SPARQL* / SPARQL star

[akuckartz]

Why?

This helps to enable the Property Graph Community to use SPARQL.

Previous work

https://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/

Proposed solution

Considerations for backward compatibility

[lisp]

was there any consideration given during the 1.0 or 1.1 processes to the possibility of supporting n3 formulae. if this process is going to propose a bnf change, it could be worthwhile to go beyond sparql*

[lisp]

was there any consideration given during the 1.0 or 1.1 processes to the possibility of supporting n3 formulae. if this process is going to propose a bnf change, it could be worthwhile to go beyond sparql*

[lisp]

possibly of interest in relation to this topic : https://lists.apache.org/thread.html/rf5c6705dca40020324ea15546df14e852e5c80ed46cef60fc071d6ab%40%3Cusers.jena.apache.org%3E

[afs]

To connect the dots: Discussion of RDF/SPARQL is happening in the RDF* Community Group

https://www.w3.org/community/rdf-star

https://lists.w3.org/Archives/Public/public-rdf-star/

[TallTed]

Contrary to the above comment from @afs, there does not now appear to be any RDF W3 Community Goup. The link above gets a 404. I do believe I recall seeing RDF mentioned in the description of some Community Group (possibly it was the RDF-DEV CG?), but the CG index page no longer shows me any such mention, whether present, past, or proposed.

[afs]

https://w3c.github.io/rdf-star/

[akuckartz]

This is the community group hosting the rdf-star mailing list: https://www.w3.org/community/rdf-dev/

[TallTed]

So, to sum up...

The RDF-DEV CG has a sub-group, called simply RDF*, which provides minimal documentation of itself on the sub-group homepage. The sub-group homepage does link back to the parent group; that's good.

The RDF* sub-group has a primary mailing list which is entirely distinct from (and far more active than) the parent group's mailing list. (I am moderately noisy on the former, and fairly quiet on the latter.)

The full relationship between the parent group and sub-group is not clear. I would generally expect the parent group to document any sub-groups on its homepage, and for that documentation to be echoed on the sub-group's homepage; I don't know why that is not done here.

The lack of any sort of charter or purpose description for the sub-group is its own challenge.

Finally, especially but not only given current traffic content on the RDF mailing list, I seriously question whether the RDF project (which it is important to note has not firmed up on which of the competing RDF-PG or RDF-SA modes is to be the default, or only, or otherwise; nor what its actual relationship to RDF is [successor? distant cousin? no relation other than the lexicals in its naming?]) is mature enough to spawn consideration or development of a SPARQL (which must also know whether it will be SPARQL-PG or SPARQL-SA, etc.), not to mention Turtle/-SA/-PG, JSON-LD/-SA/-PG, Trig/-SA/-PG, etc.

This is a very tangled web indeed.

[akuckartz]

@TallTed

... has not firmed up on which of the competing RDF-PG or RDF-SA modes is to be the default ...

There is consensus in the group since some time that there will be no "modes".

[TallTed]

@akuckartz

There is consensus in the group since some time that there will be no "modes".

I think I've seen consensus that the "modes" will not be dynamically switchable, and may not both be implementable in a single engine (at least in a single instantiation), nor possibly applicable to a single data file/repository; and possibly that these "modes" will become the base of different specs (i.e., RDF* may not switchably encompass/include both, but there may well be competing specs for RDF*-SA and RDF*-PG).

There certainly remains discussion (within the past few days!) on that mailing list of differences in features/functionality of SA vs PG, and of which of these has more appeal in the marketplace (e.g., for whether an embedded triple can be described without being asserted, or is itself asserted by simply being embedded in the description thereof), which says to me that the overall question of these "modes" is not yet settled.

[akuckartz]

@TallTed About half of what you write is FUD. Linking to the entry page of the mailing list proves nothing. There are discussions about semantics, yes, but as far as I am aware nobody recently proposed to reintroduce modes.

[lisp]

please do not close this issue.
independent of the either the quality of the administration of that community group or the coherence of the discussion on its mailing list, this issue remains a legitimate link to that process, as its outcome will be relevant for any future sparql versions.

[TallTed]

@akuckartz --

About half of what you write is FUD. Linking to the entry page of the mailing list proves nothing. There are discussions about semantics, yes, but as far as I am aware nobody recently proposed to reintroduce modes.

I believe this may be the first time I've been accused of FUD-mongering. I believe that accusation is baseless, in support of which retort I quote from a message of just a few hours ago, from @hartig himself --

Whether such embedded triples are considered to be asserted is still under discussion. This is essentially the decision between choosing SA mode (embedded triple are not asserted) and PG mode (embedded triples are asserted). The current draft spec captures SA mode.

