[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Which ontology to reference
|
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>
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>
## 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>
## 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>
## HTH, Paul
[1] 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>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/09/2009 05:25 PM
higgins-dev <higgins-dev@xxxxxxxxxxx>
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>
> 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>
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
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
