Re: Consolidating triple/edges -- named occurrence version

On 01/01/2024 21:15, Gregg Kellogg wrote:
>> Multiple edges with the same label are handled as multiple 
>> occurrences - the predicate URI of the RDF triple is thought as a 
>> conceptual relationship - with multiple sets of annotations.
> What does it mean for two occurrences to be labeled with the same 
> IRI/BNode? This would certainly invalidate using r.id <http://r.id> to 
> identify just a single occurrence. Would this directly relate these 
> occurrences with each other as if they share a graph?
>
> Perhaps I mis-understand this point; I get that << :r | :s :p :o >> 
> can be used in multiple triples to identify the same occurrence and 
> that << :r1 | :s :p :o >>

This isn't something that is specific to this version of the 
triples/edges proposal. In fact, it applies to any proposal where 
occurrences are named.

One way is to make it illegal for a name to be reused for a different 
item. While it may be possible with blank nodes where the scope is a 
document, it does make sense for URIs.

rdf:ID in RDF/XML reification comes close (but is different) to this: 
https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-reifying

The other way is to say "whatever can be deduced" if the same name is 
used in two named occurrences (different by s/p/o).

<< :r | :s1 :p :o >> << :r | :s2 :p :o >> would imply that :s1 and :s2 
refer to the same resource. The relationship name to s/p/o is functional.
(Base RDF itself can't say equals).

https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0060.html

> identifies a separate occurrence. How would << :r | :s :p :o >> and << 
> :r | :s1 :p1 :o1 >> relate to each other? Why should this be 
> considered valid? Can :r be thought to have some meaning aside from 
> being an identifier of a triple occurrence?

<< :r | :s :p :o >> and << :r1 | :s :p :o >>  is two occurrences. Each 
named occurrence can have different triples relating to it.

example: two time intervals:

<< :r | :shop :p :o >>
    :opens 10:00 ; :closes 13:00 .
<< :r1 | :shop :p :o >>
    :opens 14:00 ; :closes 17:00 .

https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0128.html

>
>> So if the application is given <http://example/occ1>, how does it 
>> determine whether URI is named occurrence and if so, how does it find 
>> the triple subject/predicate/object?
>>
>> Scanning all triples to find named occurrences and looking at the id 
>> of a named occurrence is expensive.
>>
>> Expecting an addition function x -> triple just for occurrences is a 
>> big step.
>>
>> In the triple-term version has rdf:occurrenceOf so there is a triple 
>> to maps the blank node / URI to the 3-tuple of s,p,o that had the 
>> effect of OT.
>
> Sorry, confused. It’s not clear that <http://example/occ1> is 
> associated with a single occurrence, multiple occurrences, or possibly 
> no occurrence. Is there still some role for rdf:occurrenceOf?

I'm beginning to think there is a role for a relationship to be recorded 
in the RDF somehow to go from occurrence name to what it is an 
occurrence of.

At the SemTF (2023-23-22), having inference on triple terms was seen as 
problematic in the general case. That was the motivation for 
thenamed-occurence-as-RDF term 
<https://github.com/w3c/rdf-star-wg/wiki/Semantics:-Andy's-proposal> 
from Enrico.

Maybe it is the "triple token" (a 3-tuple of S/P/O but not a triple with 
all the model theory implications).

     Andy

>
> Gregg Kellogg
> gregg@greggkellogg.net
>
>>
>>    Andy
>>
>> [1] 
>> https://github.com/w3c/rdf-star-wg/wiki/Semantics:-Andy's-proposal#semantics
>>
>> [2] Apache CommonsRDF : https://commons.apache.org/proper/commons-rdf/
>>
>

Received on Tuesday, 2 January 2024 14:07:57 UTC