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_ModelIt
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
