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

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.

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 10:17:32 UTC