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

Hi Dominik,

Thanks a lot for the pointer!

I skimmed your paper. Is it correct that the transformation you consider in 
this paper is only from RDF to PGs (not the other way around)?

Do you have any formal guarantees of your transformation (e.g., is it 
information preserving)?

Moreover, I observe that your transformation is only on the level of the data. 
I mean, you did not consider queries (SPARQL) and how they can be mapped into 
something that can be evaluated over the PGs resulting from your 
transformation, right? Note that my document about reconciling RDF* and PGs 
does not formally consider queries either. However, I am working on a formal 
definition of how SPARQL* expressions can be used for this purpose.

Best,
Olaf


On söndag 8 april 2018 kl. 22:17:18 CEST Dominik Tomaszuk wrote:
> Hi Chris, Dave, Olaf,
> 
> I'm working on a slightly different approach. My proposal is based on
> serialization that is compatible with RDF and PG model. More details you
> can find in [6]. In this paper, Olaf gave me helpful comments.
> 
> We have also implementations:
> 
> 1. neo4j-sparql-extension-yars [7] - Neo4j unmanaged extension for RDF
> storage and SPARQL 1.1 query features with support for YARS serialization
> 
> 2. sesame-rio-api [8] - Modified Sesame API with added support for Yet
> Another RDF Serialization (YARS) serialization
> 
> 3. sesame-rio-yars [9]  - Yet Another RDF Serialization (YARS)
> serialization parser for Sesame
> 
> 4. ttl-to-yars [10] - Simple Turtle to Yet Another RDF Serialization
> (YARS) serialization converter written in Python
> 
> Best,
> Dominik
> 
> 
> [6] Tomaszuk, Dominik. "RDF data in property graph model." Research
> Conference on Metadata and Semantics Research. Springer, Cham, 2016.
> https://link.springer.com/chapter/10.1007/978-3-319-49157-8_9
> 
> [7] https://github.com/lszeremeta/neo4j-sparql-extension-yars
> 
> [8] https://github.com/lszeremeta/sesame-rio-api
> 
> [9] https://github.com/lszeremeta/sesame-rio-yars
> 
> [10] https://github.com/lszeremeta/ttl-to-yars
> 
> 
> Dominik Tomaszuk
> Research Fellow
> University of Bialystok
> Poland
> 
> On Fri, 6 Apr 2018 22:15:18 +0200, Olaf Hartig 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

Received on Sunday, 8 April 2018 20:58:02 UTC