Re: labelled property graphs vs -star extension of RDFn vs -star extension of named graphs

> On 8. Dec 2023, at 17:19, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> So this indeed would be a user-visible difference from the labelled property graphs situation.

It depends on how you go about it. There is two aspects to consider:
- do you talk about types or tokens
- how do you refer to those tokens

RDF standard reification does talk about tokens, but there is no "hard link" (for lack of a better expression) between the token identifier and the token it identifies. The token so identified is subsumed in the type. There’s only one statement of some type in the data because of set semantics. 

However, this has problems. When you describe different tokens and only some of them are meant to be unasserted, you lose that important detail as another token desription was indeed added together with an asserted triple of that type (well, talking about unasserted assertions was never the aim of RDF standard reification, so it is excused - it’s just how people use it). More problems arise when one of those token annotations gets deleted: delete the asserted triple too, or does another token annotation still "use" it, depend on it? This needs a lot of housekeeping to get right. The perils of early optimization.

To solidly connect annotations on a token with the token in the way LPG provides it, one has to work around the set semantics of RDF. There’s different ways to do that: singleton graphs, singleton properties, triple identifiers like in RDFn. All that doesn’t break the RDF semantics. It just means that deduplication is applied at a different point in time: when saving the statement (only once, as type) or when querying it (returning it only once, or returning it multiple times with references to those annotations) or when reasoning (interpreting the annotations as additional information that can be ignored, or go into contextual logic). 

Thomas

> peter
> 
> On 12/8/23 09:48, Thomas Lörtsch wrote:
>>> On 8. Dec 2023, at 15:18, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
>>> At the teleconference yesterday I mentioned that there could be user-visible differences between different views of how to proceed, even when there is some consensus that different views are essentially the same.
>>> 
>>> Here is one example of a user-visible divergence.  Consider the following input, written in the community group syntax.
>>> 
>>> :liz :spouse :dick {| :start 1964; :end 1974 |} .
>>> :liz :spouse :dick {| :start 1975; :end 1976 |} .
>>> 
>>> In the community graph version of RDF-star this results in one asserted triple with subject :liz that is the subject of four triples.  In SPARQL-star, the BGP
>>> 
>>> :liz :spouse :dick {| :start 1964; :end 1976 |} .
>>> 
>>> would match against a graph constructed from this input.
>>> 
>>> In labelled property graphs this would appear to result in two asserted triples with subject :liz, each with two property-value pairs.  The above BGP would not match.
>>> 
>>> So there is a decided visible difference between the community graph version of RDF-star and labelled property graphs.
>> Yes. I believe a proposal has somewhere, somewhen (by me) been made that the shorthand syntax be extended by an identifier, e.g.
>>     :liz :spouse :dick { id:1 | :start 1964; :end 1974 |} .
>>     :liz :spouse :dick { id:2 | :start 1975; :end 1976 |} .
>> which would map to
>>     id:1 rdfx:occurrenceOf << :liz :spouse :dick >> ;
>>          :start 1964; :end 1974 .
>>     id:2 rdfx:occurrenceOf << :liz :spouse :dick >> ;
>>          :start 1975; :end 1976 .
>>> If I am correct in reading the (sparse) information available about RDFn, a -star extension of RDFn would conform to the community group reading.
>> My reading is that two occurrences get two different identifiers. The identifiers are not a function of the triple alone. Anyway, even if it isn’t yet it seems that that would be easy to add.
>>> So there would be noticeable differences between an extended RDFn and labelled property graphs.
>>> 
>>> I am not aware of any proposal for using named graphs that says what the above would result in there, so it is unclear which side a named graphs version of -star would fit into.
>> The nested named graph proposal is very definite about this, and it is clearly in the multi-edge camp
>> Thomas
>>> peter
>>>

Received on Friday, 8 December 2023 17:07:53 UTC