Re: Consolidating triple/edges

On 19/12/2023 09:48, Niklas Lindström wrote:
> Hi Pierre-Antoine,

> Would it be too conservative to ask to keep triple term types
> (univerals) as subjects for generalized RDF 1.2? I'm really worried
> about "too much rope" for general users, to commit the same error as
> in the seminal example. But from another perspective, perhaps
> generalized RDF and Notation 3 could be more commonly defined?

Turtle syntax can help the user.
(and, yes, having a fixed predicate isn't great)

The idea of 1.2 profiles "basic" and "full" was that if in "basic" no 
triple terms appear, the it has consistent entailment behaviour.

I'd expect an entailment such as:

    <<( :s :p :o )>> rdf:type .... .

     Andy

> To be consequent, if triple terms are added to RDF, generalized RDF
> 1.2 should already allow that, along with using triples as predicates
> (which to me is just as incomprehensible as using literals there; but
> it already allows that in 1.1 [1]).
> 
> All the best,
> Niklas
> 
> [1]: https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf
> 
> 
> 
> On Mon, Dec 18, 2023 at 3:24 PM Pierre-Antoine Champin
> <pierre-antoine@w3.org> 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)
>>
>

Received on Tuesday, 19 December 2023 12:06:28 UTC