Re: defining the semantics of lists

> On 13. Jun 2020, at 18:36, Ji=C5=99=C3=AD Proch=C3=A1zka =
<[email protected]> wrote:
>=20
> Just adding a vocabulary for describing container size, without any =
special semantic implications, is of course easy. There is the question =
if this should be in the "rdf" namespace, which would make it a harder =
task. People like myself would like RDF to be a minimalist unopinionated =
foundation to build upon. It would seem like cluttering. I'd prefer if =
collections etc. had their own vocabulary(ies), perhaps opinionated, =
with semantics even.
>=20
> The attitude towards change is understandable when you take in context =
that the whole semantic web project is interesting to people from =
different backgrounds, for different purposes. Hence the focus on a =
minimalist foundation and opposition to evolving RDF into a kind of a =
Frankenstein-swiss-army-knife (which you could say it already is, if you =
are being strict enough).

I wouldn=E2=80=99t be that strict. As a language aimed at end users who =
we want to upgrade the data they publish on the web with some semantics =
it is rather a little too terse. The misuse of owl:sameAs is an example =
for a desire to connect and relate that hasn=E2=80=99t been met with an =
appropriate vocabulary term. The problem wasn=E2=80=99t that the =
semantics of owl:sameAs were not crisp enough but that there wasn=E2=80=99=
t anything better in reach for the over-eager young semanticist (yes, =
I=E2=80=99m talking about myself too).=20
For a good design it=E2=80=99s not enough to be correct, it also has to =
be reasonably complete and rounded and meet the need of users. That=E2=80=99=
s why in the case of the "limit" attribute I do indeed think that it =
should be part of core RDF. The other candidate would be something like =
owl:sameAs, but without formal semantics (and more same-ness mojo than =
rdf:seeAlso). That=E2=80=99s a bit paving the cow paths I guess.

> Backwards compatibility is important for the reason that breaking =
change makes upgrading the same (or close to) as replacing it with =
something different.=20
> I agree on many points regarding RDF issues (named graphs etc.) but =
for me these are also underlying issues to my main issue, that I don't =
see much movement in direction towards a modular machine-first system, =
built on a common minimalist foundation, with an ecosystem of easily =
integrated components to support the desired use cases. What we have is =
a sprawl of mostly academic projects which are often very difficult to =
integrate.

One might partition the vocabulary into
- core (most of RDF) (which I guess is the common minimalist foundation =
that you refer to),=20
- the informal, user oriented parts (lists, also better support for =
n-ary relations)
- (maybe also templates for some ubiqituous data types like adresses, =
events etc)
- basic reasoning (domain, range, subclassing, subproperties, typing),=20=

- more reasoning (RDF reasoning about itself, some less intimidating =
parts of OWL),=20
- and the big gap: sound meta modelling
- and the other big gap: closing and constraining the world locally
That=E2=80=99s probably all still doable in an RDF 2. Some owl:sameAs =
statements to ensure backward compatability ;-) Applications could then =
be refactored acccordingly. Is that what you have in mind? (Probably =
not, I=E2=80=99m a bit guessing here).

> We are lacking some common foundations and established ways how to =
build on them. For example we don't have established answers to these =
questions:
>=20
> When exactly is it right to build semantic extensions?
> When to build a vocabulary/ontology?
> How should the semantics extensions be built in order to be as =
interoperable as possible?

We don=E2=80=99t really have much discussion about the concept of =
semantic extensions at all, in any way. The OWA is both an undispensable =
and necessary base but also an unrealistic idealistic scenario in =
practice. Semantic extensions should bridge the gap between teh OWA and =
closed world applications but the notion is not really filled. OWL DL as =
a semantic extension is even more embarrasing than the already hard to =
swallow OWA.  Apart from that application developers do their thing and =
close the world around them implicitly.
So this definitely needs to be tackled. The question is not so much =
"what is the best way" but rather "what could be a shared way", how can =
we bridge and negotiate between different realms of openness etc.=20
Probably Named Graph semantics in RDF need to be fixed first. Then we =
can use that as a base to express semantic extensions, reasoning regimes =
etc. Then we can make our applications deal with them appropriately.

Cheers,
Thomas