-- and from @rat10, a summarization of existing implementations on 2020-08-15 --

 SA  PG  Implementation  Notes - Documentation

     +   AllegroGraph    in the works - https://lists.w3.org/Archives/Public/public-rdf-star/2020Aug/0021.html
     x   AnzoGraph       https://docs.cambridgesemantics.com/anzograph/v2.2/userdoc/lpgs.htm?Highlight=rdf
     x   BlazeGraph      https://github.com/blazegraph/database/wiki/Reification_Done_Right
 x       GraphDB         http://graphdb.ontotext.com/documentation/9.2/free/devhub/rdf-sparql-star.html
 x       Jena            https://jena.apache.org/documentation/rdfstar/
 +   +   N3              deferred - https://github.com/w3c/N3/issues/27#issuecomment-644768502
 x       rdf4j           https://rdf4j.org/documentation/programming/rdfstar/
 x   +   rdfjs/N3.js     PG may become configurable soon - https://github.com/rdfjs/data-model-spec/pull/165
 x   x   RubyRDF         http://rdf.greggkellogg.net/yard/file.rdf-README.html#rdf-rdfstar
     x   Stardog         https://www.stardog.com/docs/#_edge_properties

I see a tendency towards PG mode. Comments from SA implementers suggested that they chose this approach also because going from SA to PG is easier than the other way round. Also some PG implementers don’t seem to be particularly enthused about SA mode.

In other words, modes are still under discussion.

(For the benefit of people new to this topic, "PG mode" is "Property Graph" mode, and "SA mode" is "Separate Assertions" mode.)

[akuckartz]

@TallTed The use of the word "mode" is a result of the history of the discussion. There is consensus that in the end there needs to be a single "mode" or semantics. Otherwise interoperability would be severely reduced.

That different preliminary implementations (created months or years ago) use different semantics is unfortunate - and one reason why a common specification is necessary. On the other hand these implementations and experiences with them are valuable input to the ongoing discussion.

[afs]

The categorisation of Jena (and others) is not complete and not claimed to be. It is an overview.

The reality is that PG and SA are quite close to each other, not widely different. Of course, the discussion is about the differences.

[afs]

"close" appears to be nothing more than clicking the "close" button by mistake (same timestamp as the reopen). It's easy to do.

[TallTed]

@akuckartz --

Rather than get hung up on my use of "mode", which I agree might imply something switchable in current and future implementations of RDF*, you can read "style" or "flavor" or "variant", which I hope you can read to imply something that needs to be decided one way or the other during the ongoing spec development.

The differentiation between "RDF-SA", "RDF-PG", "original draft RDF paper", or otherwise, matters to me, especially when someone talks about having implemented "RDF" without making plain which of these they mean.

RDF needs to figure out what it is, before anyone can truly say they've implemented it, and before anyone can reasonably embark on building something that interoperates with it, to wit, SPARQL, Turtle, TriG, etc*.

[TallTed]

@afs --

The reality is that PG and SA are quite close to each other, not widely different. Of course, the discussion is about the differences.

PG treating an embedded triple as having been asserted by the embedder, while SA treats that embedded triple as having been talked about by the embedder, may not be wide, but I hope you can agree that it is a substantial difference.

This and the other differences between SA and PG (and "original paper", and any other variants there may be) should be clearly listable, in order to support consideration of any decision of which will be the basis of the presumed eventual final spec -- but I have yet to see such a clear list. Perhaps I've missed something somewhere?

[afs]

There is a lot on the RDF mailing list about differences but if you think there is something missing such as a side-by-side comparison would you care to contribute by sending it to the RDF mailing list?

[TallTed]

@afs -

I do not believe I sufficiently understand the differences among RDF-PG, RDF-SA, "original" RDF, "current" RDF, and RDF to produce such a side-by-side comparison.

I do understand enough to have recognized that when someone raises concerns about some element (or its lack) in one flavor, the response is frequently that "that element is not (or is) in this other flavor, so no problem", and vice versa. This says to me that both/all flavors are still in play, in order to cover all those bases -- but covering some of those bases inherently requires not covering some other base, so I don't understand how all are being addressed. Perhaps the final UCR doc will bring understanding.

That said -- I would hope that those who originated and/or defend the several flavors of RDF* (of which I cannot yet say strictly whether I support or oppose any, though I do oppose assertion-by-embedding which suggests I will oppose PG) have that understanding.

[hartig]

Status update: the Final Community Group report about RDF-star and SPARQL-star has been published on Dec. 17, 2021. https://www.w3.org/2021/12/rdf-star.html

Since then, the RDF-star task force of the RDF-DEV community group has been working on a charter for a W3C RDF-star Working Group. The draft charter is now put to vote by the W3C members. See: https://lists.w3.org/Archives/Public/public-new-work/2022Jul/0000.html

[TallTed]

I think it's also worth mentioning here (and possibly changing the issue title to reflect) that while SPARQL* and SPARQL-star (and RDF* and RDF-star) are pronounced the same, they are radically different in meaning.

RDF* (and the associated SPARQL*) was an early experimental draft of what has evolved (for many reasons) into the currently drafted and reported (and heading toward proposed WG) RDF-star (and associated SPARQL-star).

While many reading this may already know the above, others reading this issue (even just its title) may not, and confusion is likely if the old names continue to be used instead of, and treated as synonymous with, the new.