W3C home > Mailing lists > Public > semantic-web@w3.org > April 2018

Re: Standards for storing RDF/OWL in a property graph?

From: Dave Raggett <dsr@w3.org>
Date: Sat, 7 Apr 2018 12:05:51 +0100
Message-Id: <2C9645F0-AB7A-4E53-9536-EC7D62F12F74@w3.org>
Cc: semantic-web@w3.org, Chris Mungall <cjmungall@lbl.gov>
To: Olaf Hartig <olaf.hartig@liu.se>
Hi Olaf,

That sounds interesting and worthy of further discussion. Do you have any information you can share on the use cases you’ve considered, and any experience you can share with us?

> On 6 Apr 2018, at 21:15, Olaf Hartig <olaf.hartig@liu.se> wrote:
> Hi Chris, Dave,
> I am working on these topics on a conceptual level since some time now (I mean 
> topics such as statement-level metadata in RDF, mappings between RDF graphs 
> and PGs). Most of these efforts are centered around a proposal that I call 
> RDF* and SPARQL*. The idea of RDF* is to extend RDF with the possibility to 
> have triples as the subject or the object of other triples (i.e., nested 
> triples), and SPARQL* is a corresponding extension of SPARQL in which triple 
> patterns can be nested. You may think of these extensions purely as syntactic 
> sugar or, alternatively, as an actual logical extension of the RDF data model. 
> In my work I have provided the foundation of both of these perspectives 
> [1,2,3,4].
> How is this related to statement-level metadata in RDF?
> A nested triple can be interpreted to be a statement *about* the triple in its 
> subject (or object) position, and SPARQL* is a language in which queries about 
> RDF data with statement-level metadata can be expressed in a very concise way. 
> In this context I should mention that RDF* data and SPARQL* queries can be 
> mapped to standard RDF data and SPARQL queries that use the RDF reification 
> vocabulary (or related approaches) [3], which makes it possible to support 
> RDF* and SPARQL* via a small wrapper on top of any ordinary triple store.
> How is this related to mappings between RDF and the PG model?
> First, notice that nested triples can be understood to be a form of edge-
> properties, which is the main feature of PGs that is missing from RDF. Hence, 
> RDF* can serve nicely as an intermediate model for reconciling RDF and PGs. As 
> a basis of such a reconciliation, I have provided generic mappings between 
> RDF* and PGs [2].
> I should also mention that the folks at Blazegraph have played an essential 
> part in shaping the RDF* & SPARQL* proposal, and the Blazegraph triple store 
> supports it [5] (they have been calling this feature "Reification Done Right" 
> RDR ;)
> Other triple store vendors have also expressed their interest in this 
> proposal. Additionally, a poster that I presented about it in last year's ISWC 
> was voted to receive the "peoples' choice best poster award" in that 
> conference, which seems to indicate that there is also some community interest 
> in this proposal.
> If you want to read more about the proposal, I suggest you start with the 
> short paper (4 pages) written for the poster [4].
> Best,
> Olaf
> http://olafhartig.de
> [1] Olaf Hartig and Bryan Thompson: Foundations of an Alternative Approach to 
> Reification in RDF. In CoRR abs/1406.3399, 2014.
> http://arxiv.org/pdf/1406.3399
> [2] Olaf Hartig: Reconciliation of RDF* and Property Graphs. In CoRR abs/
> 1409.3288, 2014.
> http://arxiv.org/pdf/1409.3288
> [3] Olaf Hartig: Foundations of RDF* and SPARQL* - An Alternative Approach to 
> Statement-Level Metadata in RDF. In Proceedings of the 11th Alberto Mendelzon 
> International Workshop on Foundations of Data Management (AMW), 2017.
> http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf
> [4] Olaf Hartig: RDF* and SPARQL*: An Alternative Approach to Annotate 
> Statements in RDF. Poster Session at the 16th International Semantic Web 
> Conference (ISWC), 2017.
> http://olafhartig.de/files/Hartig_ISWC2017_RDFStarPosterPaper.pdf
> [5] https://wiki.blazegraph.com/wiki/index.php/Reification_Done_Right
> On fredag 6 april 2018 kl. 12:35:18 CEST Dave Raggett wrote:
>> Hi Chris,
>> Thanks for raising this question. More broadly, there are plenty of
>> different kinds of annotations that could be applied to triples or quads,
>> e.g. temporal, spatial, data quality, provenance, trust and so forth. It
>> would be interesting to gather more details about the various use cases and
>> how people have addressed them, along with the relationship to other graph
>> formalisms including property graphs.  I am at an early stage of planning
>> for a W3C workshop on this topic and others, with a view to building upon
>> the experience of two decades of RDF and Linked Data. This is under my role
>> as the W3C staff lead for work on web data standards.
>> Best regards,
>>     Dave
>>> On 5 Apr 2018, at 18:24, Chris Mungall <cjmungall@lbl.gov> wrote:
>>> Graph databases that use a property-graph model such as neo4j have a
>>> certain level of popularity. Many people are storing ontologies and
>>> knowledge graphs in these.
>>> I'm not really interested in discussing pros/cons here, but am instead
>>> wondering if there is interest in standards or best practices for mapping
>>> RDF/OWL to PGs (or if there are efforts I am missing). The key
>>> mathematical difference between RDF and PGs is edge properties, but there
>>> are many other differences in practical implementations, e.g. URIs
>>> typically not first-class.
>>> I'm in the position of dealing with multiple neo4js from different groups
>>> each with their own interesting ways of tackling this. I'm able to
>>> standardize this set but would like this to be part of a broader effort.
>>> Examples of design decisions:
>>> subClassOf-some-values-from: 4 edges (RDF) vs 1 edge? How to encode the
>>> axiom pattern as edge properties? Make URIs the node ID, or have a
>>> special property?
>>> Bake in CURIEs as properties vs contract/expand as part of surrounding
>>> infrastructure? Direct reification vs map to edge properties?
>>> Annotation property assertions: edges or node properties?
>>> How to handle reification on triples where the object is a literal and the
>>> PG node properties are simple maps non-"follow-me" axioms like
>>> owl:disjointWith. Direct edges or alternate representation? How to map
>>> named graphs to a 'flat' graph space. Duplicate nodes vs edge and node
>>> properties? Store-specific concerns; e.g. populating 'label' in neo4j
>>> (and yes, I know many of these things are arguably problems that go away
>>> if you just use RDF directly, but if you want to have that discussion I
>>> suggest starting a separate thread).
>>> Of course, there are many assumptions baked in to how we might want to
>>> decide on the above. OWL and property graphs serve different use cases.
>>> You tend to want to avoid certain design patterns in non-RDF graph
>>> databases since there are frequently implicit assumptions involving graph
>>> traversal. Yet there is a lot in common, and it seems to make sense to
>>> avoid a proliferation of mappings. Even if there are too many use cases
>>> to define a standard mapping, a best practices document (a la the n-ary
>>> patterns W3C note) would be most welcome.
>>> We have an ontology service layer on top of neo4j
>>> (https://github.com/SciGraph/SciGraph
>>> <https://github.com/SciGraph/SciGraph>) that implements a set of mappings
>>> from OWL described here:
>>> https://github.com/SciGraph/SciGraph/wiki/Neo4jMapping
>>> <https://github.com/SciGraph/SciGraph/wiki/Neo4jMapping> (looks a bit
>>> ugly, it's all generated from junit tests)
>>> In retrospect there are some things I would do differently. For example,
>>> avoiding blank nodes as much as possible, especially for existential
>>> restrictions. But I put this up as a strawman.
>>> Are there efforts I am missing here? If not, are others interested and how
>>> should we proceed? Does it make sense to aim for a W3C note, or just
>>> start with a shared google doc?
>> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>> W3C Data Activity Lead & W3C champion for the Web of things

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C Data Activity Lead & W3C champion for the Web of things 

Received on Saturday, 7 April 2018 11:06:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:01 UTC