Re: GASP-mode

Hi Thomas,

On fredag 4 september 2020 kl. 11:14:42 CEST thomas lörtsch wrote:
> 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.

No. The idea of introducing the term "SA mode" was to have a name for the 
option to define RDF*/SPARQL* such that it can be used to annotate a triple 
without asserting that triple (as opposed to the alternative option, named "PG 
mode", in which the annotated triple would also be asserted implicitly).

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

Yes, that's part of what the recent discussion has been converging to (in 
addition to using the original Turtle* syntax (<<...>>) for SA mode).

> 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

It needs to be defined in the context of RDF*/SPARQL* to have a formal query 
semantics for SPARQL* under SA mode. Just describing everything in terms of 
transformations on an extended file format (Turtle*) is not really a clear 
formal foundation for systems that want to support SPARQL* under SA mode. 

Regarding the other concerns and the things that you mention, I am looking 
forward to an all-encompassing theory that might eventually appear and cover 
everything on your wish list. However, for the moment we have a concrete 
proposal on the table that may not cover every use case but there are people 
who seems to be happy with what it can do and there are vendors who are eager 
to support it.

I also want to emphasize that we are not here to create a W3C Recommendation 
(at least, that's not my goal at this point). Instead, we are here to create a 
Community Group report that documents the proposal so that all relevant 
parties (primarily, users of the proposal and vendors who aim to support the 
proposal) can be on the same page.

Of course, the CG report might later be input to a W3C WG that works out a 
recommendation and, then, may also look into other concerns. However, I think 
that this should not prevent us from making progress regarding the report that 
introduces the RDF*/SPARQL* approach that is agreed on by users and vendors 
here in the group.

Best regards,

> - 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:<<...>>
> 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<<...>>
> 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 Monday, 7 September 2020 09:25:48 UTC