Migration from RDF-star to RDF 1.2

[Tpt]

[TL;DR]: Please reply if you have RDF-star triple term in your Oxigraph database and would love a way to migrate at the cost of slower development time

RDF 1.2 is now stabilizing and moving toward the "candidate recommendation" status. Oxigraph should implement it instead of the older RDF-star report.

RDF 1.2 does significant changes to triple terms compared to RDF-star:

• raw triple terms are now written <<( ts tp to )>> in NTriples/Turtle/... and not << s p o >>
• triple terms are now allowed in subject position
• the << ts tp to >> p o syntax is now a sugar for [] rdf:reifies <<( ts tp to )>> ; p o
• the s p << ts tp to >> syntax is now a sugar for s p [rdf:reifies <<( ts tp to )>>]

There is also the fun thing in RDF 1.2 that:

<< ts tp to >> p1 o1 ; p2 o2 .

is not anymore the same as:

<< ts tp to >> p1 o1 .
<< ts tp to >> p2 o2 .

because the first one desugarize into:

[] rdf:reifies << ts tp to >> ;
   p1 o1 ;
   p2 o2 .

and the second into

[] rdf:reifies << ts tp to >> ;
   p1 o1 .

[] rdf:reifies << ts tp to >> ;
   p2 o2 .

Because of these changes, implementing both RDF-star and RDF 1.2 at the same time transparently is not possible.

I see a few possible approaches:

1. Have a "rdf-star" vs "rdf-12" option that should be set globally and/or anywhere. It would help existing RDF-star users keep working at the cost of significantly higher code complexity but it does not help with the migration.
2. Drop RDF-star support and do not provide a migration path (only fail to load databases with RDF-star data). The users would have to figure out a migration path themselves (the convenient one of dumping into NQuads from the old Oxigraph and loading into new Oxigraph will insert a new blank node per triple term occurrence so won't work very well).
3. Provide a smart automated migration. Each triple term will be converted into a blank node which identifier is an hash of the triple term and a new triple "NEW_BLANK_NODE rdf:reifies TRIPLE_TERM" inserted in the database. This has the advantage of keeping SPARQL queries with the << s p o>> notation working but NTriples/Turtle/... serialization will change.

Note: Providing a "dumb migration" of just keeping triple terms in the database does not work because triple terms are not allowed in subject position anymore.

Based on this, I think that option 3 is the best if people need a way to migrate. If not, option 2 is much easier to implement and will free development time for something else.

[ktk]

I do not use RDF Star in Oxigraph and my take is that it was an informal CWG spec so you don't owe anyone anything. I would go for 2.

[marvindroid]

I occasionally use RDF* triples but don't really need a migration path for them (tool mainly used for experimentation so data is recreated many times). Happy to wait for the RDF 1.2 implementation and modify our data creation instead.

[Tpt]

It took me a small hour to implement option 3, all internal tooling was already there to make it smooth to implement. It has not been much more complicated than just detecting the presence of RDF-star triple terms. So Oxigraph 0.5 will ship with it.

[labra]

In rudof, we are planning to implement SHACL 1.2 to validate RDF 1.2 as well as a new experimental version of ShEx that could also validate RDf 1.2. For that, we would like to depend on the crates with the rdf-12 feature instead of the rdf-star.

However, the published crates like oxttl version 0.1.8 are still using the rdf-star, right? It would be nice for rudof if you published the new crates with the rdf-12 feature so we could start playing with the new feature.

[Tpt]

Yes! I have not released the upcoming Oxigraph 0.5 and its dependencies. I can fairly easily cut a beta release for you to build on. Will try to get it done in the next few days. The main remaining feature I would like to add to Oxigraph 0.5 is custom aggregate functions (#1153)

[Tpt]

0.5.0-beta.1 is now published with RDF/SPARQL 1.2 (all 1.2-related tests from https://github.com/w3c/rdf-tests/ are passing \o/)