Hi Paul, I think you forgot to include a link in your reply. I assume you meant this: http://wiki.eclipse.org/Higgins/ModelAPIs The idea there was to say Models are Entities themselves instead of specialized interfaces.
Markus On Thu, Jul 9, 2009 at 4:32 PM, Paul Trevithick <[email protected]>wrote: > Berend, > > We would like to replace the Model interfaces in IdAS entirely for Higgins > 1.1 (see [1]). We’re looking for volunteers :) > > --Paul > > > On 7/9/09 5:23 AM, "[email protected]" <[email protected]> > 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:* [email protected] [ > mailto:[email protected] <[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 > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
