David,
Let me start by trying to understand your 1.) below by using a concrete
example. Let's say that the ontology data base includes the following RDF
statements in N3:
ex:david
a ex:Employee ;
foaf:firstName "David" .
In the Higgins CDM model, the resource ex:david is called an Entity. Its
canonical EntityId is "ex:david", it has one attribute "foaf:firstName"
whose value is "David", and it states that ex:david is an instance of
ex:Employee. In IdAS we'd expect this to be exposed an an IEntity [1]
instance such that if you were to invoke getEntityId() [to be renamed
getCanonicalEntityId() in Higgins 1.1] on it , it would return the value
"ex:david" (or, at the option of the context provider developer, a shorter
version of same that was still unique within the Context).
You said that the tool you are using can generate java objects. What java
instance would it generate for the above set of two triples? You imply that
it would generate a Java instance that has no "ex:david" identifier member.
--Paul
[1]
http://download.eclipse.org/technology/higgins/downloads/idas.api/builds/N-N
20090514-200905140501/javadoc/org/eclipse/higgins/idas/api/IEntity.html
On 4/17/09 5:54 PM, "David Kuehr-McLaren" <[email protected]> wrote:
>
> 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]
> <[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]> <[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 <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 <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>
> <http://download.eclipse.org/technology/higgins/downloads/idas.api/builds/S-S2
> 0090325-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]>
> <[email protected] <[email protected]> > >
> Sent by: [email protected] <[email protected]>
> <[email protected] <[email protected]> >
> 04/09/2009 05:25 PM
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions"
> <[email protected] <[email protected]> <[email protected]
> <[email protected]> > >
> To
> higgins-dev <[email protected] <[email protected]>
> <[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]> >
> <[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> >
> <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]> <[email protected]
> <[email protected]> >
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> <https://dev.eclipse.org/mailman/listinfo/higgins-dev>
> <https://dev.eclipse.org/mailman/listinfo/higgins-dev
> <https://dev.eclipse.org/mailman/listinfo/higgins-dev> >
>
> _______________________________________________
> 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
