You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Mihai Radulescu <mi...@salzburgresearch.at> on 2013/05/02 17:24:44 UTC

[PROPOSAL] Marmotta Object Oriented Mapping Client

Dear Marmotta developers,



My name is Mihai Radulescu, I am original from Romania/Bucharest and I am a 39 year old Software Engineer. 
I experience the Java landscape since 96-97 in different countries, enterprises, institutions and projects. 
Since some years, four to be precisely, I was involved in some projects related with the semantic web / semantic technologies (e.g. KiWi). Since then I have the chance to try some of  most popular Semantic tools out side there, some of my last contributions  are/was in the semantic interoprability (iCardea) or (smart) search (iMedication) field; both projects are in the eHealth domain. My actual activity area is still interoperability between two big eHealth "domains" : hl7 and openEHR, the involved project is named EMPOWER. 

I try to cristalize all my semantic web / semantic technologies experience in to a open-source project meant to be a generic client  for any RDF Repository. It's name is Rockanrolla and it is hosted by the Github (under Apache License).

I was following the Marmotta project since  begining  and I  would like to propose to integrate the Rockanrolla (generic) RDF client in to the Marmotta project. 
In a very simplistic way the Rockanrolla (generic) RDF client is similar with the Marmotta facade mechanism. But in the same time it something more; one of the most significant difference is that the facades can only exist in the Marmotta context. The Rockanrolla (generic) RDF client models can exists out-side of the Marmotta boundaries (and they may be part of an already existent business).

Here is a "small"  Rockanrolla (generic) RDF client project  description.

The  Rockanrolla frame-work main goal is to allow mapping between different object oriented (OO) data manifestation and any other kind of data representation. For simplicity this document will focus only on the mapping between the OO Data Models and RDF graphs.

As it is mentioned before the  Rockanrolla framework is meant to allow mappings between different Object Oriented Data Models (e.g. Java Beans, Python Beans, Groovy beans, C# beans, JSON objects) and RDF graphs and this without to alter the existing application business and without coupling the application to any underling RDF repository.

This idea is not new, the last decades brought us a lot of Object Mapping Frameworks more or less specialized (e.g JBoss-Hibernate, Sesame-Elmo, Jenabean, etc.) and this raises  a simple question, why do we need a new framework ? I hope that the rest of the text will convince you why.

For a better understanding let’s imagine a simple scenario, we are dealing with an already existent classic application based on relational database and POJOs. The application is working fine but from some reasons we need to enrich the business with new functionality like: better querying (than JPQL), reasoning, make use of existing (industry accepted) taxonomy/terminology; and most important the existing application remains the same we are allowed to change/touch the code.

The Rockanrolla aims is to allow the developer(s) to make use existing models (POJOS in the upper described scenario)and to extend the business without to apply any change it the existing code. 
In order to accomplish this the developer must specify meta-data (using one of the  Rockanrolla RDF client  specific methods) and use this metadata togethger with a RDF repository of his/her choice. Until here the functionality is similar with other existing solutions (Sesame-Elmo, Jenabean); what makes the Rockanrolla (generic) RDF client  unique is (beside its independence of the underlying RDF repository) its ability to generate dynamic fields and to insert them in to the run time objects. In this way the existent data models remain as they were before and the developers don’t need to care about persistence specific fields. e.g. in the relational world each persisted bean must cary a ID field, this field is only used by the persistence mechanisms, in the Rockanrolla “world” if the id field is dynamic inserted.

A secondary Rockanrolla goal is the aim to provide the upper described functionality for more than Java; Groovy, Python, JavaScript and C# are all possible candidates. In this way we can talk about a common developing (RDF specific) methodology over more paltforms. Until now, most of the existent solutions are bound to Java and (some of them) only to a specific triple-store.

The third Rockanrolla goal is to reduce the amount of "glue" code. The classical approach leads to a big amount of classes (e.g., POJOS) meant only to hold data. In the Rockanrolla approach the developer can define data-views by using meta-data and let the framework to manifest  them during run time in the format of his/her choice (e.g., JavaBeans, JSON or C# bean). Similar approach exist already; e.g., sesame-emlo is able to generate (java) classes hierarchy after given RDF file(s). The Rockanrolla  client  is able to embed in to the same data model (class) different graph nodes and sides, in this case the developer is able to filter and use only the needed information - the developer can control how the generated data-view is mapped to the udnerlying graph.

Here are some  Rockanrolla (generic) RDF client  features :
Dynamic ID filed injection. This feature allows you to dynamical create a new filed and associate it with a URL of your choice (able to ). Please notice that the new ID filed is not part of the original model; this field is dynamical created. By using this feature you can extend the classic static java bean model where all the fields and related access methods must be defined before compile.  
Static annotation, Active Annotation, and Groovy meta-data support. 
The active annotation support allows you to extend the classic/static annotation support by letting the (java compiler) to work for you and alter mutable java elements.
The Groovy meta-data support allows you to define meta-data for your models like (runnable) Groovy code. It can serve like a replacement(alternative) for the annotation mechanism. Groovy can be very useful by defining DLSs, this DSLs can be reused because they are only business specific - they are independent on the model. 
Read-only / read-write data-view. Read Only are preferment because they can be use in the multithread env. without to care about the state. 
LDPath support. You can related fields in your model with LDPath (expressions).
Life cycle listeners.
Independence of RDF repository.
Undo-Redo support (Independence of RDF repository).
Audit (change management) 
So, summarizing, first I would like to discuss the idea and find potential synergies with other developers of Marmotta, and in case you find in interesting I will be happy to contribute it to the project.
 

Thanks in advance,
Mihai







 




Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by Sergio Fernández <wi...@apache.org>.
Hi Mihai,

On 04/05/13 22:19, mihai.radulescu@salzburgresearch.at wrote:
>> Well, more than java-doc or whatever formal documentation, I'd prefer to
>> see a few example how rockr0lla looks like: how to use it, how the
>> approach differs in the languages you have commented, etc.
>
> In the coming weeks I will invest more time in the rockr0lla, I will provide
> more examples (test and documentation). I already start to work on a tutorial.
> The tutorial will be also available on the github site.
> My proposal is: I will improve the actual source-code(with example and
> documentation) and I will notice you about the progress.

That would very helpful, indeed. But actually we are not requiring so 
huge effort. At least from my point of view, some code snippet could be 
enough fro having a better understanding of your proposal, and therefore 
being able to evaluate it in the context of Marmotta.

As soon as you have something else to share with us, please reactivate 
this thread.

Thanks! :-)

-- 
Sergio Fernández

Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by mi...@salzburgresearch.at.
Dear Sergio

> Well, more than java-doc or whatever formal documentation, I'd prefer to
> see a few example how rockr0lla looks like: how to use it, how the
> approach differs in the languages you have commented, etc.
>

In the coming weeks I will invest more time in the rockr0lla, I will provide 
more examples (test and documentation). I already start to work on a tutorial.
The tutorial will be also available on the github site.
My proposal is: I will improve the actual source-code(with example and 
documentation) and I will notice you about the progress.

> For instance, comparing with the current Sesame Façading [1] could help
> us to get a more proper overview of your proposal.

This is(will be contained) in the tutorial.

> As you know, I find > the topic very interesting, and I'd like to refresh 
some ideas I  experiment with some years ago in my master degree thesis.
I know, I inspire my self (a little) from your material  - I have the link 
form you ;).

Best Regards,
Mihai

Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by Sergio Fernández <wi...@apache.org>.
Hi,

On 03/05/13 12:07, Mihai Radulescu wrote:
> The code is not in its best form - it is in the experimantal phase.
> What can be seen is the core, the component that provide support for
> the annotation and groovy meta-data. There are some unit tests and I
> start to write java-docs.

Well, more than javadoc or whatever formal documentation, I'd prefer to 
see a few example how rockr0lla looks like: how to use it, how the 
approach differs in the languages you have commented, etc.

For instance, comparing with the current Sesame Façading [1] could help 
us to get a more proper overview of your proposal. As you know, I find 
the topic very interesting, and I'd like to refresh some ideas I 
experiment with some years ago in my master degree thesis.

Cheers,

[1] http://marmotta.incubator.apache.org/sesame.html
[2] http://trioo.wikier.org

-- 
Sergio Fernández

Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by Mihai Radulescu <mi...@salzburgresearch.at>.
First, thanks fro your welcome notes. :).


> On 02/05/13 18:11, Jakob Frank wrote:
>> could you please provide a pointer to the github repo
> 
> The current code is at: https://github.com/dicentim/rockr0lla
> 

True, the code is available on the Github, I attach the URL to my last mail but the mail list filter wipe it out.

> I guess the mailing list has filtered the html of his email, removing all formatting and links. I already pointed this issue to Mihai, and he's going to provide all the links (quite useful to understand the prose).
> 
> +1 to see some code snippets :-)
> 

I send yesterday a mail with a set of links to the marmotta-dev list. One of the list if the GitHub repo.

The code is not in its best form - it is in the experimantal phase. What can be seen is the core, the component that provide support for the annotation and groovy meta-data. There are some unit tests and I start to write java-docs.

If you have any questions I will de delighted to answer them. If you consider we can have an IRC chat and we can publish the protocol.
 

Best Regards,
Mihai

Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by Sergio Fernández <wi...@apache.org>.
On 02/05/13 18:11, Jakob Frank wrote:
> could you please provide a pointer to the github repo

The current code is at: https://github.com/dicentim/rockr0lla

I guess the mailing list has filtered the html of his email, removing 
all formatting and links. I already pointed this issue to Mihai, and 
he's going to provide all the links (quite useful to understand the prose).

+1 to see some code snippets :-)

Cheers,

-- 
Sergio Fernández

Re: [PROPOSAL] Marmotta Object Oriented Mapping Client

Posted by Jakob Frank <ja...@apache.org>.
Hi Mihai,

welcome to the Marmotta-DEV mailing list!

Your proposal sounds very interesting and might open up a number of new
usage scenarios not only for Marmotta but for RDF/LinkedData in general.

I'm curious how your approach differs, regarding usage in the code,  to the
facading mechanism we currently have in Marmotta.

For that, a first insight into the code, more details on the idea and to
get some examples - could you please provide a pointer to the github repo?
(Often some lines of code say more than pages of prose ;-) )
Thanks!

Best,
Jakob