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

On onsdag 5 februari 2020 kl. 11:17:15 CET Martynas Jusevičius wrote:
> Olaf,
> 
> how is RDF* reification different from a named graph with a single
> triple? In other words, how is <<:a :b :c>> better than :g { :a :b :c
> } ? The latter being URI-addressable and already standard and the
> former not.

Within the context of a particular application, you can certainly use (single-
triple) Named Graphs as a vehicle to capture statement-level metadata / 
annotations for individual triples. You simply have to decide that this is 
what you use Named Graphs for in your application.

The caveat is that, by making this decision, there is no straightforward way 
anymore for your application to also store and query graph-level metadata (in 
addition to the statement-level metadata). In contrast, if you were using 
Named RDF* Graphs, you would not have this limitation.

Additionally, you cannot rely on the fact that others have made the same 
decision for their data. In other words, if you retrieve the following snippet 
of TriG from someone else's server (prefix declarations omitted),

ex:connection { city:_Seattle city:isConnectedTo city:_SanFranciso . }

...you cannot be sure that the URI ex:connection is meant to the denote the 
triple within the graph. Instead, you have to assume that it denotes the graph 
rather than the triple.

Best,
Olaf

 
> Reusing data and queries from Kurt's post (I've added city labels), how is
> 
>     <<city:_Seattle city:isConnectedTo city:_SanFranciso>>
>         a class:_Connection;
>         rdfs:label "Seattle To San Francisco"^^xsd:string;
>         connection:hasDistanceMiles "807.6"^^xsd:float;
>         connection:hasObverse
>             <<city:_SanFranciso city:isConnectedTo city:_Seattle>>
>         .
> 
>     city:_Seattle rdfs:label "Seattle" .
>     city:_SanFranciso rdfs:label "San Francisco" .
> 
> and
> 
>     select ?cityName ?distance  where {
>         <<city:_Seattle city:isConnectedTo ?city>>
>               connection:hasDistanceMiles ?distance.
>         ?city rdfs:label ?cityName.
>         filter (?city != city:_Seattle)
>     } order by ?distance
> 
> better than
> 
>     _:connection { city:_Seattle city:isConnectedTo city:_SanFranciso . }
>     _:obverse { city:_SanFranciso city:isConnectedTo city:_Seattle . }
> 
>     _:connection a class:_Connection;
>         rdfs:label "Seattle To San Francisco"^^xsd:string;
>         connection:hasDistanceMiles "807.6"^^xsd:float;
>         connection:hasObverse _:obverse .
> 
>     city:_Seattle rdfs:label "Seattle" .
>     city:_SanFranciso rdfs:label "San Francisco" .
> 
> and
> 
>     select ?cityName ?distance {
>         GRAPH ?conn { city:_Seattle city:isConnectedTo ?city } .
>         ?conn connection:hasDistanceMiles ?distance.
>         ?city rdfs:label ?cityName.
>         filter (?city != city:_Seattle)
>     } order by ?distance
> 
> ?
> 
> We get the same results, except we can also identify the named graph.
> 
> On Wed, Feb 5, 2020 at 10:15 AM Olaf Hartig <olaf.hartig@liu.se> wrote:
> > On onsdag 5 februari 2020 kl. 18:36:36 CET Holger Knublauch wrote:
> > > On 5/02/2020 17:46, Olaf Hartig wrote:
> > > > [...]
> > > > 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.
> > > 
> > > Ok, granted. You are enumerating those two options at the end of
> > > 
> > > http://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and

> > > -spa rql-star/
> > > 
> > > I guess the second option - to change the data model and storage - is
> > > what Martynas was referring to, and what I agree doesn't easily work for
> > > our scenarios either.
> > 
> > I see that. That's why, in addition to the RDF* data model, I also try to
> > promote the option to go with a purely syntactic layer first.
> > 
> > > OTOH, I agree that using Turtle* and SPARQL* as a syntactic layer is
> > > quite feasible and is the approach we are taking too. Needless to say
> > > these mapping approaches imply some compromises, e.g. if SPARQL* maps to
> > > rdf:Statements then queries need to take care not to accidentally also
> > > bump into the "physical" triples (rdf:object etc) that SPARQL* was
> > > supposed to hide.
> > 
> > That's correct indeed.
> > 
> > -Olaf

Received on Wednesday, 5 February 2020 16:43:08 UTC