Re: RDF* vs RDF vs named graphs

Martynas,

I agree absolutely, and I really appreciate Pierre-Antoine's and Peter's constructive discussion in this direction!

Olaf 

-----Original Message-----
From: "Martynas Jusevičius" <martynas@atomgraph.com>
To: Olaf Hartig <olaf.hartig@liu.se>
Cc: public-rdf-star@w3.org, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
Sent: Tue, 01 Dec 2020 22:44
Subject: Re: RDF* vs RDF vs named graphs

IMO part of the reasons of what makes RDF and SPARQL great is
interoperability, enabled by a small set of robust specifications.

Then there are features like named graphs, which are less strictly
specified, but de facto standards anyway.

I'm fine with RDF* as long as it can enable new PG-like use cases
*and* stay compatible with the above while still having sensible
semantics. But what if it cannot? Does anyone have an answer to that?
Taking existing implementations and finding a "common denominator"
will not necessarily lead to sensible semantics.

I think before making something "appealing to the PG people", we need
to make sure we'll not be introducing any incompatibilities with
what's already specified, proven and working.


Martynas

On Tue, Dec 1, 2020 at 9:41 PM 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.
>
> 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.
>
> 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 22:18:17 UTC