Re: streamlining the baseline

HI Thomas,

In principle, are you suggesting that an asserted triple should no
longer mean just "the triple is in the graph", but either that or when
it is encoded as a triple literal which is used as an object of a
triple in the graph (with some predefined predicates)? I.e. that,
AFAICS, the RDF semantics have to be extended so that each extension
of a property also must take into account, recursively, some other
property extensions, wherein an extension membership (a "statement")
is encoded as a literal? And, presumably, this would similarly have to
be added to the definition of basic pattern matching in SPARQL?

While this is not where my expertise lies, I have a hard time seeing
how this simplifies what an asserted triple is. Unless I'm missing
something, I'd rather stay on the currently agreed route where
assertion and reification are separate and complementary.

The use of literals, as discussed, also suffers from the problem of
blank node identifiers [1], which are not global, but local to an RDF
document *at parse time*. I believe the CDT [2] proposes to treat each
literal as its own document. But this is not easily (if at all) made
workable for the needs of RDF-star.

Best regards,
Niklas

[1]: <https://www.w3.org/TR/rdf11-concepts/#section-blank-nodes>
[2]: <https://awslabs.github.io/SPARQL-CDTs/spec/latest.html#dfn-bnl2bn>


On Sun, Jun 16, 2024 at 10:19 PM Thomas Lörtsch <tl@rat.io> wrote:
>
> as was discussed in the semantics TF meeting last friday we could streamline the abstract syntax of the baseline proposal by deriving triple term occurrences with different semantics from only one primitive, the abstract triple term - the '<<( :s :p :o) >>' in n-triples - by defining appropriate properties, e.g. for referentially transparent occurrences
>
>      :reified_x rdf-star:reificationOf <<( :s :p :o )>> .
>
> and for referentially opaque occurrences
>
>     :annotated_y rdf-star:annotationOf <<( :s :p :o )>> .
>
> this seemed like a good idea to some people (including me) and IIUC Enrico might incorporate it into an update to the baseline proposal.
>
>
> for one, it occurred to me later (again, and the original idea is not mine) that we could then also replace the abstract triple term by a literal of a to be defined RDF datatype, e. g.:
>
>      :reified_x rdf-star:reificationOf ":s :p :o"^rdf:ttl .
>      :annotated_y rdf-star:annotationOf ":s :p :o"^rdf:ttl .
>
> it seems that this wouldn't require any change to the RDF 1.1 abstract syntax at all, which would be nice. also, as recent works by the Amazon Neptune team have shown, there is more interest in and more uses for an RDF literal datatype. it would be a generically useful addition to the RDF toolbox.
>
>
> secondly, i'd like us to think again about the different semantics we need. both options discussed in the current proposed baseline are unasserted, one of them is referentially transparent and the other one to some degree opaque. it bothers me a great deal that we provide no option to assert and annotate statements in one go (the same when querying). this makes statement annotation unnecessarily tedious in the majority (*) of use cases (and it introduces ambiguity when annotated statements occur both in asserted and unasserted form). we should change this and make the referentially transparent triple occurrence asserted (as it was conceived in the original RDF* proposal) whereas the referentially opaque variant may remain unasserted.
>
> we could also define all 4 permutations of asserted/unasserted and referentially transparent/opaque, e.g.
>
>     # stating - asserted, ref. transparent
>     ## asserting and annotating in one go
>     ## n-triples
>     :a rdf-star:statingOf ":s :p :o"^rdf:ttl ;
>         :some :Attribute.
>     ## turtle
>     << :s :p :o >> :some :Attribute.
>
>     # mention - unasserted, ref. transparent
>     ## citing, but not endorsing, without syntactic precision (eg indirect speech)
>     ## n-triples
>     :b rdf-star:mentionOf ":s :p :o"^rdf:ttl ;
>         :some :Attribute.
>     ## turtle
>     <<< :s :p :o >>> :some :Attribute.
>
>     # posit - asserted, ref. opaque
>     ## stating with exactly these terms (eg functional mapping from LPG)
>     ## n-triples
>     :c rdf-star:positingOf ":s :p :o"^rdf:ttl ;
>         :some :Attribute.
>     ## turtle
>     <<" :s :p :o  ">> :some :Attribute.
>
>     # quote - unasserted, ref. opaque
>     ## quoting, not asserting, exactly those terms (eg versioning)
>     ## n-triples
>     :d rdf-star:quotingOf ":s :p :o"^rdf:ttl ;
>         :some :Attribute.
>     ## turtle
>     <<<" :s :p :o ">>> :some :Attribute.
>
> naming of the variants and syntax variations are of course tentative proposals.
> also i've omitted the optional explicit occurrence identifiers in the turtle syntax.
>
>
> all 4 variants make sense, but the first one is without reasonable doubt the most important one.
>
>
> how precisely referential opacity is to be defined is another question. the RDF literal shouldn't  be constrained to single statements and bnodes might be treated decently by annotating their concise bounded description. alternatively the CG semantics of always transparent bnodes might be used. IRIs in ref. opaque posits and quotes would denote, but not co-denote. fully uninterpreted, syntactic opacity can be achieved via the RDF literal itself.
>
>
> the abstract syntax wouldn't change at all, but the semantics would be extended by formalizations of the different types of annotated terms: stating (same as RDF 1.0/1), mention, posit and quote.
>
>
> best,
> thomas
>
>
> (*) Andy might again denounce this as a sweeping claim, but in the absence of solid empiric data what else can we do but make good guesses.

Received on Tuesday, 18 June 2024 11:21:07 UTC