> Best,=20
> Jiri
>=20
>=20
>> On June 11, 2020 12:02:07 AM GMT+02:00, "thomas l=C3=B6rtsch" =
<[email protected]> wrote:
>>=20
>>=20
>>> On 10. Jun 2020, at 22:30, Ji=C5=99=C3=AD Proch=C3=A1zka =
<[email protected]> wrote:
>>>=20
>>> Right, as has been pointed out by many, changing or extending RDF
>>> semantics would be extremely difficult task, but it isn't necessary.
>>>=20
>> There=E2=80=99s two things:
>>=20
>> 1) Adding a property to the Container vocabulary as _describing_ the =
size of a container wouldn=E2=80=99t change the semantics of RDF. We =
discussed at length in this thread what can and can=E2=80=99t be =
achieved when changing the fundamentals of RDF is not an option - and I =
sure think it isn=E2=80=99t.
>>=20
>> 2) The attitude towards change in this community is difficult to say =
the least. When Dan Brickley posted his very interesting history lessons =
a few moths ago I realized that reification had been considered for =
deprecation around 2000 already. OMG. On the one hand we are trying to =
build something of unprecedented size and reach, on the other hand we =
can=E2=80=99t make the slightest backwards incompatible change from day =
1 on? This attitude is insane and it only leads to the standard getting =
stale and eventually being replaced by soemthing new altogether - but at =
a much hingher cost to everybody involved than some breaking changes =
would occurr.
>> I was a the RDF Next Steps Workshop in Stanford 2010 (it was open to =
everbody and I couldn=E2=80=99t resist) and I remember well the vivid =
argument that we would risk uptake and adoption that was just about to =
start if we changed anything more than the most pressing technicalities. =
Last year at the Berlin Workshop I heard that now it=E2=80=99s too late =
for profound change as the installed base is already to big, that ship =
has sailed. So I must have missed the historic millisecond, around 2016 =
and a half presumably, when the stars had aligned, once and for all? =
What a choke, what a farce. Occassionally dark forecasts are made that =
all Semantic Web companies will go bancrupt if we introduce more than =
the most pressing changes. In the meantime a new industry of now about =
the same size than ours grew up - Property Graphs - on the only grounds =
that they have better usability and meta modelling. So who will gp =
bancrupt soon and why exactly? And a handful of companies support RDF* =
already - probably because they don=E2=80=99t want to get bancrupt, not =
because change is so impossibly hard and shouldn=E2=80=99t even be =
attempted.
>>=20
>>> Easier would be to make your own RDF collection/container vocabulary
>>=20
>> So, I=E2=80=99d say change is good and is indeed pretty necessary. If =
nobody cares and just dabbles on heir own vocabulary instead of trying =
to fix the mothership RDF there won=E2=80=99t be much reason to fix it =
soon enough. It would be easier for sure but not very sustainable.
>> The situation with lists is a classic SNAFU. But lists are the =
easiest part. Identifcation is broken and no one even cares anymore. =
"Just use AI to disambiguate" I hear. Reification is a mess (and RDF* in =
its current state might make it better, or worse) and Named Graphs have =
no semantics, so there is no sound meta modelling in RDF. OTOH everybody =
who doesn=E2=80=99t work on well contained single topic applications =
will acknowledge that the Semantic Web needs an agreed upon facility to =
model context and refication. That requires change, and it requires a =
vision about how everything can fit together. And it is about time.
>>=20
>>> and
>>> a validation language for it. The language would have its own =
semantics,
>>> possibly backed by some formal logic. The language syntax could be =
RDF.
>>> In many ways Shapes Constraint Language (SHACL)[1] could be an
>>> inspiration (also has RDF as syntax), could be used by your =
language, or
>>> your language could be a SHACL extension. Overall, what you are =
going
>>> for sounds like a generalization of an application of SHACL.
>>=20
>> A property to desribe the intended size of a Container would belong =
to RDF. Constraints to enforce such a limit locally in apllications =
would belong to Shacl, Shex etc. But I=E2=80=99m currently trying to =
figure out if lists as proper datatypes aren=E2=80=99t a better way =
forward.
>>=20
>>>> But how could we enforce such constraint descriptions not just in
>>>> applications but within the OWA realms of RDF?
>>>>=20
>>> Do you mean make entire RDF graphs invalid just because it doesn't =
fit
>>> some constrains for a particular purpose? Why would that be =
desirable?
>>> Even if a graph says something which is invalid for some purpose, it
>>> could be valid for another purpose - a simple example being RDF
>>> visualization.
>>=20
>> Closing the world for some application shouldn=E2=80=99t inflict the =
Open World around it. A dataset might have to undergo certain procedures =
and scrutiny before I feed it into my application. Some applications =
certainly demand such restrictivity. That doesn=E2=80=99t say anything =
about the uses and usefulness of that dataset outside of such a specific =
application.
>>=20
>> As a side note, if you decide to go down the rabbit hole, you might =
want
>> to consider handling collections restricted to members of a =
particular
>> class/datatype or their subclasses.
>>=20
>> A Series container with an explicit extension hook might be a nice =
idea: immutability was just one  example. But it could also be overkill.
>>=20
>>=20
>> Best,
>> Thomas
>>=20
>>=20
>>> Cheers,
>>> Jiri
>>>=20
>>> [1] https://www.w3.org/TR/shacl/
>>>=20
>>> On 6/8/20 12:19 PM, thomas l=C3=B6rtsch wrote:
>>>> On 4. Jun 2020, at 01:40, Ji=C5=99=C3=AD Proch=C3=A1zka =
<[email protected]> wrote:
>>>>=20
>>>> This has been an interesting thread to follow, but from the start =
I've
>>>> felt a clearly stated use case is missing. This would clear up many
>>>> things, possibly pointing to a solution which doesn't require =
changes to
>>>> RDF(S) semantics at all.
>>>>=20
>>>> I remember someone (Pat?) rightly saying that RDF was not a data
>>>> structure language, but a KR (or something like that).
>>>> So simply wanting the sort of things that programming languages =
have
>>>> as data structures is not necessarily a useful thing to spend time =
on.
>>>>=20
>>>> I much prefer predicates to be specific to the range and domain =
that
>>>> they are working over.
>>>>=20
>>>> Agreed, personally I think the rdf:List, RDF containers =
vocabularies
>>>> should be used mainly as base classes/properties to be subclassed =
in
>>>> domain specific schema or perhaps not at all.
>>>>=20
>>>> That said, one might be describing things like APIs in RDF. In such
>>>> cases one might describe some examples of input, having to be =
careful to
>>>> not define them with an unintended structure (for example a =
branching or
>>>> looping list). If this was the use case, RDF authoring tools could
>>>> feature warnings for irregular structures.
>>>>=20
>>>> An interesting use case is describing APIs accepting RDF data as =
input.
>>>> Ideally it should be using a domain specific schema, but I can see =
it
>>>> often having constructs similar to rdf:List or RDF containers. The =
APIs
>>>> descriptions should also definite how unexpected inputs are =
treated.
>>>> This could be standardized, separately to RDF specifications.
>>>>=20
>>>> These are the use cases which I thought of, I would like to know of
>>>> others. I don't think a change of RDF semantics would be needed for =
these.
>>>=20
>>> Right, no need to change the RDF semantics. It's two things however:
>>> A what RDF can describe
>>> B how descriptions can be enforced as constraints
>>>=20
>>> A
>>> Lists in RDF can be described as
>>> - closed (rdf:List)
>>> - ordered (rdf:list, rdf:Seq, rdf:Bag, rdf:Alt)
>>> - without duplicates (rdf:Alt)
>>> - with preferred member (rdf:Alt)
>>> This is a bit messy and not all combinations are available. Adding a =
'last' attribute to Containers might ameliorate the situation. The =
rdf:Series class that I proposed mainly as an example to facilitate =
discussion could be extended to address all those properties and maybe =
more:
>>>=20
>>>            // A new subclass of Container that very explicitly =
describes
>>>            // size, preferred alternative, ordering and duplicates.
>>>            // Ordering and duplicates default to TRUE.
>>>            // If no attributes are set Series corresponds to Seq.
>>>            // This container type has the combined semantic =
expressivity
>>>            // of Seq, Bag and Alt plus the capability to describe =
its size.
>>>            // The immutable property is a hint that such a newly =
defined
>>>            // construct could indeed be used to describe a few more =
things.
>>>=20
>>>  Series     subClassOf  Container
>>>  last       domain      Series
>>>             range       ContainerMembeshipProperty
>>>  pref       domain      Series
>>>             range       ContainerMembeshipProperty
>>>  order      domain      Series
>>>             range       Boolean
>>>  dupes      domain      Series
>>>             range       Boolean
>>>  immutable  domain      Series     // why not reach for the stars...
>>>             range       Boolean
>>>=20
>>> B
>>> Translating those descriptions to constraints can be tricky as =
Peters questions proved but it certainly can be done in one way or the =
other. APIs described in RDF, OWL DL formalizations, rules, Shexl =
constraints are all viable options. But how could we enforce such =
constraint descriptions not just in applications but within the OWA =
realms of RDF? That requires closing the world around the description. =
Named Graphs come to mind. So basically:
>>> - define a way to guarantee sound naming semantics for Named Graphs,
>>> - define a way to attribute graphs with semantic extensions,
>>> - define such extensions (like e.g. an app friendly local =
CWA/NAF/UNA walled garden)
>>> - teach RDF consuming applications to process data according to the =
rules of such extensions locally, within those graphs
>>> and be done with it?
>>>=20
>>> Thomas

[Lots of previous messages snipped.]=