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