Re: Can RDF* be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

Holger,

Like Pierre-Antoine, I also see "long URIs" that encode embedded triples as a possible approach to implement support for RDF*.

Olaf 

-----Original Message-----
From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
To: Holger Knublauch <holger@topquadrant.com>, public-rdf-star@w3.org
Sent: Wed, 28 Oct 2020 9:58
Subject: Can RDF* be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

Holger,

(I did what should have been done a long time ago: rename this subthread
to something more relevant)

On 27/10/2020 23:31, Holger Knublauch wrote:
> On 10/28/2020 1:53 AM, Pierre-Antoine Champin wrote:
>> Holger,
>>
>> Now I'm confused. This thread (which should have been renamed a long
>> time ago) is, in my understanding, about Martynas' question raised here
>>
>> <https://www.w3.org/mid/CAE35Vmy3vbThwHnKjbhMQuwKkH0BhNoxr_Gp15Ri5LfOdedsSA@mail.gmail.com>
>>
>>> Does RDF* need new semantics at all?
>> While I believe the answer is "yes", I concede that answering "no" to
>> that question would be convenient, because it would mean that existing
>> implementations of RDF could handle RDF* at the syntactical level only,
>> i.e. parse Turtle* and store it standard RDF triples.
>>
>> In your examples below, however, you propose to extend existing
>> implementations -- which defeats the purpose of fitting RDF* into
>> standard RDF semantics...
>
> The current RDF* draft requires introducing a 4th term type "RDF*
> triples":
>
> > IRIs <https://www.w3.org/TR/rdf11-concepts/#dfn-iri>, literals
> <https://www.w3.org/TR/rdf11-concepts/#dfn-literal>, blank nodes
> <https://www.w3.org/TR/rdf11-concepts/#dfn-blank-node> and RDF*
> triples <https://w3c.github.io/rdf-star/#dfn-triple> are collectively
> known as RDF* terms.
>
Correct.

In my understanding, introducing a new subclass of Node (TripleNode) was
the implementation counterpart of this extension of the abstract syntax,
but it seems that I was misunderstanding.

> The approaches based on (long) URIs avoid this and therefore are
> likely much less concerning w.r.t. existing implementations. A
> syntactic mapping means that existing APIs can represent these triples
> as normal URI nodes. From our own experience moving to this design was
> not disruptive (although some users have raised concerns about
> exposing the ugly long URIs in unexpected places such as exporting
> them to plain Turtle).
>
> Having said this, *some* implementations may represent these triple
> nodes differently, e.g. using the internal data structure I outlined
> below. This avoids ever storing these long URIs, makes it arguably
> easier to index and search over them, and probably keeps the issues
> with changing bnode identifiers at bay. But this is an implementation
> detail to me.
>
Agreed, but conversely, implementing the current draft using long IRIs
can be considered an implementation detail...

I think we also agree that the aim of the spec is to be as clear and
simple as possible, and that implementations may depart use their own
different internal models (for various reasons: backward compatibility,
optimization...) as long as they behave according the the spec.

> The additional semantics of interpreting these special URI nodes
> differently would be local to the RDF* specs and would not require
> adaptations to existing specs.
>
Again, agreed: this would be much less disruptive to the entire
ecosystem –and much less work for us in writing this document ;-).

But again I think that blank nodes in embedded triples make this
approach very hard. Defining the correct behaviour of "long IRI" when
they actually represent embedded blank nodes, if even possible, would be
extremely cumbersome (as opposed to the clear and simple way that the
spec should aim for). That being said, any PR proving me wrong is welcome.

> Holger
>

Received on Wednesday, 28 October 2020 10:21:40 UTC