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-S20 > 090325-200903251303/javadoc/org/eclipse/higgins/idas/api/IEntity.html > <http://download.eclipse.org/technology/higgins/downloads/idas.api/builds/S-S2 > 0090325-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
