GASP-mode

IIRC the reason that SA mode was introduced was an unhappiness with the << … >> syntax as  originally proposed, namely that it breaks the BGP intuition and modelling/querying style. The explicit addition of the annotated triple in a second statement was meant to make the base statement reachable by idiomatic query operations. At least that’s how I understood the idea behind SA mode. The currently favored PG-mode syntax however puts the annotation behind the statement - in [[ … ]] or {|…|} - and resolves this concern without the need for a second mode. 
The other argument pro SA mode is that it allows to annotate unasserted statements. That is an important but niche use case and it is already covered by RDF Standard Reification. In fact it’s probably the only thing that RDF Standard Reification is actually good for. As it’s rather niche the triple bloat induced by the reification quadlet isn’t much of a concern (plus it has a practical advantage: such unasserted statements can never accidently pop up in the result set of an unassuming query). The same could be true for a << :a  :b  :c >> node, depending on how it is defined.


Therefor I’d suggest a two-fold approach:

1/ for RDF*-style annotation
- go with PG-mode in the modified, appending syntax 
      :a  :b  :c  {| :d  :e |} .
  to annotate statements that are actually asserted
- use workarounds like inverse properties for less simplistic use cases where the annotated statement would (but in this syntax can’t) occur in the object position

2/ for annotating unasserted statements
- let the <<…>> syntax be syntactic sugar for the RDF Standard Reification quadlet
      _:x  a  rdf:Statement ;
           rdf:subject  :a ;
           rdf:predicate  :b ;
           rdf:object  :c ;
           owl:sameAs  << :a  :b  :c >> .
- if needed let some << :a  :b  :c >> node automatically expand to a reification quadlet
- don’t define it in the context of RDF* but in RDF
- the model-theoretic semantics of RDF Standard Reification are undefined but so are those of RDF*. Even if statement and annotation look more tightly connected - at least in PG mode - they aren’t (and IIUC they can’t be without a semantic extension to RDF). 

IMO this keeps RDF* conceptually cleaner and aligns it better with RDF - which also means less loose ends and overlapping concerns to handle when developing a real meta modelling solution for RDF.


I’m trying to keep an eye on the broader picture. Viewed from RDF the RDF* extension is still a hack: it has no model-theoretic semantics, the relation between statement and annotation is merely syntactic, the relation to named graphs is undefined, probably more. I’m concerned that this will be cause for some severe trouble down the road. The cleaner and more focused the definition of RDF* the better. I’m not saying that it has no merit: it definitely covers an important usecase. But, for example, I don’t buy into the view that there is a fundamental difference, an orthogonal relation even between RDF* and Named Graphs, because: really, where is the fundamental difference between annotating one, two or more triples? There is none, neither in theory nor in practice! 

So it will, at some point, be important to be able to define a sound maping between RDF* and a meta-modelling approach that doesn’t care about the number of triples it annotates. That could be Named Graphs or an extension of RDF* or something else entirely, who knows. The current PG mode of RDF* might then just become syntactic sugar for a more complete solution. The current rush to implementation is understandable given how long this problem has been lingering but it is also dangerous as the needs and mechanics of sound meta modelling in RDF are still not properly understood.


That said, I would welcome an extension to the <<…>> syntax that allowed it to address actual statement occurrences in named graphs, e.g. be prepending the graph name like so:
 https://my.graph.name?triple=<<...>>
This would definitely address a specific triple occurrence as there can’t be more than one triple of a given type in any graph. It would however, in line with RDF Standard Reification, not assert said triple - which nmakes sense as one might not have write access to a distant named graph but still might want to annotate some triple in it. If the triple doesn’t exist the address points nowhere - that happens and might be unexpected, but not harmful.
By extension the unprefixed <<…>> would be a shortcut for something like
 https://w3.org/rdf?abstractStatementType=<<...>>
making the thing an IRI, unmistakebly, which IMHO makes a lot more sense than interpreting it as a literal (but notice the H in IMHO - this is more a very strong feeling than an informed position as I still don’t fully understand the reasoning behind the approach to interpret << … >> nodes as literals). The "abstractStatementType" string is of course unpractical and overly verbose, but used here to be clear that this thing doesn’t refer to any concrete statement.


Ahem, there’s still no name for that << … >> thingy, right? Maybe call it a "triplet"?


Thomas

Received on Friday, 4 September 2020 09:15:06 UTC