Re: defining the semantics of lists

Hi Peter,

my initial question when starting this thread was: what holds rdf:Containers back from having the same semantic weight as rdf:Lists? What could be done to overcome that deficit. There are some reasons why I was asking that and not the least was to understand semantics of lists - hence the subject line. With the question came the idea for an answer: an rdfx:length property to specify the length of a Container and thereby close it. With Pat's help that developed into an rdfx:last property because that way we don’t have to introduce arithmetic into the semantics. The intention is exactly the same: provide a means to close rdf:Containers, make them finite. Such a finite container could then be used instead of rdf:Lists. It would have a less obtrusive syntax, need fewer triples, perform much faster in the usual triple stores, would be easier to query and could be used with OWL DL. The only real downside so far: no syntactic sugar in Turtle - that would be another topic.

So the short answer to your questions is: the aim is to provide Containers with a semantics similar to rdf:Lists respectively to find out what is needed to reach that goal. 

The longer answer is: rdf:Containers intuitively provide some semantics already. Membership properties are ordered by integer values, starting with 1 and incremented by 1 for each entry. What’s missing compared to lists is to be able to close a container, to make it finite. Most of your questions can intuitively be answered from there:

> On 1. Jun 2020, at 18:54, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 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?  

See above.

> What are the semantics of chains (saying a bit more than rdf:Collection is not adequate)?  

See above.

> Is a chain more than a bunch of triples?  

Yes, otherwise what would be the point?

> What counts as a chain?  


> Can chains be circular?

No.

> Can they be infinite?  

No, that’s the whole point, remember?

> Can they share heads?

No, there can be only one membership property :_1 

>  Can they be multi-tailed?  

No, there can be only one membership property per integer

> Can they have multiple values for one position?  

Same question as before, isn’t it?

> Can chains be elements of chains?  

Yes, but that is another topic

> Can chains be ungrounded?

I don’t understand.

>  Is it possible to have a chain with no elements?

No, as there is no :_0 membership property.
Maybe you mean missing list entries? Any list items at list positions less or equal than the 'last' one that are not listed can be entailed as being blank nodes.

> 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.

I think we did that already and I hope you have a clearer picture now.

> 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.  

Will they ever be?

> For example, what happens if there are two rdf:_<n> values in a chain for a particular <n>?

It is an inconsistency.
What happens if it happens to occurr all the same is another question that we probably can’t answer.

> (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?  

It is an inconsistency.
What happens if it happens to occurr all the same is another question that we probably can’t answer.


> What happens if there are multiple stop points?  (This seems to be particularly problematic.)  

It is an inconsistency.
What happens if it happens to occurr all the same is another question that we probably can’t answer.


> What happens if the value of rdfx:last is not one of the rdf:_<n>?  

If there is a bigger rdf:_<n> then it is an incosistency, see above.

> What happens if a chain is one of its own elements?

The question makes no sense to me. There are infintely many ways to construct infinitely large or infnitely deep nested structures at any list item position. Why do you ask for that specific one? Is it an achievable goal to develop a definition that successfully rules out all pathological variants?

> Are chains complicated because of the infinite vocabulary required?

That would be a question that I would hope you could answer.

> 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.

I don’t think it is helpful or promising or even possible to rule out explicitly everything that you don’t think is desired. I hope however that you have a better idea now of the issue at hand and we can get to the real business. 

Pat tried his best to teach  me that RDF only _describes_, not _prescribes_ things - and lists are just another thing. Now, I surely need more time to fully wrap my head around that but it seems that all your questions and all my answers aim at perscribing, not describing. I noticed how the RDF Semantics document dances around that topic by clarifying that it can’t preclude all sorts of pathological containers and collections. Therefor I tried to come up with the least intrusive way to describe an intent about some container, namely that it has ony a certain number of members. Everything else comes from the integer order of the membership properties. That was good enough for the last 20 years so it should be good for the future too. I can wholeheartedly assure that my honest intent is only to describe that some list of mine is finite and not prescribe something about anybody elses list.

OWL DL makes some remarks what it expects from rdf:Lists, namely:
"When a list pattern is matched to G, all list variables _:xi and _:xj with i ≠ j MUST be matched to different nodes; furthermore, it MUST NOT be possible to match the list pattern to two maximal subsets of G such that some list variable in the first pattern instance is matched to the same node as some (possibly different) variable in the second pattern instance. This is necessary in order to detect malformed lists such as lists with internal cycles, lists that share tails, and lists that cross."
https://www.w3.org/TR/2012/REC-owl2-mapping-to-rdf-20121211/#Mapping_from_RDF_Graphs_to_the_Structural_Specification

This is certainly more concise and complete than what I could come up with right now but essentially it’s not rocket science either, it’s plain text. If that’s all that’s needed, then: yes, I can do that too for rdf:Containers with a 'last' property. And the gist of it can be found above.

I hope all this is enough so that you can now answer the question if such a 'last' property on rdf:Containers would break anything in OWL DL, catapult the ontology out of DL or otherwise look fishy and suspicious to you.

Thomas





> 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 21:11:31 UTC