Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Newbie question: Higgins Ontology (HOWL XML File) to Java Model Classes (EntityModel, AttributeModel) Mapping. How does it work?

I guess the reason why there is no such automatic mapping component is that most of the time people don't care to actually write down the ontology of their CP as RDF/OWL, but still implement the Model API. If that was more common, then yes such a component would make sense.

Another reason is that some CPs simply don't have a single, fixed domain ontology. It may be different in each context that they instantiate. As you can see on the IContext interface there's a getSchema() method. This is supposed to return the ontology (in OWL) of a particular context. That schema can also be discovered through UDI resolution (see http://www.azigo.com/company/dev/udi/), i.e. before actually opening a context.

Markus

On Thu, Jul 9, 2009 at 11:23 AM, <Berend.Boll@xxxxxxxxxxxxx> wrote:
Hi Markus,
 
thank you for your advice. As you guessed I am thinking about the case 3 in your list, the concrete domain ontology or the schema of the CP. I was confused that there is no "automatic" mapping, when I create a context in Higgins via the Higgins registry, because I saw all the "Model" classes in the Higgins Java code. I will take a look at the special Jena CP for the OWL/RDF handling.
 
- Thanks
Berend
 


Von: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Markus Sabadello
Gesendet: Montag, 6. Juli 2009 20:15
An: Higgins (Trust Framework) Project developer discussions
Betreff: Re: [higgins-dev] Newbie question: Higgins Ontology (HOWL XML File) to Java Model Classes (EntityModel,AttributeModel) Mapping. How does it work?

Hello Berend,

I am not sure exactly what you mean with "Higgins ontology XML file". There are three things to be distinguished here:

1. The cdm.owl file in the org.eclipse.higgins.ontology project.
This is what we call the Higgins "Context Data Model". You can read about it here:
http://wiki.eclipse.org/Context_Data_Model
It defines the very basic foundations (Contexts, Entities, Attributes) of our data model. The cdm.owl file is meant only for documenting purposes. It is basically an RDF/OWL file describing the same concepts as the above wiki page, but this file is never used programmatically.

2. The higgins.owl file in the org.eclipse.higgins.ontology project.
This file is based on the above "Context Data Model". This is an "upper ontology" which is meant to serve as a basis for concrete domain ontologies (see next point). It describes some more advanced features which we actually use programmatically in IdAS. For example, it describes an access control mechanism, and how to make statements about attributes (e.g. lastModified, creator, ...)

3. A concrete domain ontology (aka as the schema of a Context Provider).
Maybe this is what you referring to. This defines the concrete classes of Entities and Attributes in a Context Provider, like employee, supplier, e-mail address, friend, etc. IdAS itself doesn't define these things, it's up to the individual Context Providers to do this (well, you probably know this already). Anyway, the point is that therefore Context Providers also have their own code for implementing the IdAS Model API and returning "models" for their Entities and Attributes. Some CPs can be very restricted (e.g. allowing only a few predefined Entity and Attribute classes), whereas others can be very open (allowing pretty much anything).

If you create your own Context Provider, I would say that it is good practice - but not required - to write down its domain ontology in an RDF/OWL file, potentially using some parts of higgins.owl.

Maybe you have already created such a domain ontology, and now you want to automatically create Model classes based on it. Is this what you are asking?

Conceptually I guess this would make sense. I don't think we have code for automatically "converting" a domain ontology (expressed in RDF/OWL) to a set of Java classes that can be used for the IdAS Model API. BUT: We have one Context Provider (the Jena one) which internally stores its data as RDF. It properly supports the IdAS Model API. This means that the code in the Jena Context Provider could come very close to what you are looking for. For example, if you call getAttributeModels() on an Entity from the Jena CP, it will take a look at its own ontology and return IdAS Model objects for the RDF Properties it finds.

If this sounds promising, have a look at the Java package org.eclipse.higgins.idas.model.impl in the org.eclipse.higgins.cp.jena2 project.

Hope that helps a bit, let us know if you still have questions..

Markus

P.S. The only reason why the XMLFile Context Provider doesn't support the IdAS Model API is that nobody has written it; conceptually it could support it.

On Fri, Jul 3, 2009 at 5:02 PM, <Berend.Boll@xxxxxxxxxxxxx> wrote:
Dear Higgins Team,

we are currently looking into the Higgins project as a base implementation for an IdAS/Context Provider solution for our user profiles distributed over different application silos.

One key point we are still having problems with, is the question how to map the Higgins Ontology (as defined in an XML file) to the actual "Model" classes in the java code (EntityModel, AttributeModel) that can be accessed via the "getModel()" method.

For example, the Higgins 1.0 solution for the XMLFile Context Provider does not implement such a mapping. The "getModel" method is just not implemented here.

Also I can find no source code that may do such a "generic" scanning and conversion of the Higgins ontology XML file. From my partial understanding of Higgins so far, I would think that this mapping task is similar for each context, because the Higgins ontology is specified. So I do not have to implement such a mapping for each context provider, but can reuse some conversion method implemented in the Higgins framework.

Is that so? And if yes, where is it done? What code can I reuse, when I write my own context provider?

Any help to get me on the right direction will be appreciated.


Kind regards,
Berend Boll
T-Systems Enterprise Services GmbH
Systems Integration
Project Delivery Unit Telco
IP Products Service & Network
Berend Boll
IT Systems Architect
Goslarer Ufer 35, 10589 Berlin
+49 30 3497-3246 (Tel.)
+49 30 3497-3247 (Fax)
+49 170 7641785 (Mobil)
E-Mail: berend.boll@xxxxxxxxxxxxx
Internet: http://www.t-systems.com

T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, Dr. Matthias Schuster, Klaus Werner
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644


Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top