How to convert an OWL or RDF vocabulary (ontology) to an OrientDB class format?

[Geof Pawlicki]

I've recently imported a product description ontology into a new graph database. I would like to similarly, automagically create classes representing properties of individual products and services (and numerous  attributes related to their commercial use) from an OWL or RDF format, specifically Martin Hepp's GoodRelations work: http://www.heppnetz.de/ontologies/goodrelations/v1#classes. 

Is this possible in current the Community version of 2.0.11 , or would it be necessary to enter the class definitions my hand, or possible to write a simple module to do it? 

Thanks,

Geof

[Riccardo Tasso]

Hi Geof,

   RDF is supported through the SAIL implementation ( https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation ) since orientdb supports natively the blueprints Java API.

Anyway I would suggest to write your schema using orientdb OSQL language and import your data with a custom module.

The reasons are three:

1. orientdb supports class inheritance (both for vertices and edges) while Blueprints (at least in the actual version) don't; since RDFS can use this kind of construct, you could benefit of using it natively
2. performance should be better with OSQL since you can use native constructs
3. I don't know how well is maintained the Sail implementation

Cheers,

   Riccardo

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Geof Pawlicki]

Thanks, Riccardo. It's hard to imagine doing much of anythign useful without class inheritance so using OSQL makes sense. . . which sortof puts me back to a comparatively manual approach for loading a fairly large schema (~2500 lines of OWL). Among other things, this seems an error prone way to do the conversion, whereas there are mutliple programs available to convert between RDF, OWL, JSON-LD, Microdata, etc.

So, am thinking so far to write some extensions to a readily available Python/SAX parsers to automate the creation of the OSQL script. Has anyone tried anything like this, or better, have something working ?  I'm hoping that it would have some general utility.  FWIW, I also have similar questions regarding the availability of automation to create input screens en route to putting together test data. 

Geof

[Riccardo Tasso]

Hi Geof,

   you right: if the tool must be general and not very specific to your case a mapping tool will be the right approach.

Starting from a good RDF or OWL parsing library will be necessary (rdflib for python, Sesame for Java).

If you prefer the cleaner approach to performance I will suggest you Blueprints SAIL outplementation: work with RDF/OWL with a graphdb under the hood (in your case orientdb)! It may have bugs or inefficencies, but it's the reference, and you can always improve the code if you like it.

Another unexplored but, in my opinion, very promising approach will be the develop of a SAIL implementation which is specific to orientdb. In this case I will be interested in giving my own contribution (in the spare time).

Otherwise, if you don't have too much time, you have to choose between two ways:

1. you just need to import goodrelations data into orientdb: define your own mapping, tailored for your use case; when data are imported you'll be able to query and work with them with OSQL language; probably you'll need also a RDF/OWL exporter
2. you need to query with SPARQL, work directly on RDF/OWL, import/export in that format: have you considered a triple store?!

I am very interested in this topic: please let me know your progress.

Cheers,

   Riccardo

[Geof Pawlicki]

Again thanks for rounding out the range of possibilities, Riccardo. 

I think I'm foreclosed from the SAIL approach because I *have* to do path queries that may extend over auxiliary data incorporated from another, non-RDF data source. Also, while the GoodRelations schema seems a likely piece, and is actually well suited to the data I need to acquire, the actual data could well end up coming in a schema.org format, or even be unstructured. Hence I have an initial, and perhaps general, preference for mapping. I suppose the other approach woudl be to RDF-ize the non-standard data?

Regarding the subesquent (or preferred) use of SPARQL, I don't see an immediate advantage to centering on it though. Specifically, the triple store approach would lose the flexibility of the path query afforded by OrientDB, yes? If so, it seems I'm better off with classes inheriting from V and E.

So, still somewhat grasping a bit for a good general-purpose way to do the import/export work, and mostly wondering if an automated approach to RDF->OSQL would be useful to anyone else, e.g. as a peripheral tool like the ETL module?

Geof

[Riccardo Tasso]

2015-07-07 15:30 GMT+02:00 Geof Pawlicki <geofpa...@gmail.com>:

I suppose the other approach woudl be to RDF-ize the non-standard data?

Yes, which is not so terrible as you may think, rdf data is made to be extended.

  

Specifically, the triple store approach would lose the flexibility of the path query afforded by OrientDB, yes?

