Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] IProperty getType()

Jim wrote:

Paul,

 

When I add getType() to IPropertyValue, then I need to implement it in the 35 basic simple value impls under org.eclipse.higgins.idas.impl (BasicValue*.java). Currently, I can implement three of these (BasicValueString.java, BasicValueNormalizedString.java, and BasicValueBase64Binary.java). We need to add the rest to the higgins.owl so I have a URI.

 

For now, I suppose I can make up the URIs which I think you will use.

 

Yes, at this point I hope I’m completely predictable!

 

BTW, I assume http://www.eclipse.org/higgins/ontologies/2006/higgins#normalizedStringSimpleValue is the proper URI for the example you use below

 

That’s not quite what I meant. Assume I have an instance of a DigitalSubject subclass called Person. Assume that this Person has an attribute “eyeColor” whose value is the literal “blue”. I would expect that through your IProperty.getType() would return the “eyeColor” URI. The new IPropertyValue.getType() could return one of the following:

 

 (a) the URI of the higgins:Attribute subclass (i.e. higgins:NormalizedStringSimpleAttribute)

 (b) the URI of the higgins:SimpleValue subproperty that the Attribute mentioned in (a) has, that has as its range the literal “blue” (i.e. higgins:normalizedStringSimpleValue)

 (c) the URI of the type of the literal “blue” value (what the property higgins:normalizedStringSimpleValue has as its range) (i.e. xsd:normalizedString)

 

In my email below I implied the best answer was (a), though you thought I meant (b). But now that I look at it, I think (c) is even better.

 

It (c) even works for complex types: If, instead of a simple literal, the Person had a complex PostalAddress, then (c) would return the URI of this OWL-defined class “PostalAddress”.

 

Jim

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 9/26/06 9:19 AM >>>

Ah, makes sense.  I agree, we should add that method and I'll re-work the doc. 

 

It probably makes sense somewhere to document the analogies between the APIs and the OWL/RDF output.

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 9/25/06 8:42 PM >>>

Hi Jim,

My proposal is that IPropertyValue.getType() would return the URI of the Attribute subclass. For example, it might return the URI for NormalizedStringSimpleValue (per the latest higgins.owl 0.5.7). A NormalizedStringSimpleValue class of Attribute always has a value that is an XML Schema normalizedString.

Your current IProperty.getType() would, as it does today, return the type of the higgins:attribute sub-Property. This would typically be user-defined (where user = context provider developer), e.g. a URI representing some schema's notion of, say, eyeColor.

-Paul

 


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Monday, September 25, 2006 1:51 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: Re: [higgins-dev] IProperty getType()

 

I'm working on rewording it now. Here's what I currently have: IProperty.getType(). It's a lot like what I had, but plays with words (swapped should for may, added "or range of types").  I'm still not happy with it -- I don't think the use of the word "may" carries the meaning that it's not always possible.

Regarding the possible solution:  What would IPropertyValue.getType() return?  A more specific URI?

Jim


>>> "Paul Trevithick" <
paul@xxxxxxxxxxxxxxxxx > 9/22/06 5:31 PM >>>

Jim,

I have been looking at your latest Javadoc http://forgeftp.novell.com/bandit/HigginsIDASJavadoc/ 

In your IProperty interface you have a getType() method. In your doc you say:

It is used to convey both the name of this property and the runtime class type of the value (returned by getValue()).

I agree with this for OWL DatatypeProperties, but for OWL ObjectProperties this isnt strictly true. Although it is true that sometimes an OWL ObjectProperty is defined such that its range is only one class, it is also true that sometimes an ObjectProperty whose range is defined as being a set of possible classes. Even if only one class i s mentioned, the actual instance might be a subclass of this class (and there might even be several kinds of subclasses). My point is that a Propertys URI doesnt always tell you the type of what, in graph representation, it is pointing at.

You said in your Javadoc:

A consumer should also be able to determine from this URI, the Type of object(s) returned from getValue() and getValues().

And more to the point that:

These determinations may be made either by examining parts of the URI itself, or dereferencing it (or parts) to other sources of information.

But it seems to me that you really have to use reflection on the Java object returned from getValue to know exactly the type (class) of what youve got. You cant determine this a priori. (Note: Ive been careful to talk here o nly about ObjectProperties, OWL DatatypeProperties are not a problem on this point).

A possible solution: In addition making some edits to the above javadoc text.Since getType() returns an IPropertyValue, could we add a getType() to IPropertyValue? [In higgins.owl all ranges of the attribute property are subclasses of the Attribute class, so this new getType() would in effect tell you which subclass of Attribute youve got].

-Paul


Back to the top