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
