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

Miel,

I realize a singleton graph is not the same as a triple. That's why I
followed but with the TRIPLE example, but it's too late for that.

IMO adding a first-class concept which is not URI-addressable goes
against RDF core principles. The original reification was not perfect,
but at least it does not have this drawback.

On Thu, Feb 6, 2020 at 12:18 PM Miel Vander Sande
<miel.vandersande@gmail.com> wrote:
>
> Hello Martynas, all,
>
> If there any standard Named graph semantics would exist, which do not, they could only go in the direction of “identifying an RDF graph”, which could contain 1+ triples (or perhaps it could be empty as well). Or in other words for 1 triple:
>
> I say something about a graph G that contains the triple T
>
> Reification is fundamentally different because it can only be about 1 triple, or not exist at all. There is no graph G. In other words:
>
> I say something about the triple T
>
> Pragmatically, you could handle these two the same, but like Olaf pointed out, this is only true for you. And encountering Named Graphs with more than one triple will cause a mess.
>
> I believe that if we ever want to make progress, we really need to first accept that Named Graphs and Reification target different types of objects, and thus are different constructs, and stop putting the “quads with single triple as reification” forward (no offence intended).
>
> Best,
>
> Miel
>
> > On 6 Feb 2020, at 08:39, Olaf Hartig <olaf.hartig@liu.se> wrote:
> >
> > Martynas,
> >
> > Using a triple itself when talking about it is the key idea of the RDF* approach.
> >
> > See also Andy's analogy to literals.
> >
> > What you are suggesting diverges from this key idea.
> >
> > Olaf
> >
> > -----Original Message-----
> > From: "Martynas Jusevičius" <martynas@atomgraph.com>
> > To: Olaf Hartig <olaf.hartig@liu.se>
> > Cc: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
> > Sent: Wed, 05 Feb 2020 22:47
> > Subject: 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 Thursday, 6 February 2020 12:19:54 UTC