Re: defining the semantics of lists

I've been looking at the suggestions to set up chains in RDF and I have a
number of questions.

What are chains supposed to be for?  What are the semantics of chains
(saying a bit more than rdf:Collection is not adequate)?  Is a chain more
than a bunch of triples?  What counts as a chain?  Can chains be circular?
Can they be infinite?  Can they share heads?  Can they be multi-tailed?  Can
they have multiple values for one position?  Can chains be elements of
chains?  Can chains be ungrounded?  Is it possible to have a chain with no
elements?

In my view it is a good idea to determine what chains are supposed to be
fore and how they are supposed to work before the syntax (and any
axiomatization) of chains is presented, not least so that it can be
determined whether the syntax (and axiomatization, if present) actually
supports what is wanted.

Making chains be rdf:Seq plus an explicit stop point appears to answer some
of these questions, but the implications of this setup should be spelled out
explicitly.  Further not all the questions are answered.  For example, what
happens if there are two rdf:_<n> values in a chain for a particular <n>?
(This might be particularly problematic if the two values are both container
membership properties.)  What happens if there are values for rdf:_<n> with
n greater than the stop point?  What happens if there are multiple stop
points?  (This seems to be particularly problematic.)  What happens if the
value of rdfx:last is not one of the rdf:_<n>?  What happens if a chain is
one of its own elements?  Are chains complicated because of the infinite
vocabulary required?


One way to "specify" chains, of course, is to just say that they are a set of
triples, and no more.  I don't think that this is what is desired here, though.


peter



On 5/24/20 11:29 AM, thomas lörtsch wrote:
> [Lots of earlier messages and some of this message snipped.]
> I do now understand how the OWA prohibts any explicit closing of a list in RDF, how RDF is all about _describing_ things, how only single triples can be a bearer of truth, how RDF terms themselves are not to be messed with and how the whole endeavour of formal semantics under an OWA is walking a very thin line between what may be inferred and what cannot be ruled out. Maybe. [0]
> However I also lost practically all faith in the formal semantics of Collections and Containers alike. If not even the simplest syntactic constraints - only one head, no branching - can be enforced then why bother at all with the semantics of a length attribute? 
>
> Why even consider an arithmetic extension? Not withstanding its usefulness in other contexts I’m not convinced that some arithmetic extension can ground the semantics of an rdfx:hasLength property when the rdf:Container it describes has so little formal standing to build on.
>
> One could make rdfx:hasLength an owl:AnnotationProperty so its semantics would definitely be reduced to handwaving, providing a hint to applications if some list probably is complete. Closing a list was deemed useful before but it was implemented with a verbose syntax and in OWL DL it's off limits for users. Lists are so important in practice that IMO that’s reason enough to introduce something along those lines, even with _very_ limited formal semantics.
>
> I was also pondering the graph based approach that Cory proposed but for a basic construct like lists (and trees and tables that can easily be built from it) it seems a waste. Graphs should be used for all kinds of stuff, even for structural features like n-ary relations, but lists - rather not. At least that’s my current thinking.
> I think it can be useful in a bigger context like being able to express that in some application/source/universeOfDiscourse all lists are closed. But I’d rather embed that in a semantic extension that fixes a few more things and formally defines a Closed World Scenarios that applications often assume and require.
>
> Pat has in earlier mails suggested to mark the last item of a list instead of providing a length attribute. That didn’t really catch on with me because I lacked an idea how to do it. Meanwhile the following vocabulary extension bubbled up in my head:
>
>  rdfx:Chain rdfs:subClassOf rdfs:Container .
>  rdfx:last rdfs:domain rdfx:Chain .
>  rdfx:last rdfs:range rdfs:ContainerMembershipProperty .
>  
>  _:L  rdf:_1  "a" .
>  _:L  rdf:_2  "b" .
>  _:L  rdf:_3  "c" .
>  _:L  rdfx:last rdf:_3 .
>
> I sort of like it but I’m not convinced that it's really more elegant.
> Fundamentally it doesn’t seem to make much difference:
> - Containers still provide only a semantically weak base
> - a missing 2nd slot would still need to be filled
> - a surplus 4th slot would still need to be ignored
>
> And maybe the counting business on ContainermembershipProperties would still require an arithmetic extension? Which would still not be worth the trouble because it would only stand on Collections’ shifting semantic sands?
>
>
> BTW: I don’t like the name "Chain". I would prefer "Series" but I’m not a native speaker and not sure if it captures the intended purpose well enough. Also "Seq" and "Ser" are easy to confuse (but "Ser" gets filed one after  "Seq", so that’s good!). "Fin de Seq" would of course be even nicer.
>
>
> Thomas
>
>
> [0] And that the RDF Semantics at https://www.w3.org/TR/rdf11-mt/ use the term "intent" although I got ridiculed for introducing it a few mails ago: "The intended mode of use is that things of type rdf:Bag are considered to be… " etc. Ha!
>
[Lots of previous messages snipped.]

Received on Monday, 1 June 2020 16:54:32 UTC