Re: Consolidating triple/edges

Thomas,

Dec 14, 2023 17:50:48 Thomas Lörtsch <tl@rat.io>:
> [...]
>
> ## Tokens vs Types
>
> I’d like to completely turn the table on tokens vs types: a reference to the type has to explicitly address the type. A relation reciprocal to rdfx:occurrenecOf can achieve that e.g.
>
>    :T rdfx:typeOf << :s :p :o >>

If I understand correctly, you would like the subexpression  << :s :p :o >>  in the previous line to be considered as a token of the triple type (:s, :p, :o)? And you would like the meaning of the previous line to be that the IRI :T is meant to denote this triple type?

If so, what would you expect to happen if someone writes the following?

   :T rdfx:typeOf << :s1 :p1 :o1 >> .
   :T rdfx:typeOf << :s2 :p2 :o2 >> .

Which triple type would :T denote in this case (if any)?

> OTOH, any reference to << :s :p :o >> is defined to implicitly references a token

Always the same token or always a different one? In other words, should the two occurances of the subexpression  << :s :p :o >>  in the following two lines be understood to "implicitly reference" the same token or two different tokens?

   << :s :p :o >> :p2 :o2 .
   << :s :p :o >> :p3 :o3 .


Thanks,
Olaf


> and may either provide a custom name or will be provided with a new blank node to name the reference.
>
>
> ## Syntax
>
> We should try to make the naming syntactically as uniform and predicatble as possible. The nested graph proposal uses a pair of square brackets [] prepending constructs to indicate the name. If a custom name is given it is entered into that pair. That violates the rules for [] in Turtle/TriG but seems to parse unambiguously.  Not providing any name syntactically and still assuming the presence of a blank node name is a bit more tricky.
>
>     :liz :spouse :dick [id:1]{| :start 1964; :end 1974 |} .
>     :liz :spouse :dick {| :start 1975; :end 1976 |} .       # _:id2
>
>     [] << :s :p :o >> :start 1964 ; :end 1974 .
>
> In any case: if it doesn’t parse without a prepended name, then prepend a [].
>
>
> ## Unasserted vs Asserted
>
> Why not define a property that not only references a token, but also creates the triple, e.g.:
>
>    :liz :spouse :dick [id:1]{| :start 1964; :end 1974 |} .
>
> mapping to
>
>     id:1 rdfx:assertionOf << :liz :spouse :dick >>
>         :start 1964; :end 1974 .
>
> instead of
>
>     id:1 rdfx:occurrenceOf << :liz :spouse :dick >>
>         :start 1964; :end 1974 .
>     :liz :spouse :dick .
>
> That way we get identifiers for each triple occurrence together with the triple being asserted - direct identification, not earyl optimization. See above why that is important.
>
> All this unasserted business may seem a bit eccentric, but it’s the key to any sort of configurable semantics like quotation etc. It therefore has huge potential - if done right.
>
>
> ## SPARQL sugar
>
> You compare the occurence-based shortcut relation to syntactic sugar for RDF lists, which is fine, except that querying those lists is a hardship. Same for RDF/XML’s syntactic support for RDF standard reification. Any kind of RDF syntactic sugar also needs proper support in SPARQL to be effective in practice.
>
>
> ## Triple terms vs Graph terms
>
> Just for completeness: all for this can easily be expanded to graph terms. The syntax
>
>     []{ :s :p :o. :u :v :w }
>
> is explored in the nested graph proposal.
>
>
> ## Graph Terms vs Named Graphs
>
> I like Adrians example [0] of a complicated named graph based application and I’m taking that serious. However it should also be clear that triple/graph terms in the end are always stored in a way very similar to named graphs. There is just no other way in a quad based system. Triple/graph terms can be represented as named graphs, named graphs can be represented as graph terms. It’s a practical question of how to encode belonging/membership: syntactically as nested graphs, via a new term type as in RDF-star that transforms a triple into a term at the surface (but NOT in the underlying storage layer, for obvious performance reasons), via explicit binding relations as Niklas proposes [1] (and as Dydra implements nested graphs), etc. The main question is how to ensure that those binding relations don’t get lost in the process, but that IMHO is true for any solution. Nested graphs can be serialized to graph terms, which are just an extension of triple terms. That requires an additional en/de-coding step to fit them into an environment that reserves named graphs to its own purposes. That extra step is the price that those applications have to pay for being so particular about their use of named graphs. That’s only fair, and probably still economical for them.
>
>
> ## Term types vs Datatypes
>
> The most fundamental grievance with RDF-star is the introduction of a new term type when a new datatype of type RDF/TTL would suffice. All I proposed above is readily imlpementable in the nested graph proposal, which does map to TriG and regular N-quads and such a datatype (and even Turtle and N-triples, but that’s another discussion).
>
>
> Best,
> Thomas
>
>
>
> [0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0019.html
> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Nov/0032.html
>
>
>>    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 Thursday, 14 December 2023 23:01:28 UTC