Re: Consolidating triple/edges

On Tue, Dec 19, 2023 at 1:06 PM Andy Seaborne <andy@apache.org> wrote:
>
>
>
> 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.

Most certainly.

> (and, yes, having a fixed predicate isn't great)

I think it depends on what kind of predicates we deem necessary for
the use cases. If these are both precise and general enough with some
specific property (precise like rdf:type is precise and general,
perhaps unlike rdfs:value), then it could be somewhere between good
enough and a Good Thing™.

(I'm thinking that e.g. rdf:states or rdfs:statementOf might do. And I
still hope it'll bring us what we need to, down the line, clarify the
various patterns that named graphs are used for today. As in how to
define the various more explicit relationships needed to state the
various possible uses that today are "cramped" together in the
"pairing" of a resource name and an RDF graph. And upon that, their
sought after semantics. We're already dipping into that with
transparency vs. opacity...)

> 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 .... .

Yes, I agree (likely rdf:Triple). Just like this:

    <a> rdfs:label "a" .

entails:

    <a> rdfs:label _:a .
    _:a rdf:type xsd:string .
    _:a rdf:type rdfs:Literal .

right? But not:

    "a" rdf:type xsd:string .
    "a" rdf:type rdfs:Literal .

unless we're using generalized RDF?

I wonder if it is inconsequential to allow triple types as subjects in
RDF 1.2 Full but not literals? I'm not suggesting we allow the latter,
but it would kind of make sense if we do the former. For me, that
would have to come with some *major* (uppercase) warnings and safety
mechanisms (at least in syntax; perhaps also not expected to be
storable in graph stores), but there is logic to it.

Again, to be clear: I am (of course) not opposed to facts about
universals; I've just been saying that it's the occurrences/uses of
them that we (commonly) need to talk about (in most use cases,
especially the ones using annotations). The universals are for
advanced, disciplined usage (logic, reasoning).

Cheers,
Niklas

>      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 14:58:50 UTC