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: [email protected]
[mailto:[email protected]] 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, <[email protected]> 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: [email protected]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
