Re: RDF* vs RDF vs named graphs

> On 1. Dec 2020, at 21:40, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> Dear all,
> 
> On tisdag 1 december 2020 kl. 09:20:06 CET Pierre-Antoine Champin wrote:
>> Dear all,
>> 
>> to be honest, at first, I too was not really convinced by RDF*, compared
>> to what RDF already offers.
>> 
>> But the fact is that RDF* appeals to many people, including people that
>> are not core members of the SemWeb community. So the least that we can
>> do, I believe, is try to understand what makes it more appealing that
>> what has been long been available before it.
>> 
>> Not only is RDF* appealing, but it is there already. It is implemented
>> in multiple triple stores, which is great, but in slightly different and
>> incompatible ways [1], which makes it less useful...
>> 
>> That's why I believe its is important to learn the lessons from RDF*'s
>> popularity, and reach a consensus, among users and implementers, to
>> avoid different implementation to drift apart and kill RDF's core
>> purpose, which is interoperability.
> 
> I can only second what Pierre-Antoine wrote.
> 
> My main goal here is to take the RDF*/SPARQL* approach that people have 
> started to implement and to use, and properly document and define it in a form 
> that serves as a spec for the existing and perhaps future implementers. 
> Knowing that there is already some divergence in these existing 
> implementations, my hope is that this spec becomes a basis for converging 
> towards an ecosystem of interoperable implementations of the approach. The 
> fact that we have several of these implementers in the group makes me positive 
> about that.
> 
> I understand that the approach has limitations and is not going to solve all 
> problems or address all use cases. I can live with that, and it seems that 
> several of the existing implementers can do so too.
> 
> So, given the aforementioned goal, I see discussions of additional features 
> (embedded quads, embedded triples as predicates, encoding of embedded triples 
> as IRIs) or of proposals to change the overall direction of the approach as 
> potential distractions.

I understand that and I don’t object to limiting the scope of RDF* to certain usecases. OTOH RDF already has two half-baked approaches to meta modelling and I’m concerned of another approach again not doing it right and muddying the waters even further. RDF* is not operating in a vacuum. So even if RDF* doesn’t support e.g. annotating groups of statements or statements in other graphs it should do so in well defined ways, knowing what it does, what others do and how those activities can interlock. 

If it annotates occurrences - which as I understand is its core raison d’être - without giving full information about the annotated occurrence, namely the graph that the triple occurrs in, it should do so in well defined ways, e.g. by defining that it always refers to a triple of that type in the local graph. It can’t get by without discussing the topic of graphs at all. That’s just not cutting it.

What may be irritating is that if one has made it that far it is probably easy to go the full distance. Also discussions about how to get that far may sound like they discuss going the full distance. But that is a problem that comes with the limiting approach and the reason why I prefer to aim for a complete solution. 

> Don't get me wrong. I don't mean to make this a hostile territory for such 
> discussions. It is just that I prefer to spend my (unfortunately very limited) 
> time on trying to make progress towards completing a spec of the approach, and 
> I hope that people who share this goal can help in this effort.

Yeah, sorry for that harsh choice of words.

Thomas



> Finally, just to be clear, when I say "spec", I am not talking about an 
> official W3C REC at this point. Instead, I see this spec as one of several 
> possible inputs to a potential RDF 1.x WG.
> 
> Best regards,
> Olaf
> 
> 
> 
>> As many of us, I have my own ideas and preferences about where this
>> consensus should land, but I try to keep the discussion as open as
>> possible. However, this is not a clean slate:
>> 
>> * RDF* has already been described in several papers, and
>> 
>> * as I mentioned above, it is already largely implemented.
>> 
>> Features that have changed from one paper to another (e.g. PG mode vs.
>> SA mode) are often implemented differently across systems; those
>> obviously need to be discussed.
>> 
>> Features that have been stable from the very beginning (e.g. "abstract"
>> triples rather than triple occurrences) are usually already implemented
>> consistently across systems. Changing them would have a big impact on
>> both users and implementers, and may end up stopping the momentum that
>> got us here in the first place. Changes of this kind remain an option
>> and deserved to be discussed, in my opinion, but only if we have a very
>> compelling argument and a large consensus to change them.
>> 
>>   best
>> 
>> [1]
>> https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/att-0065/result
>> s-2020-11-27.tsv

Received on Wednesday, 2 December 2020 00:06:36 UTC