W3C home > Mailing lists > Public > semantic-web@w3.org > February 2008

Re: OODBMS <-> RDF

From: Ioannis Athanasiadis <ioannis@idsia.ch>
Date: Tue, 5 Feb 2008 14:23:20 +0100
Cc: <semantic-web@w3c.org>
Message-Id: <4D43CB06-1D6E-4068-8EA6-D8B5ABE2874C@idsia.ch>
To: José Pedro Ferreira <jose.pedro.ferreira@cern.ch>

Dear Jose,
as Elisa implied in her email pointing to the OMG community on meta- 
models, the "problem" with relational database models is that their  
constructs are overloaded and certain aspects are not at all covered.  
For example,  we use in RDBMS associate entity tables to define many- 
to-many relationships. However which of the two (or more) entities are  
"own" the data remains undefined. Imagine two tables "Cat" and  
"Person", each one of which defines an entity in a database. An  
associate entity table "Cat_Owner" will store the ownership  
relationship between Person and Cat. However, by simply inspecting the  
scheme we cannot figure out the direction of the relationship. Is a  
cat owned by a person, or a person owns the cat, or both? Any of the  
three could be allowed with the same DB schema.
This means that extra definitions are required, apart the database  
schema in order to define the full semantics of a relational model.

As for the practical questions, I have tried in the past D2R libraries  
that work great. But D2R requires quite some manual work to specify  
your  ontology in the way you want.

Best regards,
Ioannis

--
Dr Ioannis N. Athanasiadis
IDSIA - Istituto Dalle Molle di Studi sull'Intelligenza Artificiale
Galleria 2, CH-6928 Manno, Lugano, Switzerland
tel: +41-586-666-671 fax: +41-586-666-661 mob: +41-798-141-680
ioannis@idsia.ch - www.idsia.ch - www.athanasiadis.info

On 4 Feb 2008, at 09:24, José Pedro Ferreira wrote:

