Re: Consolidating triple/edges

Olaf,

I don't think the syntax can constraint at the abstract syntax level 
although concrete syntax in Turtle can help avoid the situation.

We define rdf:occurrenceOf as a functional property (define in text 
because RDFS can't express that).

Maybe ":s1 owlsSameAs :s2" etc

It isn't a unique situation. In common use, rdf:first/rdf:rest are 
expected to be functional, and have no cycles and use blank nodes; 
reification and container vocabulary tend towards unique unique triples.

While this is in the RDF namespace, it is general: RDF is not expressive 
enough on it's own to exclude it.

As Gregg notes, it happens. It's the nature of RDF.
I think we can have our examples use blank nodes.

     Andy

On 15/12/2023 00:28, Gregg Kellogg wrote:
> I’d say it can’t be a syntactic constraint but may be a semantic inconsistency due to open-world assumption.
> 
> Gregg Kellogg
> Sent from my iPhone
> 
>> On Dec 14, 2023, at 3:41 PM, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>
>> Andy,
>>
>> Dec 12, 2023 21:59:24 Andy Seaborne <andy@apache.org>:
>>> [...]
>>>
>>> ## Turtle
>>>
>>> Add to Turtle a new statement (grammar rule 2):
>>>
>>>      << occurrenceName | :s :p :o >> .
>>>
>>> This names an occurrence of the triple s p o.
>>>
>>> The triple is not asserted, keeping "assertion" and "occurrence" as orthogonal concepts even if they might commonly be used together.
>>>
>>> occurrenceName is a URI or blank node, including [] (the ANON terminal rule 47 in Turtle - no triples inside the []).
>>>
>>> It is better to have the name first to allow for split lines and modified annotation syntax below.
>>>
>>>
>>> ## N-Triples
>>>
>>> In N-Triples, reflecting the RDF abstract data model, there is a property to relate occurrence to a triple term.
>>>
>>>      :occurrenceName rdf:occurrenceOf << :s :p :o >> .
>>
>> What should happen if someone writes the following two lines?
>>
>>    :occurrenceName rdf:occurrenceOf << :s1 :p1 :o1 >> .
>>    :occurrenceName rdf:occurrenceOf << :s2 :p2 :o2 >> .
>>
>> Should the abstract syntax contain a constraint by which such a multi-use of :occurrenceName is defined to be invalid? Or should this be treated as an inconsistency under whatever entailment regime that is concerned with such rdf:occurrenceOf statements?
>>
>> Thanks,
>> Olaf
>>
>>
>>> There are triples terms in the data model
>>> (RDF-Concepts - section 3.1 : editors draft [2]).
>>>
>>> Renaming "quoted triple" as "triple term" would be better because it has less implication of the usage.
>>>
>>> The NT syntax would be available in Turtle in the same way that rdf:first is available in Turtle - and with the same expectation that it would rarely be used.
>>>
>>>
>>> ## RDF Graph Merge
>>>
>>> Graph merge happens as before - blank nodes need to be kept apart.
>>>
>>>
>>> ## Annotation
>>>
>>> This gives the modified annotation syntax as per Thomas's email [1]:
>>>
>>>>      :liz :spouse :dick { id:1 | :start 1964; :end 1974 |} .
>>>>      :liz :spouse :dick { id:2 | :start 1975; :end 1976 |} .
>>>
>>> Slight syntax tweak: For SPARQL, reusing { has to be careful because { is a group start.
>>>
>>> :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 .
>>>
>>> and asserting:
>>>
>>>      :liz :spouse :dick .
>>>
>>>
>>> ## Named occurrences in term slots
>>>
>>> << occurrenceName | :s :p :o >> could also be used in a subject or object slot with the occurenceName being the RDF term for subject or object (c.f. RDF collections and predicate object lists) for use with unasserted triples:
>>>
>>> << [] | :s :p :o >>
>>>         :start 1964 ;
>>>         :end 1974 .
>>>
>>>       Andy
>>>
>>> [1]
>>> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0024.html
>>>
>>> [2] https://w3c.github.io/rdf-concepts/spec/#section-triples
>>>       (as of 2023-12-10)
>>
>>

Received on Friday, 15 December 2023 09:26:39 UTC