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

Hi Olaf,

On Sun, 8 Apr 2018 22:57:09 +0200, Olaf Hartig wrote:
> 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)?

That's right. I'm working on PG->RDF transformation now. Note that YARS 
serialization was develop also to that kind of transformation.

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

We have only a few implementations. We have not found the case where the 
information is lost etc.

> 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.

We are currently collecting information because we want to start in the 
near future with SPARQL -> Cypher and Cypher -> SPARQL.

> 
> Best,
> Olaf

Best,
Dominik

> 
> 
> 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 Monday, 9 April 2018 09:15:52 UTC