RE: [higgins-dev] IProperty getType()

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

Yeah, I think you're right, (c) is probably most useful to the IdAS consumer. That way they can avoid parsing the schema after reading the type.

Lucky for me, the basic implementations and the table in the Javadoc for ISimpleValue.getType() are set up in such a way that changing from  (b) to (c) is trivial.

Another option is to add multiple methods like:
getAttributeURI (returns a)
getAttributeValueURI (returns b)
getAttributeValueTypeURI (returns c)

Maybe we just leave it at getType() for now and re-examine later if consumers have a need.

Jim

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 09/26/06 9:05 PM >>>
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#normalizedStringSimpl
eValue 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()
<http://forgeftp.novell.com/bandit/HigginsIDASJavadoc/org/eclipse/higgins/id
as/IProperty.html#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