Re: RDF* vs RDF vs named graphs

It would be very useful to have some of the uses of edge properties in Stardog
described here and made into use cases.

As far as I can see, a large fraction (maybe even the majority) of the uses of
embedded triples (including edge properties) that are used to describe
embedded triples are problematic. 

peter


On 12/4/20 5:33 AM, Pavel Klinov wrote:
>
>
> On Fri, Dec 4, 2020 at 10:38 AM Pierre-Antoine Champin
> <pierre-antoine.champin@ercim.eu <mailto: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.
>
> 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
> <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
>     <http://example.com/crawlers#c1>> ;
>     >    dct:source <http://example.net/listing.html
>     <http://example.net/listing.html>> .
>     >
>     > in http://ceur-ws.org/Vol-1912/paper12.pdf
>     <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
>     <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
>     <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/
>     <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
>     <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
>     <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:00:09 UTC