Re: RDF-star “baseline” document

On 4 Jun 2024, at 15:20, Niklas Lindström <lindstream@gmail.com> wrote:

1. Is the use of opaque triples as subjects necessary for conveying
intent here? Or is it more of a "design style"?

It is pure design style.

2. While calling this "annotating triples" makes perfect sense, this
naming choice seems different from the already given notion of
"annotation" for the macro of both asserting a triple and describing
occurrences thereof. As these many-to-one "annotations" appear to be
(various kinds of) concrete tokens of these opaque triples, naming the
relation something like `rdf:token` (or per #1 its inverse) may be
less confusing? (Still just as a working name of course, but to nip
some of the discussion in the bud.)

I guess this needs thorough discussion.

3. This notion of well-formedness somewhat changes the current design
of RDF.

Not really. Consider owl: while introducing its own vocabulary, it restricts its syntax to a specific grammar, and it gives an explicit semantics to the constructs of the owl grammar with the added vocabulary, and not to the unrestricted rdf constructs. We are doing the same.
I'm not saying that I necessarily like this, but it is definitely a possibility which follows already taken paths.

Today, there is a stricter abstract syntax, and then a
"radically" generalized form which allows any term anywhere (to be
able to represent e.g. the entailed rdf:type of the resource a literal
denotes). If well-formedness shouldn't merely be *added* to the mix,
it might even be consolidated with today's use of generalized RDF;
perhaps even supplant it (at least for the reasoning needs). One way
is to make the regular abstract syntax more generalized (possibly
*only* forbidding literals and triples as predicates, declaring those
as disjoint from properties). That means allowing literals as
subjects, which is "dangerous" (or outright bad), but of course still
prohibit that in well-formedness (same for triple terms, as you've
defined it).

Nobody is adding literals as subjects here.
Note that without triple terms both simple semantics and rdf semantics in this rdf-star proposal coincide exactly with simple semantics and rdf semantics in rdf 1.1.

4. Since opacity also crosses the delineation between syntax (a graph
g) and model (interpretation I of g), it needs to be easily made sense
of. The years-long debates on these forums alone are clear indications
that this is hard to make easy. It may be doable for different
audiences; for some just referencing Lisp is enough; for others, using
analogies like "stepping out of the picture/map" or "breaking the
fourth wall" might do better. And one precursor is already in RDF:
named graphs *are* such "walls", with their names being on the outside
of interpretation.

(I kind of make sense of it all by thinking of the graph names as "on
top of" the model, and triple terms "beneath" (and perhaps literals as
"jutting out on the sides")...)

I am not sure I follow you 100%.
I understand that we are very liberal: anyone can attach any concrete meaning they want to reifications and annotations, as soon as it complies to this basic principle: a reification is an arbitrary many-to-many relationship between a reifier and a transparent triple term, and an annotation can annotate at most one opaque triple term.
Examples and best practices should of course clarify these concepts.

5. Well-formedness, as "regular use of RDF" should prevent accidental
(or "naive") context shifts in the model from the domain-of-discourse
to the abstract forms of its representation (such as the seminal
mistake). While sometimes innocuous, those hard-to-spot differences
can have troubling consequences; both breaking intended meaning and
blocking interoperability a long way down the line. What we add now
(with statements about statements, and well-formedness in general)
should both help users avoid, and ideally, through carefully designed
ontologies, *get out of* such mistakes.

I expect that sadly (1) nobody will care about well formedness, but nonetheless (2) everybody will spontaneously write in the well formed fragment.
But let's see...

6. Even if syntax makes the distinction clear, it still puts the
burden of understanding it on the data creator and/or consumer (just
think of how easily newcomers mix up an IRI and its denotation). That
may be possible to overcome with semantics for bridging the
difference, so that "mistakes" can be transparently bridged after the
fact. We did touch on that in terms of the old "transparency-enabling"
notion recently; though it is not without challenges.

Is putting quotes around a triple to make it opaque (i.e., a literal) so confusing, as opposed to not put them??

7. To address #6, though I believe you have strong doubts,

You guessed it right :-)
This would belong to the realm of meta models in rdf, which reality has shown IMHO that nobody could care less :-)
But be my guest and let's add all this meta model stuff (and new axiomatic triples); it will be completely neutral wrt the semantics (and therefore the meaning) of the new rdf-constructs...
Note that you can find in the document the meta model stuff in the the definition of rdf semantics indeed. See how I called it 🤔

Cheers
--e.

I still
seek a reasonable way to stipulate an entailed relationship between an
opaque and a transparent triple. For example, from the use of an
opaque triple, e.g. (following the form from in #1 and #2 above):

   <#stmt1> rdf:tokenOf <<' :s :p :o '>> .

if this would be necessarily inferred (represented in "generalized RDF"):

   <<' :s :p :o '>> rdf:reifies <<( :s :p :o )>> .

Along with this, for transparent triple terms:

   <<( :s :p :o )>> a rdf:Relationship ; rdf:subject :s ;
rdf:predicate :p ; rdf:object :o .

(or a variation thereof, reasonably distanced from but related to
classic rdf:Statement tokens).

Them, connecting the two, we'd get:

   <<' :s :p :o '>> rdf:reifies [ a rdf:Relationship ; rdf:subject :s
; rdf:predicate :p ; rdf:object :o ] .

And, with:

   rdf:subject owl:propertyChainAxiom (rdf:tokenOf rdf:reifies rdf:subject) .
   rdf:predicate owl:propertyChainAxiom (rdf:tokenOf rdf:reifies
rdf:predicate) .
   rdf:object owl:propertyChainAxiom (rdf:tokenOf rdf:reifies rdf:object) .

this would be true:

   <#stmt1> rdf:subject :s ; rdf:predicate :p ; rdf:object :o .

thus fully connecting classic reification and opaque triple tokens.

And there is more to it, such as how this enables modelling the types
of general (many-to-many) reifiers, using OWL, by declaring how a
specific type of reifier is restricted to specific kinds of predicate
uses. (I.e. make it possible to describe the relationship between the
`:Marriage`class  and the `:spouse` property.) But I'll spare you more
such metamodelling extravaganza for now.

Cheers,
Niklas

On Mon, Jun 3, 2024 at 11:29 PM Franconi Enrico <franconi@inf.unibz.it> wrote:

Hi all,
as promised, I’ve prepared a document defining the current status of RDF-star, according to what I understood from our latest chats.
It is mainly a merge of the two previous documents about the two profiles.

The idea is that RDF with simple interpretations has two triple terms (transparent and opaque) and unrestricted syntax for them. There is no other adde special vocabulary.
On the other hand, RDF with RDF interpretations introduces the special vocabulary for reification, restricts the syntax of triple terms as usual (the “well formed” fragment), and specifies the functionality of the annotation in the reification of opaque triple terms.

You may notice that I changed rdf:annotationOf with rdf:hasAnnotation, in order to allow for direct literal annotation to opaque triple terms - not orthodox but useful I guess.

Here it is:
https://github.com/w3c/rdf-star-wg/wiki/RDF-star-"baseline"


Cheers
—e.