RDF4J and RDF-star developments

[frensjan]

I have been trying to read up on a discussion in the RDF 1.2 / RDF-star standardisation effort that has apparently been going on for some time now. It seems that what will be standardised will deviate considerably from the current RDF/SPARL-star draft community report.

I've spent quite some hours trying to digest the mailing list archives, but I must admit that I'm struggling to make heads or tails of it. I understand that the current thinking goes beyond 'mere' quoting of triples (opaque or transparent) and would allow for identifiers to be linked to triples (using rdf:reifies) and that there is quite some discussion about the cardinality of such reifiers (I believe the are called).

There currently is support in RDF4J for RDF-star which is compatible with the draft report or close to it. There is no support just yet in the native store, only the memory store supports this. GraphDB does support persistence of quoted triples, I believe also the Halyard fork support them. In our implementation we use quoted triples for querying provenance information.

I was wondering what the views of the RDF4J community are on this subject.

[kenwenzel]

Hi @frensjan,

I plan to support RDF-star within the LmdbStore. Almost everything is already in place to do this.
I have seen that rdf:reifies can be used to give triple terms a name like:

<importantFact> rdf:reifies <<( <a> <b> <c> )>>

Is this already supported in the MemoryStore or GraphDB?

A notable difference in the latest discussions seems to be if triple terms (or quoted triples) should be allowed in the subject position or not. I have not thought about the consequences yet.

What are your opinions and the reasons of starting this discussion?

Best regards,
Ken

[hmottestad]

I haven't really followed along with the RDF 1.2 discussions so I can't say how different the latest proposal is from the one implemented in RDF4J.

I can say that our implementation is a bit behind the draft proposal since we implemented support for RDF-star some time before the current draft was published. At this point it's probably wise to wait until the RDF 1.2 working group publishes their final recommendation.

Btw. The MemoryStore does support some simple persistence. If your dataset isn't too big then you can try that while you wait for the LMDB Store.

[frensjan]

TL;DR

I don't have strong opinions yet. I fear that RDF 1.2 will deviate be incompatible with RDF-star, at least with the implementation in RDF4J. I fear that RDF 1.2 might become less useful / harder to implement than it could/should.

---

Longer response:

I think the RDF4J implementation isn't really that far off from the draft community report, if at all. But the RDF 1.2 seems to be taking quite a turn.

The RDF4J implementation supports quoted triples at the core data structure level. I get the impression that the current working group is backing away from that idea and to position statements about statements as a syntactic addition to RDF for reification. I.e., to create some sugar to write:

<e> rdf:reifies <<( <s> <p> <o> )>> ;
    ex:source <x> .

instead of

<e> a rdf:Statement ;
    rdf:subject <s> ;
    rdf:predicate <p> ;
    rdf:object <o> ;
    ex:source <x> .

Perhaps also the current quoting and annotation syntax will be supported, but that's unclear, at least to me.

Implementers input

What are [...] the reasons of starting this discussion?

The Amazon Neptune team (including Bryan Thompson and Olaf Hartig responsible for seminal work on statements about statements as well as Ora Lassila) seem to be clashing with a somewhat more academic part of the working group. I don't see much input coming from other implementers. This concerns me.

@VladimirAlexiev, is anyone from Ontotext following the RDF 1.2 / RDF-star discussions?
@aschwarte10, is this a concern for Metaphacts?
@pulquero, this will surely impact Halyard!

My stance

What are your opinions [...]?

First and foremost I fear that RDF 1.2 will not be compatible with the RDF-star work; which would at least for us be a pity, because we've built on it at Web-IQ. Nothing we can't change though, depending on the final outcome of course.

In terms of the direction they seem to be taking: I can understand the desire to not change the core RDF semantics.

Cardinality debate

I don't have a strong position when it comes to the cardinality debate. So whether this should be possible:

<e> rdf:reifies <<( <a> <b> <c> )>> .
<e> rdf:reifies <<( <x> <y> <z> )>> .

On the one hand, I think this will create a better named-graphs; a version in which the semantics of named graphs can be expressed better. On the other hand, it could make edge properties harder to reason about. And what does it even mean to reify two triples? This doesn't seem to make sense to me:

