Re: One kind of "occurs" relation or many?

Dear Thomas,

On 19/12/2023 15:27, Thomas Lörtsch wrote:
>
>> On 19. Dec 2023, at 10:09, Pierre-Antoine Champin<pierre-antoine@w3.org>  wrote:
>>
>> Andy,
>> On 18/12/2023 22:08, Andy Seaborne wrote:
>>> That triggered a question:
>>>
>>> Is rdf:occurenceOf , or whatever we name it, the only relationship between an occurrence/token in the domain, and a triple type/term?
>>>
>>> Are there useful subproperties of rdf:occurenceOf?
>>>
>>> While these could be by (rdf:)typing the occurrence separately, subproperties can be clearer and don't "loose" the type when looking at just the occurrence-term triple.
>> I agree, and this is the main reason I have fought for a long time against the idea of introducing a "default" predicate between the occurrence identifier and the triple term...
>> But now, I have come to consider that the pros overweight the cons.
>> NB: inserting a triple using the more specific subproperty of rdf:occurrenceOf (or whatever we name it) can still be done
> I’d rather have the most basic arrangements introduced explicitly.
You can't do more "basic" than having /one/ very general predicate.
Any further refinement would raise legitimate questions: why did we 
chose to include distinction A and leave distinction B aside?

Don't get me wrong: I'm not saying that the distinctions you are making 
below are uninteresting. On the contrary. But I don't think that this 
group has the skills nor the time to produce an appropriate ontology of 
the "triple occurrences". Nor do I think that it should be part of the 
RDF vocabulary.

   pa

>   The shorthand syntax asserts the statement right away. That should be captured in the property, e.g.
>
>     :s :p :o  {| id:1 | :y :z |}
>
> would be mapped to
>
>     :s :p :o .
>     id:1 rdfx:assertionOf << :s :p :o >> ;
>          :y :z .
>
> (and 'id:1 rdfx:assertionOf << :s :p :o >>' would always entail ':s :p :o .')
>
>
> Another plausible option is the "unasserted assertion" as we keep calling it for lack of a more sensible name, e.g.
>   
>     id:1 rdfx:quoteOf << :s :p :o >> ;
>          :y :z .
>
> without asserting ':s :p :o .'.
>
> The difference - ':s :p :o .' either being asserted or not - is rather drastic, so different properties seem well justified IMO. Imagine people using rdfx:occurrenceOf and useres not knowing if they intended to assert the annotated statement or not. That doesn’t make sense and adds an unnecessary source of confusion.
>
>
> Also, as far as I’m concerned, the CG semantics of quoted terms should remain unchanged because it provides a basis for other interesting semantics. Then there’s also the standard reification semantics of being unasserted, but referentially transparent, which as the use cases have shown has a lot of practical applications. That would then be
>
>     id:1 rdfx:reportOf << :s :p :o >> ;
>          :y :z .
>
> again without asserting ':s :p :o .' ("reportOf" as in "reported speech").
>
>
> The nested named graph proposal provides yet one more variant - records, which are asserted but referentially opaque - and proper syntactic sugar [0].  Maybe check it out over the holidays.
>
>
> Note to those that are confused why I "suddenly" am in favor of referentially opaque semantics: I never was against it per se, I just didn’t want it to be the default semantics, and especially not for the shorthand syntax.
>
> Best,
> Thomas
>
>
> [0]https://github.com/rat10/nng/blob/main/citationSemantics.md

>
>
>
>>    - manually, in addition to the convenient annotation syntax, if that matters to you (1), or
>>    - via some form of inference (2).
>> (1)
>> :richard :married :liz {| :m1 | :from 1964; :until 1974 |}.
>> :m1 ex:realizationOf << :richard :married :liz |}.
>> (2) (in N3)
>> :richard :married :liz {| :m1 | a ex:Realization; :in 1964; :until 1974 |}.
>> { ?o rdf:occurrenceOf ?t; a ex:Realization } => { ?o ex:realizationOf ?t }.
>>>      Andy
>>>
>>> On 18/12/2023 14:24, Pierre-Antoine Champin wrote:
>>>> Hi all,
>>>> Andy's proposal below (which I have to say I like very much) gave me an additional idea:
>>>> if we were to follow it, we could consider introducing a third profile that would sit between Basic (no triple terms) and "Full" (no restrictuon), by allowing triple terms only as the object of rdf:occurrenceOf (in an asserted triple).
>>>> A working title for this intermediate profile could be "RDFn" profile, because my intuition is that this profile covers most of what RDFn aims to do, and could be implemented in the same ways as RDFn (i.e. by adding a 4th column to triples, the 4th column being the identifier).
>>>> I see how more profile could mean more fragmentation of the ecosystem... but it could also mean that more people find an option they are happy with in RDF 1.2, and it is better if those options are clearly laid out in the spec than "improvised" by each unhappy implementer.
>>>>    best
>>>> On 12/12/2023 21:59, Andy Seaborne wrote:
>>>>> Here is an attempt to write out the details of what I think has been said recently.
>>>>>
>>>>> It is addressing "publishing information about multi-edges".
>>>>> (Ideas here are from WG members - the mistakes are mime.)
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> This preserves the uniqueness of triples in a graph, and allows independent collections of assertions about a relationship. Such collections of assertions do not get entangled on merge.
>>>>>
>>>>>
>>>>> ## 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 >> .
>>>>>
>>>>> 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)
>>>>>
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>