Re: GASP-mode

> On 7. Sep 2020, at 10:51, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> 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

Yes, and I just wanted to put it in perspective. I hope I didn’t sound like I tried to claim authorship for that idea.

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

I know nothing about defining query semantics so I can’t comment on your argument but I still wonder how two modes - SA and PG - make things easier when you also could just base the << … >> "triplet" on RDF standard reification. And this is really not a nefarious attempt to drag shiny new RDF* back into the swamps of the RDF of old.

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

We’ll see. But even if that "all-encompassing theory" never surfaces it doesn't hurt to think about how RDF* can fit into and extend RDF as seamless as possible, especially as it’s still early days.

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

I hope you don’t regard my comment as obstructive. If the relation to RDF is however of such low priority at this point then I can indeed not contribute much. But the more the paths diverge the harder it will be later to reconcile them.

Best,
Thomas


> Best regards,
> Olaf
> 
> 
>> - 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 Monday, 7 September 2020 09:56:46 UTC