Re: [higgins-dev] Which ontology to reference

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

Paul, 

Any further guidance on how CP and applications
writers can use the HOWL 1.1 in regards to tooling that handle OWL and
RDF? I am currently focused on the third use case, serializing an IdAS
object based on the CPs schema, which, if it extends from HOWL1-1-106.rdf
does not contain entityid and definition of the entityRelationship attribute.


Thanks, 

David 

David Kuehr-McLaren 
Tivoli Security
919.224.1960

David Kuehr-McLaren/Raleigh/IBM@IBMUS
Sent by: higgins-dev-bounces@xxxxxxxxxxx

04/17/2009 05:54 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

To	"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc	higgins-dev <higgins-dev@xxxxxxxxxxx>, higgins-dev-bounces@xxxxxxxxxxx
Subject	Re: [higgins-dev] Which ontology to reference

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 <ptrevithick@xxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

04/15/2009 09:41 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

To	higgins-dev <higgins-dev@xxxxxxxxxxx>
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" <dkuehrmc@xxxxxxxxxx>
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" <dkuehrmc@xxxxxxxxxx
<dkuehrmc@xxxxxxxxxx>
> 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 <ptrevithick@xxxxxxxxx
<ptrevithick@xxxxxxxxx>
> 
Sent by: higgins-dev-bounces@xxxxxxxxxxx
<higgins-dev-bounces@xxxxxxxxxxx>
04/09/2009 05:25 PM 
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"  
   <higgins-dev@xxxxxxxxxxx
<higgins-dev@xxxxxxxxxxx>
> 
To 
higgins-dev <higgins-dev@xxxxxxxxxxx
<higgins-dev@xxxxxxxxxxx>
> 
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" <dkuehrmc@xxxxxxxxxx
<dkuehrmc@xxxxxxxxxx>
<dkuehrmc@xxxxxxxxxx
<dkuehrmc@xxxxxxxxxx>
> > 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
higgins-dev@xxxxxxxxxxx
<higgins-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/higgins-dev
<https://dev.eclipse.org/mailman/listinfo/higgins-dev>

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev