|
Welcome Guest | Login | |
|
Index
| Recent Threads
| Who's Online
| User List
| Search
| Help
| 
|
|
Forum has been closed down This forum has been closed down due to extensive spamming activities. Please use the mailing list instead. |
 |
openRDF.org Forum » AliBaba & Elmo: Open Discussion » Thread: Merging object composition code of Elmo and Alibaba into individual project |
|
Total posts in this thread: 4 |
[Add To My Favorites] [Watch this Thread] |
| Author |
|
|
Jul 29, 2009 3:36:36 PM
kenwenzel Member
|
Hallo, I'm working on a project which integrates Sesame with the Eclipse RCP world. We've done this by adapting ideas and code of Eclipse EMF to create a runtime environment and editing framework for ontologies within the Eclipse runtime environment. The RDF data binding is realized with Elmo. For the representation of RDF objects the editing framework uses adapters which are created by an adapter factory. Currently the adapter factory investigates the rdf:types of each object and instantiates a matching adapter for this set of types (e.g. by using the adapter for one of the most specific types). It would be nice to use object composition for creating the adapters in a similar way to Elmo and Alibaba which combine different concepts and behaviors to create RDF objects. Are there any plans to refactor the object composition logic in a separate project? Best regards, Ken Wenzel |
||
|
|
Jul 30, 2009 3:39:14 AM
james OpenRDF.org Consultant Canada Joined: Jul 21, 2005 Posts: 650 Status: Offline |
The object composition code is heavy tied to the persistence model. The notion of an object-store with a connection scope is essential to the architecture of the object composition. This is apparent in the object types' dependence on the rdf:type property at the time the object is loaded. Swapping the RDF persistence with a hibernate (or sql-jpa) solution would be difficult as most existing object-persistence frameworks also have own composition that may interfere. An in-memory solution (optimized for objects) may give better getter/setter performance, but would loose all the query functionality of the RDF store. Once SPARQL supports updates, the portability of an rdf-object-store like Elmo/AliBaba will increase and the possibility of using other storage solutions, like an RDF-SQL store (with an existing SQL schema) will become more common. From what I gather you have adapter factories that you don't want to live in the primary RDF store, but you do want them to behave like other composed objects. This could be overcome in a few ways without pulling the object-composition out into its own library: 1) Have two object-stores, the second is an additional in-memory RDF-store that contains all the configuration properties (and types) for these adapter factories. Switching between stores maybe a little tricky, but possible. 2) Federate an read-only memory store of these adapter configurations with the primary RDF store. This can create a seamless union between models without putting configuration data into the primary RDF store. AliBaba's Federation can be used in this way with Sesame 2.3 (and also with Elmo 1.5), but is a little trick to setup. 3) If these adapter factories are singletons and don't have any persisted properties, you can use the @oneOf annotation to map concepts/behaviours to the resource URI even if no information about it exists in the RDF store. 4) In AliBaba I have been experimenting with a new annotation for composing concepts/behaviours based on resource URI patterns. This, like @oneOf, allows objects to be composed without any information existing in the RDF store, but is applied by URI pattern instead of explicit resource URIs. Hope this helps. ---------------------------------------- Sesame Consultant http://leighnet.ca http://jamesrdf.blogspot.com |
||
|
|
Jul 30, 2009 10:28:41 AM
kenwenzel Member
|
Thank you for your answer.
This is one of the ideas that also came into my mind. This should work if the manager associated with the federation only knows the adapter concepts and behaviors but not the entity concepts. A problem of this approach is the way how SesameManager instantiates objects. There is the minor problem that SesameManager does not support caching (and therefore reusing) of bean instances. This is crucial if the objects keep transient state (like operating system resources, etc.), but this issue could be resolved in the same manner as described in this post. The other problem arises because SesameManager creates a bean for a unique resource and not a set of RDF types. This prevents an adapter from being shared by different objects with the same set of types. |
|||
|
|
Jul 31, 2009 7:54:39 PM
james OpenRDF.org Consultant Canada Joined: Jul 21, 2005 Posts: 650 Status: Offline |
Transient properties are part of the processing logic and not part of the domain model logic. This makes them out of scope for Elmo or AliBaba. However, AliBaba introduces an ObjectFactory that should make these sorts of hacks easier. It separates the object creation/initialization away from the object manager/connection. Elmo supports @intersectionOf annotation for assigning a common concept/behaviour between object of the same set of types. However, you have to know what the set is in advance. You could also introduce an inferencing rule that assigns an adapter property based on the current rdf:type properties. AliBaba introduces @triggeredBy annotation to execute methods when triples with particular predicates are committed in the RDF store. ---------------------------------------- Sesame Consultant http://leighnet.ca http://jamesrdf.blogspot.com |
||
|
| [Show Printable Version of Thread] |