I'm not really sure of what you mean...anyway also SPARQL has property paths, see: http://www.w3.org/TR/sparql11-property-paths/

 

So, still somewhat grasping a bit for a good general-purpose way to do the import/export work, and mostly wondering if an automated approach to RDF->OSQL would be useful to anyone else, e.g. as a peripheral tool like the ETL module?

My opinion is that this kind of tool doesn't exist since a general solution to this mapping problem is hard to find and the benefit/cost lead often to a custom mapping instead of a general method.

Consider for example the gr:Offering class. In RDF it's identified by a URI ( http://purl.org/goodrelations/v1#Offering ) but in orient you can't create a class with such a name. The quick and dirty way is to simply create a Offering class in orient. The general solution may be the creation of a function to translate a URI to a valid class name (and this function should keep a mapping of namespaces).

Another interesting problem to face in such a conversion is the subclassing of RDF DataType Properties. In orient a DataType Property is a PROPERTY and as far as I know you can't subclass them. I don't know exactly if this construct is required by your use case...but for a general solution you have to face it.

Many of those questions are answered by SAIL outplementation but, as I've already said, my feeling is that orient is more expressive than Property Graph Model (implemented by Blueprints).

Probably the magic is in finding a good trade-off between the Best Solution and the custom solution which is useful only in your specific use case. Both RDF and orient are important tools and a kind of ETL from RDF to Orient should be of interest of many. This could also be a good work for a thesis, I don't know.

If you decide to start something I'll give you all my support.

Cheers,

   Riccardo

[Geof Pawlicki]

FWIW, after reviewing the available path feature, I've begun to think that not having to use SPACKL would in benefit in itself!  

Otherwise, there happen to be 22 subProperties in the goodrelations ontology, and they don't seem to add a great deal, especially when compared to having the capabilities represented by OrientDB's extended SQL. As you point out, the class naming can be handled simply, and losslessly, enough with a comment field. I don't doubt that there are other problems on the horizon, but I guess the first thing is to get something that works for my immediate case. . .

From your experience with the Query BUilder, are there procedures, approvals and the like needed to get something incorporated into a release ?

Thanks,

Geof

[Riccardo Tasso]

2015-07-09 23:00 GMT+02:00 Geof Pawlicki <geofpa...@gmail.com>:

From your experience with the Query BUilder, are there procedures, approvals and the like needed to get something incorporated into a release ?

Sorry, I can't understand this question, what do you mean?

Riccardo

[Geof Pawlicki]

Maybe I misunderstood, has your work on the QueryBuilder for OSQL been incorporated into an OrientDB distribution?  If so, my initial question reduces to "who to ask" about doing something similar if/when this import thing gets moving. 

Thanks,

Geof

[Riccardo Tasso]

No, it is not included.

In your case you could ask in this mailing list.

Riccardo

--

[Geof Pawlicki]

Well, without knowing much about the background of the QueryBuilder project, or your preferences, it would seem natural enough for it to be included. I don't think it's too early to be considering it for "standards track," as it's a good and frankly necessary piece for wider adoption of OrientDB. 

For my part, no one else has spoken up regarding an ETL-like capability to automate import/export of RDL schemas (or data), so I'll probably just get somethign working and ask for further comment. Is there any history to this sort of thing that I should be aware of, e.g. beyond SAIL/Blueprints being the Java standard ? 

Thanks,
Geof

[Geof Pawlicki]

Hi Riccardo, 

Don't know what other will have tried, but it occurs to me (in the course of slogging through the manual groundwork for this) that the relation between a Property and a subProperty can be readily expressed with AV-Pairs in any of the List types.  

Otherwise, developing a deeper appreciation of RDF and SPARQL as I go along too. . . 

Thanks,

Geof

[Riccardo Tasso]

2015-07-17 15:19 GMT+02:00 Geof Pawlicki <geofpa...@gmail.com>:

Don't know what other will have tried, but it occurs to me (in the course of slogging through the manual groundwork for this) that the relation between a Property and a subProperty can be readily expressed with AV-Pairs in any of the List types.  

Hi Geof,

   I don't know if I correctly understood your problem, but I guess that you could model a RDF subproperty in OrientDB by subclassing the edge type. What do you think about it?

Riccardo