> Dear Ioannis,
> Many thanks for this information. However, I am looking for studies on
> the opposite direction: from an existing OO database to RDF. My main
> concern here is how to specify the way mappings are done: a new
> ontology? any existing one that I don't know of...? I suppose that the
> problem of mappings does not apply to your case (at the OO<->RDF  
> level,
> I mean).
>
> Best regards,
>
> Pedro
>
> Ioannis Athanasiadis escreveu:
>> Dear Pedro,
>>
>> we have done some work towards a semantic-rich development  
>> architecture [1]. Our goal was to utilize an OWL/RDF ontology as a  
>> domain model to be used for software application development.  A  
>> software tool for generating Enterprise Java Beans, Hibernate  
>> mappings, and Relational schemas from an ontology is available  
>> online [2].
>> More documentation will be eventually available on [3]
>>
>> Best regards,
>> Ioannis
>>
>> [1] Athanasiadis, I.N., Villa, F. & Rizzoli, A.E. (2007). Enabling  
>> knowledge-based software engineering through semantic-object- 
>> relational mappings. In 3rd Intl Workshop on Semantic Web Enabled  
>> Software Engineering, 4th European Semantic Web Conference, pp.  
>> 16-30 (online at: http://swese2007.fzi.de/papers/04.Enabling_KB_SE.pdf)
>> [2] http://imt.svn.sourceforge.net/svnroot/imt/Thinklab/
>> [3] http://www.integratedmodelling.org
>>
>>
>> On 30 Jan 2008, at 10:46, José Pedro Ferreira wrote:
>>
>>> Dear all,
>>> Thank you so much for all the suggestions that you promptly  
>>> provided!
>>> I'm currently taking a look at the extensive amount of information  
>>> provided by Elisa and Niklas, and I see that there's already a lot  
>>> of work in this area, though things are still a bit immature.
>>> Niklas, I'd really appreciate if you could provide me some  
>>> information about this python structures <-> rdf transforms  
>>> provided by oort, since I already have a layer that makes this  
>>> kind of transformation in order to export JSON. So, maybe it will  
>>> be useful.
>>>
>>> Thanks, once again,
>>> Cheers,
>>>
>>> Pedro
>>>
>>>
>>> Niklas Lindström escreveu:
>>>> Hi!
>>>>
>>>> This is *very* interesting. I am behind Oort [1] (which Jesse
>>>> mentioned). One of the ideas driving it is to have a mapping *both*
>>>> back and forth between object and RDF graphs. Since it's Python,  
>>>> there
>>>> may be some ground for what you're after. Specifically, Oort today
>>>> allows you to construct RDF from Python dict/list/atomic value
>>>> structures [2] (isomorphic to JSON, which you can load directly via
>>>> simplejson). If you can get these structures from the ZODB, I hope
>>>> Oort will take you to the RDF you need.
>>>>
>>>> A missing piece of the puzzle is generating mappers directly out of
>>>> OWL schemas (and possibly vice versa). But these mappers also
>>>> represent queries/aspects, which are more ragged and mixed, so this
>>>> merits more investigation.
>>>>
>>>> ... Going further and beyond...
>>>>
>>>> In a wider sense, the Oort ("Out Of RDF Transmogrifying") idea  
>>>> right
>>>> now is a tiny beginning of what I feel can be a promising way of
>>>> bridging the gap between RDF and current pragmatic ("less is more")
>>>> approaches that have emerged, such as microformats and JSON (along
>>>> with the nascent ideas of schemas for those, as proposed by James
>>>> Clark [3, 4] and e.g. the Mozilla team [5]). Much of what is  
>>>> discussed
>>>> regarding Atom extensions [6] also seem (to me) to point towards a
>>>> need for formalism "reduction" to fit more narrow contexts (by  
>>>> which I
>>>> mostly mean to reuse OWL ontologies in simpler scenarios, where I'm
>>>> afraid proper RDF continues to be "beyond the horizon").
>>>>
>>>> I do think RDF is a "grand unifier" for modelling, but it seems  
>>>> that
>>>> for many specific contexts, it is viewed as "too formal" to get
>>>> traction. It's not impossible, but hard, to sell RDF as a perfect
>>>> match for smaller/local data syndication efforts. This poses the  
>>>> risk
>>>> of continued reinvention of many things RDF solves very well
>>>> (precision, I18N, data- and resource typing etc.). I believe that  
>>>> any
>>>> given context provides assumptions and locality (of terms etc) that
>>>> makes the decontextualized data which RDF is about *seem*  
>>>> superfluous.
>>>> But that next step is then always left unresolved, causing all  
>>>> these
>>>> integration problems that I assume many of us Semantic Web  
>>>> followers
>>>> see a solution for in RDF, OWL, SPARQL etc.
>>>>
>>>> Basically, I consider simpler representations to be wrapped in  
>>>> context
>>>> to reduce formal details, and I am convinced that that can be  
>>>> mapped
>>>> to the RDF data model rather unobtrusively. How is what I've only
>>>> begun scratching on the surface of..
>>>>
>>>> I've wanted to get the time and energy to pitch this more formally,
>>>> but haven't gotten around to it much (more than with this  
>>>> message, and
>>>> a related blog post [7] last year).
>>>>
>>>> Where to go further then? I'd gladly invite you to join
>>>> <http://groups.google.com/group/oort>, which due to nigh zero  
>>>> activity
>>>> I'd happily recast from a python toolkit focus into the more  
>>>> general
>>>> vision I described above. Not the least since my scope has  
>>>> widened to
>>>> plans for e.g. a javascript version of the Oort mapper, as well as
>>>> examination of the Elmo [8] effort from the OpenRDF/Sesame people,
>>>> which looks very similar to this. Granted, I do not have the
>>>> experience yet to organize larger community efforts, so perhaps  
>>>> some
>>>> other form would work better? I'm happy to join any party  
>>>> interested
>>>> in this.
>>>>
>>>> (By analogy, this can be related to things as diverse as the  
>>>> relative
>>>> merits of dynamic, static and inferred typing in programming,  
>>>> ORMs for
>>>> RDBMSs, CouchDB-like technology, etc. Akin to "how to have the cake
>>>> and eat it too".. I believe we can do this. With insulated layers,
>>>> each simple and formal, as in many other cases.)
>>>>
>>>> Best regards,
>>>> Niklas
>>>>
>>>> [1] <http://oort.to/>
>>>> [2] <http://oort.to/oort_api/oort.test.test_rdfview-pysrc.html#test_from_dict 
>>>> >
>>>> [3] <http://blog.jclark.com/2007/04/do-we-need-new-kind-of-schema-language.html 
>>>> >
>>>> [4] <http://blog.jclark.com/2007/04/xml-and-json.html>
>>>> [5] <http://developer.mozilla.org/en/docs/Describing_microformats_in_JavaScript 
>>>> >
>>>> [6] <http://www.imc.org/atom-syntax/mail-archive/ 
>>>> threads.html#20299>
>>>> [7] <http://dustfeed.blogspot.com/2007/01/knowledge-bits-and-pieces.html 
>>>> >
>>>> [8] <http://openrdf.org/doc/elmo/1.0-beta2/user-guide/>
>>>>
>>>>
>>>>
>>>>
>>>> On Jan 26, 2008 12:12 AM, Jesse Erdmann <jesse@jesseerdmann.com>  
>>>> wrote:
>>>>
>>>>> The only other D2R like software I'm aware of is Squirrel RDF,
>>>>> http://jena.sourceforge.net/SquirrelRDF/.  I don't know of any  
>>>>> support
>>>>> of ZODB.  Is something like RDF Alchemy,
>>>>> http://www.openvest.com/trac/wiki/RDFAlchemy, or Oort,
>>>>> http://oort.to/, similar to what you're looking for?
>>>>>
>>>>> 2008/1/25 José Pedro Ferreira <jose.pedro.ferreira@cern.ch>:
>>>>>
>>>>>
>>>>>> Hello.
>>>>>> Yes, I know that RDF can be seen as object-oriented. But... I'm  
>>>>>> not
>>>>>> considering if it is possible to display OO data using RDF, but  
>>>>>> rather
>>>>>> how to make this translation in a smooth, fairly automatic way,  
>>>>>> without
>>>>>> having to write enormous amounts of replicated code, and taking
>>>>>> advantages of the similarities that exist between the two  
>>>>>> models. It's a
>>>>>> matter of "translation techniques".
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pedro
>>>>>>
>>>>>> cdr escreveu:
>>>>>>
>>>>>>
>>>>>>> On Fri Jan 25, 2008 at 02:34:28PM +0100, Jos? Pedro Ferreira  
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello.
>>>>>>>> I need to make data stored in an object-oriented (ZODB)  
>>>>>>>> database available
>>>>>>>> as RDF. I've been looking for existing architectures and  
>>>>>>>> mapping
>>>>>>>> techniques, and eventually found D2RQ
>>>>>>>> <http://www4.wiwiss.fu-berlin.de/bizer/D2RQ/spec/>. The  
>>>>>>>> problem is that
>>>>>>>> D2RQ seems too much oriented towards the relational paradigm.
>>>>>>>> Is there any research done on this particular area? I've been  
>>>>>>>> thinking
>>>>>>>> about something similar to D2RQ, but object-oriented.  
>>>>>>>> However, I'd like to
>>>>>>>> know if there's any work already done about this subject.
>>>>>>>>
>>>>>>>>
>>>>>>> your OOobject is your RDFsubject, your OOobject property is  
>>>>>>> your RDFpredicate, and your OOobject property's value(s) is/ 
>>>>>>> are your RDFobject(s) (mind the nameclash)
>>>>>>>
>>>>>>> your OOobject have URI fields, of course.
>>>>>>>
>>>>>>> this also works with JSON.. which can be thought of as an  
>>>>>>> OOobject serialization, and compatible with RDF so long as  
>>>>>>> your property-symbols are URIs and each JSONobject has a URI  
>>>>>>> property
>>>>>>>
>>>>>>>
>>>>>>> theyre pretty much identical. even RDFs with its subclassing  
>>>>>>> and subtyping is an OO model.. replace 'object' with  
>>>>>>> 'resource' in the literature
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>>
>>>>>>>> Pedro
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> begin:vcard
>>>>>>>> fn:Jose Pedro Ferreira
>>>>>>>> n:Ferreira;Jose Pedro
>>>>>>>> org:CERN;IT-UDS-AVC
>>>>>>>> adr:;;;Geneva;;;Switzerland
>>>>>>>> email;internet:jose.pedro.ferreira@cern.ch
>>>>>>>> title:Software Developer
>>>>>>>> tel;work:+41 22 76 75025
>>>>>>>> tel;cell:+41 763 045 795
>>>>>>>> x-mozilla-html:FALSE
>>>>>>>> url:http://www.zarquon.biz
>>>>>>>> version:2.1
>>>>>>>> end:vcard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jesse Erdmann
>>>>> jesse@jesseerdmann.com
>>>>> Twitter: http://twitter.com/jesseerdmann
>>>>> Blog: http://blog.jesseerdmann.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> <jose_pedro_ferreira.vcf>
>>
>> -- 
>> Dr Ioannis N. Athanasiadis
>> IDSIA - Istituto Dalle Molle di Studi sull'Intelligenza Artificiale
>> Galleria 2, CH-6928 Manno, Lugano, Switzerland
>> tel: +41-586-666-671 fax: +41-586-666-661 mob: +41-798-141-680
>> ioannis@idsia.ch - www.idsia.ch - www.athanasiadis.info
>
>
> <jose_pedro_ferreira.vcf>
Received on Tuesday, 5 February 2008 13:23:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:35 UTC