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

Re: RDF* vs RDF vs named graphs

From: thomas lörtsch <tl@rat.io>
Date: Fri, 4 Dec 2020 17:16:49 +0100
Cc: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-star@w3.org
Message-Id: <1503E2A3-BC83-4419-B782-C90C5DDFBA6C@rat.io>
To: Pavel Klinov <pavel@stardog.com>


> On 4. Dec 2020, at 11:33, Pavel Klinov <pavel@stardog.com> wrote:
> 
> 
> 
> On Fri, Dec 4, 2020 at 10:38 AM Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
> Perer,
> 
> > What should be concluded from this?  Just about the most charitable conclusion
> > is that RDF* is unsuitable for its claimed use.
> 
> the fact that the examples do not reflect the best way to address their use-cases using RDF* (as it is formally defined) does not mean that such a way does not exist.
> 
> Don't get me wrong: I am not trying to minimize the fact that such examples are, in a way, harmful. Clearly, they have created a lot of misunderstanding. One could even think that the popularity of RDF* happened for bad reasons, because people saw in those example something that was not here (in the formal definition, nor in the implementations).
> 
> What makes me more optimistic is, precisely, that we have implementations, some of them deployed in commercial products. I'll leave the implementers comment on that, but I'm curious to know how their customers are using RDF*, and whether the unicity of embedded triples raised that many problems.
> 
> I have yet to see any examples of serious user confusion around use of RDF* in Stardog. We document clearly the key decisions we made re: RDF*/SPARQL* [1] and the confusion does not arise [2]. Most people using it in Stardog have some familiarity with the PG data model and aligning with that helps.

Your documentation at [1] says: 

"Named Graphs: Edges with properties can be stored in a named graph just as other triples. However, edge properties must be stored in the same named (or default) graph as the corresponding edges."

That supports my point: Stardog assumes that annotations refer to the edge in the same graph, not to all edges of that type. The proposed RDF* semantics however defines that the annotation refers to all edges of that type, in any graph (it doesn’t discriminate between graphs).

Thomas


> What typically does cause confusion is any mention of RDF reification or use of (singleton) named graphs for statement-level metadata. While it can be implemented that way, as soon as those details leak to users, problems arise. People start feeling that RDF requires some obscure/complex mechanisms for something that PG databases support easily and naturally. And we feel pretty strongly that *anything* that increases perceived complexity of RDF is a bad thing.
> 
> Disclaimer: YMMV, other vendors may have a different experience. I'm not really willing to debate who's experience is the right or most representative, just responding to Pierre-Antoine's call for vendor comments.
> 
> [1] https://www.stardog.com/docs/#_details
> [2] this isn't to say that there're no issues, just not due to confusion re: semantics. Typical questions we have at this time are more like people wanting to use edge properties in SHACL to validate RDF* or in R2RML to map tables to RDF*. But we're never going to get there if we cannot even settle on the basic syntax, semantics, and querying.
>  
> 
> Just a small comment below on one of the examples that you quote:
> 
> On 03/12/2020 00:47, Peter F. Patel-Schneider wrote:
> > I certainly agree with Thomas that examples used throughout the RDF* documents
> > and discussions are ill-supported by the various formal definitions underlying
> > RDF*.
> >
> > We see
> >
> > :bob foaf:name "Bob" .
> > <<:bob foaf:age 23>>
> >    dct:creator <http://example.com/crawlers#c1> ;
> >    dct:source <http://example.net/listing.html> .
> >
> > in http://ceur-ws.org/Vol-1912/paper12.pdf
> >
> > <<:painting :height 32.1>>
> >    :unit :cm;
> >    :measurementTechnique :laserScanning;
> >    :measuredOn "2020-02-11"^^xsd:date.
> >
> > <<:man :hasSpouse :woman>>
> >    :source :TheNationalEnquirer;
> >    :webpage <http://nationalenquirer.com/news/2020-02-12>;
> >    :retrieved "2020-02-13"^^xsd:dateTime.
> >
> > in https://graphdb.ontotext.com/documentation/9.2/free/devhub/rdf-sparql-star.html
> >
> > <<:Bess_Schrader :employedBy :Enterprise_Knowledge . >> :dateAdded "2020-05-22" .
> > <<:Bess_Schrader :employedBy :Enterprise_Knowledge . >> :addedBy :user_bscrader .
> >
> > in https://enterprise-knowledge.com/rdf-what-is-it-and-why-do-i-need-it/
> 
> I can't help but notice that the embedded triple is repeated here, 
> although the intention is clearly to put two annotations on the same arc 
> -- the illustrating figure leaves no doubt about that:
> 
> https://enterprise-knowledge.com/cms/assets/uploads/2020/07/rdf_7.jpeg
> 
> so that person does not seem to assume that multiple embedded triples 
> represent different arcs...
> 
> That's 100% true. Drawing any conclusion from the fact that Bess decided to repeat the embedded triple would be a mistake. It's a single graph edge with two properties.
> 
> Cheers,
> Pavel
>  
> 
>      best
> 
> >
> > <<?c a rdfs:Class>> dct:source ?src ;
> >      prov:wasDerivedFrom <<?c a owl:Class>> .
> >
> > :loisLane :believes << :superman :can :fly >>.
> >
> > in https://w3c.github.io/rdf-star/rdf-star-cg-spec.html
> >
> >
> >
> > What should be concluded from this?  Just about the most charitable conclusion
> > is that RDF* is unsuitable for its claimed use.
> >
> > So what is RDF* good for?  I am concerned about this.
> >
> >
> > peter
> >
> >
> >
> >
> 
Received on Friday, 4 December 2020 16:17:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 4 December 2020 16:17:08 UTC