- From: thomas lörtsch <tl@rat.io>
- Date: Fri, 29 May 2020 20:31:39 +0200
- To: William Van Woensel <William.Van.Woensel@Dal.Ca>
- Cc: Patrick J Hayes <phayes@ihmc.us>, Semantic Web <semantic-web@w3.org>
Hi William and Doerthe,
thank you very much for the detailed and elaborate response! Some more remarks below which maybe you find useful.
> On 19. May 2020, at 15:00, William Van Woensel <William.Van.Woensel@Dal.Ca> wrote:
>
> Hi Thomas,
>
>>> The use of rdf:first and rdf:rest can be regarded as a reification of the list datatype.
>> This is the only time that reification is mentioned in that document [0] so I guess it refers to RDF reification which has incomplete semantics. But lets assume an N3 document provides the application context in which a reification is semantically sound.
> I interpreted this statement as such (note that the current WG did not write this spec): just like RDF statements can be reified by specifying its components one by one, so can the elements of an N3 list. I didn't read much more into it.
Reification is a tricky subject. I don’t know how it’s handled in N3 but in RDF it is not specified which specific triple a reification quadlet reifies: the reification quadlet only reifies the abstract triple type, not any concrete token - but as said before lets ignore this aspect and assume that the document is the context that associates a triple token with its reification quadlet.
The other important subtlety in RDF reification is that the reificaton quadlet does not assert the triple it reifies. Again I don’t know the subtleties of N3 but if it understood reification as in RDF then the first/rest ladder would not actually state the list it describes - only the bracket style list would do so. But first-rest-ladders in RDF certainly do not reify but state a list.
So one way or the other N3 diverges from RDF semantics, right? Maybe I’m not seeing the forest because of all the trees and this problem disappears when the notion that "The use of rdf:first and rdf:rest can be regarded as a reification of the list datatype." is dropped. Or, as you say, let’s not read much into it.
> From a practical viewpoint, a first-rest ladder can be converted into an N3 list, and vice-versa, via the application of some straightforward rules. From a semantic viewpoint however, N3 lists, either in their first-rest ladder form or otherwise. expand on the (underspecified) RDF lists in the following ways: all lists exist, the “first” property is functional, and lists are uniquely identified via their contents. The explanation of N3's list semantics is a little bit clearer in the related paper [1].
>
> In a bit more detail, N3 understands lists as proper data types, and they can be represented in brackets just like in Turtle (e.g., (:first :second :third)). In order to make that compatible with the first-rest ladder representation of lists as used in RDF, extra axioms are needed. These are explicitly listed in the paper; an example is that the properties rdf:first and rdf:rest need to be functional). With these axioms, we can treat both kinds of lists as equal.
>
> Note that our current semantics of N3 sees the lists in brackets as the primary representation of lists. The first-rest-ladders are not formalised yet, but we plan to do that following the axioms stated in the paper (when we are at that point, we will also see whether there are open problems).
>> Would then
>> - an implementation treat a list either as a datatype or an rdf:first/rest/nil ladder?
> Internally they could do either, but they will need to be able to "understand" both. It is interesting to notice the way N3 understands the predicates rdf:first and rdf:rest. The following triples need to be true:
>
> (:first :second :third) rdf:first :first.
> (:first :second :third) rdf:rest (:second :third).
>
> If you have in mind that N3 also supports rules and universal quantification, those predicates make it easy to deal with lists (no matter how you represent them internally):
> :my :list (:first :second :third).
> {
> :my :list ?list.
> ?list rdf:first ?first
> }
> =>
> {
> ?first :isFirstElementOf ?list.
> }.
> A reasoner should derive:
> :first :isFirstElementOf (:first :second :third).
>
> This can be seen as an example of the "mixed" notation, and it is not strictly one or the other.
This shape shifting capability is kinda cool but why not provide syntactic sugar for lists in the query/reasoning syntax as well, like:
{
:my :list ?list#first .
}
=>
{
?list#first :isFirstElementOf ?list.
}.
I just invented the "#first" fragment identifier syntax. With "#second" etc it would get trickier. Shamless plug: use containers instead and you have those nifty :_1 … membership properties at your disposal ;-) Or just repurpose them...
> (As a side remark: as in many other RDF contexts, the scoping of blank nodes can be tricky, especially in rules. That is why we are hesitating to claim that the axioms really solve all problems. My personal advice to all implementers would be to use the bracket notation.)
>
>> - or can both ways to model lists be used interchangeably, could the same list occurr in both ways in the same document?
> Yes.
Again, I wonder why you trouble yourself with supporting the first-rest-ladders at all. You already have the syntactic sugar for lists. IMHO the wise design choice would be to run with that sugar as far as in any way possible.
Then also the following, quite hairy problem would just dissolve into thin air.
>> - or are lists as datatypes the primary way to introduce lists and is reification of such a list as an rdf:first/rest/nil ladder the necessary step to assert things about it?
> The plan is at least to make them equivalent following the axioms.
>
>>> 1. All lists exist. The statement [rdf:first <a>; rdf:rest rdf:nil]. carries no information in that the list ( ,<a> ) exists and this expression carries no new information about it.
>> My emglish is not the best either but the sentence above would be clearer to me if it was reworded to "… carries no information in addition to stating that the list ( ,<a>) exists…". Or do I misunderstand?
> No, that is not the meaning – but I think that the problem here is not your English, but rather the lack of explanation :)
>
> If we say that [ rdf:first <a>; rdf:rest rdf:nil]. stands for (<a>) we "lose" the meaning of the blank node; i.e., the blank node will no longer mean that some list exists, but will actually refer to the list. Hence, the axiom simply states that all lists exist to fill that “gap”. (That is partly also a problem of reification in general; we "misuse" blank nodes which are implicitly quantified and fully ignore that quantification.)
>
> Maybe it becomes clearer with a named blank node. So, the goal is to make the following two expressions equivalent:
> :my :list (<a>).
> and
> :my :list _:b0.
> _:b0 rdf:first <a>.
> _:b0 rdf:rest rdf:nil.
>
> If we want to understand the second set of triples exactly as the first one, we can see the last two triples (starting with _:b0) as auxiliary triples which "explain" the list, in that sense they "mean" (<a>). But, when we use blank nodes in triples we say that something "exists". So, there is a gap. Hence, what the team submission suggests is that we simply always assume that all lists exist.
Yes, no, … NO: I can’t get over this ( ,<a>) thing. You introduce an empty element - isn’t that simply illegal? But more importantly: what does it really stand for? IMO your problem comes from the fact that RDF can’t express anything else than triples. There is no gap of meaning or existance, there is only a syntactic gap and the blank node is nothing more than a syntactic means. Giving it more semantics is actually distorting the view.
The first-rest-ladder expresses a list with triples. The same list coated in brackety sugar is just a node and therefore can’t stand alone in RDF. Isn’t that the core of your problem? A much easier solution would then be to introduce the sugared list (<a>) in a triple, like e.g. the rather silly looking:
(<a>) owl:sameAs (<a>) .
or (actually equally verbose):
(<a>) a rdf:List .
or, nearer to your example above:
(<a>) owl:sameAs _:b0 .
You argue that you don’t want to loose the semantics of the blank node (the _:b0 in your example) but I think you are mixing structure with content. Sure, the _:b0 expresses that there exists something (up to this point a very trivial assertion) with certain properties, namely listiness, list members etc (now indeed interesting). The
(<a>)
does the same: it expresses the existance of a specific list. What you want to capture with the blank space in your (,<a>) is actually already expressed: through the brackets! The brackets are the equivalent of the first-rest-ladder of which the blank node is a part. The blank node is purely a syntactic means which on itself, without the list that builds on it, is just a node
_:b0
and as such is meaningless. IMO there is not only no point in not "loosing" it, the attempt is outright wrong as it introduces the concept of something essential behind/within/grounding the list. But such essential thing isn’t there: the list is just the list and it exists in whatever syntax one chooses to express it, but nothing more.
I seem to vaguely remember that some translations of logic into spoken language tend to omit such "There exits… such that..." phrases - maybe because they want to avoid those pitfalls but I can’t come up with an example right now. Also, according to Wikipedia existential quantification has a few, slightly different meanings: "there exists", "there is at least one", or "for some" [0]. IMO it’s best not to read too much into it, or rather as little as possible. After all saying that "something exists, period" is a pretty trivial assertion.
> Finally, note that N3 supports a set of builtins that operate on lists; such as appending, checking membership, etc. We plan to add a “length” builtin as well (honestly, even before this mailinglist thread started!).
But now that Pat talked me out of the length property, what will you do? ;-)
Thomas
[0] https://en.wikipedia.org/wiki/Existential_quantification
> Kind regards,
> William and Doerthe
>
> [1] Berners-Lee, Tim, et al. "N3logic: A logical framework for the world wide web." Theory and Practice of Logic Programming 8.3 (2008): 249-269.
>
> -----Original Message-----
> From: thomas lörtsch <tl@rat.io>
> Sent: May-18-20 7:08 AM
> To: William Van Woensel <William.Van.Woensel@Dal.Ca>; Patrick J Hayes <phayes@ihmc.us>
> Cc: Semantic Web <semantic-web@w3.org>
> Subject: Re: defining the semantics of lists
>
> CAUTION: The Sender of this email is not from within Dalhousie.
>
> Hi William,
>
> thank you for the pointer to N3! You will have noticed that I’m not the most proficient logician around so it should come without surprise that I have some questions.
>
> > The use of rdf:first and rdf:rest can be regarded as a reification of the list datatype.
>
> This is the only time that reification is mentioned in that document [0] so I guess it refers to RDF reification which has incomplete semantics. But lets assume an N3 document provides the application context in which a refication is semantically sound.
>
> Would then
> - an implementation treat a list either as a datatype or an rdf:first/rest/nil ladder?
> - or can both ways to model lists be used interchangeably, could the same list occurr in both ways in the same document?
> - or are lists as datatypes the primary way to introduce lists and is reification of such a list as an rdf:first/rest/nil ladder the necessary step to assert things about it?
>
> > 1. All lists exist. The statement [rdf:first <a>; rdf:rest rdf:nil]. carries no information in that the list ( ,a> ) exists and this expression carries no new information about it.
>
> My emglish is not the best either but the sentence above would be clearer to me if it was reworded to "… carries no information in addition to stating that the list ( ,<a>) exists…". Or do I misunderstand?
>
>
> Best,
> Thomas
>
>
> [0] https://www.w3.org/TeamSubmission/n3/#lists
>
>
>
> > On 17. May 2020, at 15:17, William Van Woensel <William.Van.Woensel@Dal.Ca> wrote:
> >
> > Hi Thomas, Pat,
> >
> > Regarding Pat's comment re possible semantic conditions, I think
> > Thomas' message has some good examples :-)
> >
> > I will point out that, in Notation 3, lists / collections are closer to first-class citizens than they are syntactic sugar. The W3C Team Submissionspecifies some extra axioms to deal with N3 lists, and mentions they could be implemented as data-types (in that case the first-rest ladder could be regarded as a reification). In fact, these axioms cover something similar to what Pat mentioned – i.e., if the same resource has multiple “first” arcs from it then those nodes must be equivalent.
> >
> > We are working on an N3 semantics that extends the RDF semantics, and
> > here, N3 lists are considered an element in their own right (in
> > addition to cited graphs and quantifiers, for instance). As opposed to
> > static properties (such as rdfx:length), a set of built-ins have been
> > defined for lists, such as member, append, .. (e.g., see Eye, Cwm). We
> > have a built-in wish list going here (feel free to contribute!)
> >
> >
> > Regards,
> >
> > William
> >
> > -----Original Message-----
> > From: thomas lörtsch <tl@rat.io>
> > Sent: May-17-20 6:41 AM
> > To: Patrick J Hayes <phayes@ihmc.us>
> > Cc: William Van Woensel <William.Van.Woensel@Dal.Ca>; Semantic Web
> > <semantic-web@w3.org>
> > Subject: Re: defining the semantics of lists
> >
> > CAUTION: The Sender of this email is not from within Dalhousie.
> >
> > Hi all,
> >
> > I’m really having trouble wrapping my head around this…
> >
> > Pat’s main argument centers around a very clear cut distinction between descriptions and constraints. But in reality that distinction is often not so clear but rather a perspective that one can choose [1]. I’ve got the feeling that I can evade the whole argument about a fundamental change to RDF by just proclaiming that the proposed list length attribute is merely a description of the intent behind a certain list.
> > E.g. I might want to publish a list of my favored colors and declare that I have exactly 3 of them. The list however contains only 2 because I can’t decide what the third one should be. That says something about my list (and my state of mind) but it certainly doesn’t break RDF.
> > But I fear that such a merely descriptive interpretation would then again amount to a very weak formal semantics, certainly weaker than that of collections.
> > Insofar, yes, I see the dilemma. I wonder however how RDF could establish any semantics on such grounds. On the semantic web are at any time talking about statements that could be wrong, misleading, grossly incomplete etc. None of that breaks the fundamentals.
> >
> > Let's take a more solidly worked out list vocabulary: to simplify things I refrain from the idea to add a length attribute to existing containers. Instead I define a new type of container, rdfx:Chain, and a new property rdfx:hasLength. I subclass rdfs:Container because I strive for lists that are easy to read and write by hand [0].
> >
> > rdfx:hasLength
> > rdfs:domain rdfx:Chain ;
> > rdfs:range <http://www.w3.org/2001/XMLSchema#int> .
> > rdfx:Chain
> > rdfs:subClassOf rdfs:Container .
> >
> > I'd like rdfx:Chain to be defined rather tight:
> > * an rdfx:Chain should have exactly as many entries as indicated by its length property.
> > * entries should be assigned through rdfs:ContainerMembershipProperty properties, starting from 1 and without skipping numbers: an rdfx:Chain of length 3 is expected to be constructed of exactly the properties :_1, :_2 and :_3..
> > * an rdfx:Chain without a length property is mostly equivalent to an rdf:Seq but is still required to be without gaps and consecutively numbered, starting from 1. Its length may therefor be calculated from an rdfx:Chain that meets all those requirements.
> >
> > Any rdfx:Chain that breaks one of these rules is considered, ahem, problematic. Applications must decide how to handle it.
> > More semantics are sure possible. A somehow sensible set of rules could be that an unruly numbered rdfx:Chain is re-numbered, starting with :_1, missing members are augmented as blank nodes and surplus members cut or at least ingored. OTOH there’s so many things that can go wrong and with so many different consequences that it seems a bit risky to standardize such fixing arrangements.
> >
> > The semantics of rdfx:Chain without any extra fixings are not much different from rdf:List except the one basic difference that an rdf:List that is broken because e.g. an element went missing is broken very obviously. The rdf:List doesn’t need any machinery that calculates if it's okay or not whereas an rdfx:Chain does need such machinery. I do however still have trouble accepting that bridging this difference would require to fundamentally alter RDF. It seems like syntactic sugar to me, albeit on the model level. Well, maybe that makes all the difference?
> >
> > However: let’s say I declare ex:house to be rdfs:subClassOf ex:car and consequently a reasoner starts to add four wheels to every house in my ontology. That may be unfortunate but it doesn’t break RDF. How would a moderately heavy handed fixing arrangement as outlined above (say we don’t delete surplus members but simply ignore them) be any different? Does the problem stem from the fact that we are talking about RDF vocabulary, not instance data?
> > Pat argues that RDF is not designed to be a datastructure language, but does that mean that describing datastructures is off limits to RDF? Is it to be considered as a sort of meta modelling? Does it lead to paradoxes or intractability?
> >
> > Another aspect: Pat's reference to lists as a new node type seems to suggest that contradictions that are encapsulated in one statement are not a problem. The statement
> > ex:aChainOfLength_4 rdfx:hasLength "3"^^xsd:integer would therefor not be problematic although ex:aChainOfLength_4 is clearly of length 4, not 3 as stated. This seems unfair and I’m again reduced to bickering, but not really understanding.
> > BTW: I’m not convinced by that whole approach of a new node type for lists. I'd like lists to be integrated into RDF first class because they are such an important and ubiquitous datastructure. Describing lists in RDF is certainly not the most efficient way to implement and use them but I prefer a tight integration to an encapsulated one. I’d like to be able to spin graphs that relate and annotate items in lists and lists of lists (tables). That can more naturally be done when lists are expressed as graphs. However I’ve never seen the approach with a new node type fleshed out in considerable detail. Maybe it has some advantages that I'm not aware of.
> >
> > Best,
> > Thomas
> >
> >
> > [0] Collections took all the syntactic sugar in N3, Turtle and JSON-LD but that's another problem that for now shall be ignored.
> >
> > [1] To elaborate: a statement can be considered a description, an axiom, a constraint - that often depends on the point of view taken and is rather an operational aspect. There can be value in adding a length property to a list for the purpose of indicating when the author thinks that the list is complete. I might want to publish a list with my favorite colors and express that I have exactly three of them. I would expect the open world to have little say in that matter but to happily receive my contribution. The list however contains only 2 items because I’m still undecided about the third color.
> > The list consumer then has a situation and will have to find a way to deal with it. However it’s often better to be made aware that there might be a problem. In such a case the added length attribute is a feature as it describes a discrepance between what I said and what I intended to say. Only in a further step may an axiom derive that the third color is as undefined as my state of mind or may a constraint reject the list as incomplete.
> >
> >
> >
> >
> > > On 15. May 2020, at 06:07, Patrick J Hayes <phayes@ihmc.us> wrote:
> > >
> > > Hi Thomas
> > >
> > > Let me explain why the semantics of the RDF containers is the way it is. Several members of the RDF WG were surprised by this, but it kind of follows inevitably from other, more basic, design decisions of RDF.
> > >
> > > First, RDF is NOT designed to be a datastructure language: it is a descriptive language. It describes things. The semantics is entirely set up with this basic design decision in mind. And second, it describes things under an open-world assumption. That point (open-world vs. closed-world) was always controversial, but it was thrashed out very early in the design process and became a fundamental design choice, on the grounds that a Web-based description language can never assume that all the relevant data is known about some topic. So this means that given any piece of RDF, you can cut out some piece of it, or adjoin some more RDF to it, without anything breaking.
> > >
> > > So now, how could rdfx:ClosedSeq work? Presumably it would come along with a bunch of assertions about the first, second, third etc. elements of the seq, and maybe a way of saying that the one of them is the last item, so we might need rdfx:LastItemIn. Suppose however that we simply don’t have a triple that specifies the second element. Is this an error? Or just an incomplete description? If the latter, what if we omit the LastItemIn triple; then we don't know how long this seq is. Is that also an incomplete description (as the open-world assumption requires) or is it an error? What happens if we are told that A is the second item and also that B is the second item? Is that an error, or can we conclude that owl:sameAs A B ? If we take the open-world choice in these cases then this is hardly distinguishable from that we have already. But if we say that incomplete or ‘excessive’ information is an error then we don’t really have an RDF graph, since the extra constraints amount to a fundamental change to the idea of graph syntax. A ‘legal’ RDF graph now is not just a set of triples: it has global constraints on what must be present or what is allowed to be present. This is of course possible, but it would change RDF fundamentally.
> > >
> > > Now, another way to go would be to say that RDF needs containers, but it doesn’t need to describe them using triples. We could just allow a new kind of construct as a node in a triple (in addition to IRIs, Bnodes and literals) and give it its own definition. We would have to invent new syntax to represent them, of course, which would break all known RDF engines, but maybe it would be worth it (?) Then sequences (etc) would be much more like conventional datastructures. Of course, the semantics would have to say something about these things, but not much. (For example, we might require that IRIs inside sequences denote the same thing as they do outside, basic things like that.) This would not break the open world assumption.
> > >
> > > Anyway, I hope this helps people think about what the issues are :-)
> > >
> > > Best wishes
> > >
> > > Pat
> > >
> > >
> > >> On May 14, 2020, at 8:18 AM, thomas lörtsch <tl@rat.io> wrote:
> > >>
> > >> I’m aware that the topic of lists in RDF can ingnite lively debate nearly as much as blank nodes so my apologies in advance. I have a very specific question and I don’t intend to discuss the use of lists in OWL, syntactic sugar in Turtle, querying in SPARQL or historic details about how some decisions came to be (although I do find all that very interesting, but another time...).
> > >>
> > >> Lists from the RDF container vocabulary - rdf:Seq, rdf:Bag and rdf:Alt - can’t be closed whereas lists from the collection vocabulary - rdf:List - are always closed. Collections, in constrast to containers, are popularly considered to "have semantics" because of this closing characteristic.
> > >> The excruciatingly exact Lisp-style modelling of rdf:Lists through rdf:first/rest/nil properties does indeed leave no room for misunderstanding about the listiness and closedness of an rdf:List.
> > >> What level of semantics could be provided for containers by explicitly defining either a closed container, e.g. rdfx:ClosedSeq, or an appropriate property, e.g. rdfx:hasLength, that implicitly closes a container?
> > >>
> > >> I reckon that semantics introduced per definition are always somewhat weaker than semantics that emenate naturally and unmistakably from a datastructure itself. However collections have a lot of disadvantages (that I promised above not to discuss) and I wonder how workable the semantics provided by defining an rdfx:ClosedSeq class or an rdfx:hasLength property would be. Would they be able to take some load, none at all, not enough, or almost the same as collections?
> > >>
> > >> Thomas
> > >
> >
> >
> > > On 17. May 2020, at 05:53, Patrick J Hayes <phayes@ihmc.us> wrote:
> > >
> > >
> > >
> > >> On May 16, 2020, at 11:01 AM, William Van Woensel <William.Van.Woensel@Dal.Ca> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> Some minor thoughts on this issue:
> > >>
> > >> Suppose however that we simply don’t have a triple that specifies the second element. Is this an error? Or just an incomplete description? If the latter, what if we omit the LastItemIn triple; then we don't know how long this seq is. Is that also an incomplete description (as the open-world assumption requires) or is it an error? What happens if we are told that A is the second item and also that B is the second item? Is that an error, or can we conclude that owl:sameAs A B?
> > >>
> > >> Not sure whether this was meant to present a dichotomy between collections or containers – but it is same for the RDFS collections, no?
> > >
> > > Yes, it is. And RDF is obliged to accept the open-world interpretation in such cases.
> > >
> > >> If the second item in the linked list would be missing, it's even
> > >> worse since the rest of the list would simply be "lost"; or, the
> > >> same resource could have two different "first" or "rest" items,
> > >> possibly leading us to conclude they are equivalent (In fact, the
> > >> latter example is given in the RDF 1.1 semantics document to
> > >> illustrate the total lack of semantics for collections; which is
> > >> the real underlying issue here I suppose)
> > >
> > > Exactly.
> > >
> > >>
> > >> If we take the open-world choice in these cases then this is hardly distinguishable from that we have already. But if we say that incomplete or ‘excessive’ information is an error then we don’t really have an RDF graph, since the extra constraints amount to a fundamental change to the idea of graph syntax. A ‘legal’ RDF graph now is not just a set of triples: it has global constraints on what must be present or what is allowed to be present. This is of course possible, but it would change RDF fundamentally.
> > >>
> > >> Perhaps I again misunderstand, but surely a semantic extension with extra assumptions for datastructures (regarding entailment, or consistency) would not break RDF?
> > >
> > > Well, we certainly could have a semantic extension which imposes
> > > extra syntactic conditions of its own (just as OWL-RDF does) but
> > > then that would not be RDF. But yes, certainly such an extension -
> > > call it RDF-C, maybe -
> >
> > For a moment I thought you’d introduce contexts to define surfaces on which lists can be closed. But you wouldn’t go that far, would you? Or would you? Well, it would certainly introduce some inflationary demand in context identifiers.
> >
> > > could be defined and might be useful. My next question would be, what did you want it to mean? That is, what semantic conditions would you want to put on such closed collections and statements made about them?
> > >
> > > Pat
> > >
> > >>
> > >>
> > >> Regards,
> > >>
> > >> William
> > >>
> > >> -----Original Message-----
> > >> From: Patrick J Hayes <phayes@ihmc.us>
> > >> Sent: May-15-20 1:07 AM
> > >> To: thomas lörtsch <tl@rat.io>
> > >> Cc: Semantic Web <semantic-web@w3.org>
> > >> Subject: Re: defining the semantics of lists
> > >>
> > >> CAUTION: The Sender of this email is not from within Dalhousie.
> > >>
> > >> Hi Thomas
> > >>
> > >> Let me explain why the semantics of the RDF containers is the way it is. Several members of the RDF WG were surprised by this, but it kind of follows inevitably from other, more basic, design decisions of RDF.
> > >>
> > >> First, RDF is NOT designed to be a datastructure language: it is a descriptive language. It describes things. The semantics is entirely set up with this basic design decision in mind. And second, it describes things under an open-world assumption. That point (open-world vs. closed-world) was always controversial, but it was thrashed out very early in the design process and became a fundamental design choice, on the grounds that a Web-based description language can never assume that all the relevant data is known about some topic. So this means that given any piece of RDF, you can cut out some piece of it, or adjoin some more RDF to it, without anything breaking.
> > >>
> > >> So now, how could rdfx:ClosedSeq work? Presumably it would come along with a bunch of assertions about the first, second, third etc. elements of the seq, and maybe a way of saying that the one of them is the last item, so we might need rdfx:LastItemIn. Suppose however that we simply don’t have a triple that specifies the second element. Is this an error? Or just an incomplete description? If the latter, what if we omit the LastItemIn triple; then we don't know how long this seq is. Is that also an incomplete description (as the open-world assumption requires) or is it an error? What happens if we are told that A is the second item and also that B is the second item? Is that an error, or can we conclude that owl:sameAs A B ? If we take the open-world choice in these cases then this is hardly distinguishable from that we have already. But if we say that incomplete or ‘excessive’ information is an error then we don’t really have an RDF graph, since the extra constraints amount to a fundamental change to the idea of graph syntax. A ‘legal’ RDF graph now is not just a set of triples: it has global constraints on what must be present or what is allowed to be present. This is of course possible, but it would change RDF fundamentally.
> > >>
> > >> Now, another way to go would be to say that RDF needs containers, but it doesn’t need to describe them using triples. We could just allow a new kind of construct as a node in a triple (in addition to IRIs, Bnodes and literals) and give it its own definition. We would have to invent new syntax to represent them, of course, which would break all known RDF engines, but maybe it would be worth it (?) Then sequences (etc) would be much more like conventional datastructures. Of course, the semantics would have to say something about these things, but not much. (For example, we might require that IRIs inside sequences denote the same thing as they do outside, basic things like that.) This would not break the open world assumption.
> > >>
> > >> Anyway, I hope this helps people think about what the issues are
> > >> :-)
> > >>
> > >> Best wishes
> > >>
> > >> Pat
> > >>
> > >>
> > >> > On May 14, 2020, at 8:18 AM, thomas lörtsch <tl@rat.io> wrote:
> > >> >
> > >> > I’m aware that the topic of lists in RDF can ingnite lively debate nearly as much as blank nodes so my apologies in advance. I have a very specific question and I don’t intend to discuss the use of lists in OWL, syntactic sugar in Turtle, querying in SPARQL or historic details about how some decisions came to be (although I do find all that very interesting, but another time...).
> > >> >
> > >> > Lists from the RDF container vocabulary - rdf:Seq, rdf:Bag and rdf:Alt - can’t be closed whereas lists from the collection vocabulary - rdf:List - are always closed. Collections, in constrast to containers, are popularly considered to "have semantics" because of this closing characteristic.
> > >> > The excruciatingly exact Lisp-style modelling of rdf:Lists through rdf:first/rest/nil properties does indeed leave no room for misunderstanding about the listiness and closedness of an rdf:List.
> > >> > What level of semantics could be provided for containers by explicitly defining either a closed container, e.g. rdfx:ClosedSeq, or an appropriate property, e.g. rdfx:hasLength, that implicitly closes a container?
> > >> >
> > >> > I reckon that semantics introduced per definition are always somewhat weaker than semantics that emenate naturally and unmistakably from a datastructure itself. However collections have a lot of disadvantages (that I promised above not to discuss) and I wonder how workable the semantics provided by defining an rdfx:ClosedSeq class or an rdfx:hasLength property would be. Would they be able to take some load, none at all, not enough, or almost the same as collections?
> > >> >
> > >> > Thomas
Received on Friday, 29 May 2020 18:32:12 UTC