| [higgins-dev] IProperty getType() |
|
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 javadoc 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 when
applied to something modeled as an OWL ObjectProperty this isn’t strictly
true. It is true that sometimes an OWL ObjectProperty is defined such that its
range is only one class, however it is also true that sometimes an
ObjectProperty whose range is defined as being a set of possible classes. Even if only one class is
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 Property’s
URI doesn’t always tell you the type of what, in graph representation, it
is pointing at (i.e. its “value” so to speak). You said in the 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 you’ve got. You can’t determine this a priori.
(Note: I’ve been careful to talk here only 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 you’ve got]. -Paul |