W3C home > Mailing lists > Public > public-rdf-star@w3.org > February 2020

Re: How is RDF* supposed to work with Linked Data?

From: Olaf Hartig <olaf.hartig@liu.se>
Date: Wed, 5 Feb 2020 07:46:40 +0000
To: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
CC: Holger Knublauch <holger@topquadrant.com>
Message-ID: <1825111.K0TJm8DWxX@porty3>
On onsdag 5 februari 2020 kl. 09:49:34 CET Holger Knublauch wrote:
> On 5/02/2020 08:40, Martynas Jusevičius wrote:
> > I don't see how RDF* can stay compatible with RDF:
> >      A node may be a URI with optional fragment identifier (URI
> > 
> > reference, or URIref), a literal, or blank (having no separate form of
> > identification). Properties are URI references.
> > 
> > https://www.w3.org/TR/rdf-concepts/#section-URI-Vocabulary

> I share this concern. It is impractical to introduce a completely new
> node type without breaking a lot of code and tools.

In contrast. An advantage of the RDF*/SPARQL* approach is that supporting the 
approach in a system does not require the system to be rewritten such that it 
covers the RDF* data model internally. Instead, a small wrapper component on 
top of the unchanged system internals can do the trick. Such a wrapper may map 
RDF* data and SPARQL* queries into RDF and SPARQL by using, for instance, the 
RDF reification vocabulary (or any other explicit reification approach). 
Alternatively, the wrapper may implement a mapping to the URI reification 
approach that you mention.


> This is why, at least for the time being, we are using what could be
> considered a hack, encoding triples as URIs:
> http://datashapes.org/reification.html#uriReification

> No approach is ideal, but this here is the most incremental, realistic
> route for us. The ugly long URIs would typically be hidden, e.g. behind
> a syntax like Turtle* and SPARQL* which we are trying to implement for
> our platform's next major release.
> (And yes, whether these long URIs should use namespace prefixes is
> another open question which we may need to revisit).
> Holger

Received on Wednesday, 5 February 2020 07:46:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 5 February 2020 07:46:52 UTC