<e> a rdf:Statement ;
    rdf:subject <a> ; rdf:predicate <b> ; rdf:object <c> ;
    rdf:subject <x> ; rdf:predicate <y> ; rdf:object <z> .

Identifiers

A big change from the community draft report seems to be the idea that all reified triples/statements will have an identifier (IRI or blank node) and not be resources of themselves. This is obviously very different from the current implementation in RDF4J. I'm not sure if this a good idea. I think it can help authoring e.g. Turtle-star documents or writing SPARQL-star queries. That said, I haven't seen compelling examples / use cases. A the implementation level, for some triple stores it may be a blessing, for others it may be a big hurdle. I'm not sure yet.

Discussion in the open but hard to follow

At a different level, I'm trying to catch up with the RDF-star / RDF 1.2 discussion, but this is rather challenging given that currently my only sources are the meeting minutes and the e-mail archives. Both are rather impenetrable.

RDF4J implementation and voice

At this point it's probably wise to wait until the RDF 1.2 working group publishes their final recommendation.

I agree with this in terms of changing the implementation in RDF4J.

That said, if we have one, we could voice an opinion to the working group!

[pulquero]

Given it is just sugar, I don't think I have to care too much. I don't see quoted triples going away any time soon - there are numerous commercial and open-source stores that support them now and therefore existing customers/users who are going to be dependent on the functionality for some time to come. Ultimately, the market will decide what ends up being adopted. There are numerous examples where formal specs lost popularity to community driven initiatives.

[frensjan]

there are numerous commercial and open-source stores that support [quoted triples] now and therefore existing customers/users who are going to be dependent on the functionality for some time to come.

Agreed, I think it's a pity that the current WG is moving away from the RDF-star report. Of course, there can be very good reasons for that! I just don't have a 100% clear view on that.

Ultimately, the market will decide what ends up being adopted. There are numerous examples where formal specs lost popularity to community driven initiatives.

Agreed to some extend; standards be set, but it's indeed their utility that drives adoption. However, as this work is targeted as RDF 1.2, a lack of adoption or even worse a split in the implementations where some go the RDF 1.2 route and others the RDF-star route would be detrimental.

[pulquero]

Agreed, I think it's a pity that the current WG is moving away from the RDF-star report. Of course, there can be very good reasons for that! I just don't have a 100% clear view on that.

I guess not having to modify the RDF model is a good reason, but in a post-RDF-star world, I don't think that makes much sense any more. I mean, theoretically, it's nice, but practically, I can't ever see myself prioritisation a task on our backlog to migrate our etl to RDF 1.2.

Agreed to some extend; standards be set, but it's indeed their utility that drives adoption. However, as this work is targeted as RDF 1.2, a lack of adoption or even worse a split in the implementations where some go the RDF 1.2 route and others the RDF-star route would be detrimental.

I suspect we will see both RDF 1.2 and RDF-star being supported by implementations, currently there is no collision in syntax so that should be possible. In fact, RDF-star may have the last laugh: I wouldn't be surprised if RDF 1.2 ends up being implemented in terms of RDF-star for performance. In RDF 1.2, they have the concept of well-formedness. If you data is well-formed you can assume the existence of certain triples and hence make certain optimisations. There is a question of how a store would check/track whether its data is currently well-formed or not, but if you make use of quoted triples then that is guaranteed - you can't have half of a quoted triple.

[afs]

we've built on it at Web-IQ

@frensjan - if you'd like to provide a use case, or an email to describe Web-IQ usage, to the RDF working group, that would be appreciated.

[frensjan]

Sure Andy, I'll contact you on this.

[VladimirAlexiev]

@frensjan I haven't been active in the WG, but I share Amazon's opinion: discussion has strayed from the pragmatic into the theoretical, and exploring some huge "solution space".
I thought the CG report represented solid consensus and was going to be "propagated" into a bunch of specs.
Far from it: every day there's a new proposal and new important consideration...

But in the last couple of weeks I've seen some tendency to "come back to basics" and settle on something practical.
Let's not forget the main purpose of RDF-star was to make RDF more competitive to LPG!