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

So why not follow the named graph syntax, just restrict it to a single
triple? For example

    ex:connection <<city:_Seattle city:isConnectedTo city:_SanFranciso>>

And then in query form something like STATEMENT instead of GRAPH (to
align with rdf:Statement):

   SELECT ?cityName ?distance WHERE {
        STATEMENT ?connection <<city:_Seattle city:isConnectedTo ?city>> .
        ?connection connection:hasDistanceMiles ?distance.
        ?city rdfs:label ?cityName.
        FILTER (?city != city:_Seattle)
    } ORDER BY ?distance

That way the statement is both reified and addressable.

On Wed, Feb 5, 2020 at 5:43 PM Olaf Hartig <olaf.hartig@liu.se> wrote:
>
> 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 21:47:15 UTC