Re: RDF* vs RDF vs named graphs

On 12/2/2020 6:40 AM, Olaf Hartig 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.
>
> 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.
>
> 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.

+1

RDF* has proven practical value already. Those who like to use it should 
be allowed to proceed with a CG close to the original design. Those who 
don't want to use it can happily continue with named graphs or 
rdf:Statements (both of which have been around for many years, with 
mixed success). If the consensus model of W3C is bound to fail here, it 
is enough if a sub-community agrees on some direction to at least 
harmonize the existing implementations.

I am worried this group gets bogged down if too many directions are 
considered and theoretical border cases are dictating the overall approach.

Holger


>
> 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 Tuesday, 1 December 2020 23:50:18 UTC