Exactly, thanks Markus. On 7/9/09 1:15 PM, "Markus Sabadello" <[email protected]> wrote:
> 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] >> <http://[email protected]> " <[email protected] >> <http://[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] >>>> <http://[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] >>>> <http://[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] <http://[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] <http://[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
