Paul, Thanks for the response. From my understanding of your comments, you understand the difficulty I am having between IdAS-resolvable entityRelations and non-IdAS-resolvable RDF relationships. I am still a little confused on how your suggestion for applications determine the difference will work. But, I think I will fork that into a new thread. As for the entityId attribute:
I have three use cases where I do not understand how to use the HOWL1-1-106.rdf schema as a concrete schema for my context provider and/or application and reference the required Higgins IdAS entityId attribute. 1.) Using OWL/RDF tools to generate java objects for use in a context provider I am using an ontology database as an identity store. The tools for this database can take an OWL/RDF schema file and generate java value objects for the data objects in the DB. I then want to wrap those java objects inside an IdAS CP and expose them as IEntity objects. The problem here is that the code generated for the ontology database does not include the entityId attribute. So, there is no way to return, set, or persist the entityId in the ontology database. The entityId literally does not exist in the schema, so there is no way for the code generation tool to create the java code to manipulate the attribute in the DB. 2.) Applications use OWL tools to generate pojo objects for objects in a repository Application developers want to generate pojo objects using OWL/RDF tooling and populate those objects with calls to IdAS. The application level objects generated from the tools will not contain the unique entityId identifier. 3.) Serializing an object based on the context providers schema An application needs to serialize an object returned from IdAS based on schema provided by the context provider (either published or retrieved from the iModel interface on the Context object). The serialized object will not contain the entityID. I hope these make sense. Thanks, David David Kuehr-McLaren Tivoli Security 919.224.1960 Paul Trevithick <[email protected]> Sent by: [email protected] 04/15/2009 09:41 PM Please respond to "Higgins \(Trust Framework\) Project developer discussions" <[email protected]> To higgins-dev <[email protected]> cc Subject Re: [higgins-dev] Which ontology to reference David, I have responded to your email below in <pt/> sections. And explained CDM as it is currently defined. I actually see a closely related but different problem with CDM. As I explain below, at present all relations are presumed to be EntityRelations and if you want to have an opaque (nonEntity-valued) URI as a value you must define a simple-valued attribute (e.g. A URI string-valued attribute). The problem is that this means that we can?t reuse ?as is? existing RDF/OWL ontologies (e.g. FOAF) because within CDM the presumption is that you can resolve the target (range) of all relations to Entities. In the example you and I use below, the ?foaf:homepage? property has value is a Web address. This web URI doesn?t resolve to an Entity (e.g. An Entity exposable by IdAS). So therefore the foaf:homepage relation can?t be reused directly. This needs more thought. --Paul On 4/10/09 12:20 PM, "David Kuehr-McLaren" <[email protected]> wrote: Paul, Thanks again. I am still having trouble. See my comments <dkm> like this </dkm> David David Kuehr-McLaren Tivoli Security David, see ## inline. On 4/9/09 6:10 PM, "David Kuehr-McLaren" <[email protected] < [email protected]> > wrote: Paul, Thanks. That makes it more clear. But now I am confused by the relationship of HOWL to IdAS. IdAS only returns Entities. ## This is all a bit hard to understand. In IdAS things are called Entities. In RDF things are called resources. The difference is that in RDF things are identified by HTTP URI identifiers (only), whereas in IdAS (well, the Context Data Model) things are identified by UDIs (more abstract identifiers). As a result we can only approximate Entities using RDF. The fundamentals are different. <dkm> I think I understand the problem. The CDM schema defines a entityRelations as a URI with a label and comment to the reader that it should be treated as a UDI. The CDM is conceptual model approximated in RDF. But there are relationship attributes in the HOWL that are defined as URIs, like "member" ("part"). I assume that "member" is an entityRelation, but there is no way for the tooling or the human reader of the HOWL schema to know this. My extension may contain URI properties, like "myWebPage". >From the model, there is no way to tell entityRelations from legitimate URIs. </dkm> <pt> All entityRelations are object-valued (i.e. Entity-valued). Unlike regular RDF, all Entities must be resolvable. You are correct that if you want to have an attribute like myWebPage (or foaf:homepage as shown below) that has an opaque (non-IdAS-resolvable) value then in regular RDF you can just say something like: <foaf:homepage rdf:resource="http://www. davidkuehr-mclaren .com"/> where the range of foaf:homepage is an RDF Resource of type ?Document? (according to FOAF) identified by an opaque URI. OTOH in CDM you would have to define a simple-valued attribute (e.g. whose value was an xs:anyURI string). So you could define ex:homepage whose value was a URI: <ex:homepage rdf:resource="http://www. davidkuehr-mclaren .com"/> In the above the value of ex:homepage is NOT an Entity. </pt> ## However there is a lot of utility in the existing RDF/OWL tools. So in order to make it easier to use the off the shelf RDF/OWL tools (such as the SWOOP and Protégé that you mentioned), in Higgins 1.1 we split higgins.owl into higgins.owl (which describes new OWL classes like Agent, Group, etc.) and cdm.owl that describes the ?meta? model of Entities interconnected with UDIs. <dkm> The resulting schema (and any automated generated classes, data tables, etc.) built from RDF/OWL tool is missing the entityId and entityRelationship properties. The output of the tooling can not be used by the context provider author or the appliction author without these fundemental properties. </dkm> <pt> At present in CDM all relations (e.g. your ?member? above) are presumed to be entityRelations. As for your comment about missing the entityId properties I don?t understand why you say that. Can you elaborate? </pt> ## The latter, cdm.owl is really only for humans to look at. It uses RDF to describe the more abstract foundation (Entities and UDIs) in a shallow way even though RDF-based tools can?t more deeply operationalize the definitions. In order to build an ontology for my context provider that uses the HOWL objects, it appears I will need to add the Agent object (as well as other objects types) to my own exstension of the CDM, in order to treat the Agent objects as Entities. Is that the correct approach for building the schema for a context provider? ## No. As mentioned above cdm.owl should not be imported into your ontology or used at all when building ontologies. Just import higgins.owl and define your own subclasses and properties. Let?s say that you define a subclass, Foo, of the Agent class in higgins.owl. If you go ahead and implement your ontology in an IdAS Context Provider, this CP may well return an instance of Foo<-- this Foo instance would be a java class that implements the IEntity interface [1]. But unlike in Higgins 1.0 your Foo class (in your ontology) is NOT a subclass of a class named ?Entity?. <dkm> OK, but now it seems I need to add entityId and entityRelation to my HOWL1.1 exstensions in order to have a schema that describes to the application what they will get back in Foo. Also, this statement, "implement your ontology in an IdAS Context Provider" implies that the CP author will hand code the ontology. My goal is to dynamically generate the CP and the IEntity based on the extended HOWL RDF/OWL file. </dkm> <pt> WRT your first statement, I think I?ve explained that all relations are presumed to be entityRelations. As I mention above, I don?t understand why you nee to add an entityId attribute. </pt> ## HTH, Paul [1] http://download.eclipse.org/technology/higgins/downloads/idas.api/builds/S-S20090325-200903251303/javadoc/org/eclipse/higgins/idas/api/IEntity.html < http://download.eclipse.org/technology/higgins/downloads/idas.api/builds/S-S20090325-200903251303/javadoc/org/eclipse/higgins/idas/api/IEntity.html > Thanks, David David Kuehr-McLaren Tivoli Security 919.224.1960 Paul Trevithick <[email protected] <[email protected]> > Sent by: [email protected] <[email protected]> 04/09/2009 05:25 PM Please respond to "Higgins \(Trust Framework\) Project developer discussions" < [email protected] <[email protected]> > To higgins-dev <[email protected] <[email protected]> > cc Subject Re: [higgins-dev] Which ontology to reference Hi David, That was confusing indeed! I have replaced the word ?Entity? in the second sentence with the word ?Agent.? [All classes (including Agent) and instances thereof in higgins.owl 1.1 are types of Higgins Entities. But when modeling in OWL we don?t directly use Entity directly. ] --Paul On 4/9/09 3:48 PM, "David Kuehr-McLaren" <[email protected] < [email protected]> <[email protected] <[email protected]> > > wrote: I am having trouble understanding the instructions to Context Provider authors regarding extending the higgins ontology as per the Context Data Model 1.1 page. (I apologize in advance, if this is a basic OWL question or is documented elsewhere on the wiki) http://wiki.eclipse.org/Context_Data_Model_1.1#Building_on_higgins.owl_1.1 < http://wiki.eclipse.org/Context_Data_Model_1.1#Building_on_higgins.owl_1.1 > < http://wiki.eclipse.org/Context_Data_Model_1.1#Building_on_higgins.owl_1.1 < http://wiki.eclipse.org/Context_Data_Model_1.1#Building_on_higgins.owl_1.1 > > In the section "Building on higgins.owl 1.1 " it states " Developers must create specialized ontologies based on HOWL that describe specific concrete domains.For example, if a developer wanted to describe a CRM database, she would create an OWL ontology that would describe the data objects in the CRM database. This CRM database is called a Context in Higgins. If, for example, the database contained records about customers and those customers had full-names and email addresses, then the developer would define "Customer" as a sub-class of Entity and "full-name" and "email" as kinds of Attributes." The first sentence implies the developer should be using the "upper" ontology higgins1.1 owl. But the last sentence tells the developer to reference the CDM and subclass Entity. Intuitively, I think i would want to subclass Person from HOWL for a Customer object. But Agent does not seem to subclass Entity. When I use OWL modeling tools like SWOOP or Protoge, I can not figure out how to subclass Agent as an Entity. Thanks for any guidance, David David Kuehr-McLaren Tivoli Security Identity Integration Architecture 919.224.1960 _______________________________________________ higgins-dev mailing list [email protected] <[email protected]> https://dev.eclipse.org/mailman/listinfo/higgins-dev < 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
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
