So, based on my perhaps flawed understanding of what types get reported to the caller, the IdAS javadoc states that simple value types are always one of the XML schema built-in simple datatypes (excluding the ur-type anySimpleType, but including its subtypes listed in http://www.w3.org/TR/xmlschema-2. You can see a table of these in Section 3.
If I'm mistaken and IdAS simple value types are supposed to be something else, we need to address that.
I think the second part of the reply was to suggest that one can get a simple value's IAttributeSimpleValueModel, then call getType() on that and find out what it's super-type is. In fact, getType() will simply return it's own type. We would need to add a getSuperType() or getSuperTypes() if we wanted to support subtyping.
>>> "Tom Doman" <tdoman@xxxxxxxxxx> 01/11/08 5:50 PM >>>
#1 is just a special case of #2. In my generated LDAP ontology, I derived attribute types from Higgins types which were eventually expressed as xsd:<whatever>. So, yes, we need to discuss subtyping, maybe we can get the ball rolling on the next call and finish up at the F2F if needed.
On #3, yeah, could be. Though, I think the caller of the getType() API will be happy just to be able to figure out what the returned type means. So maybe we don't need to anything here. For example, in LDAP, if I said an attribute was a "syntax_DirectoryString", it'd be the same as if I said it was a "urn:oid:126.96.36.199.4.1.14188.8.131.52.15". By further referring to the model, the caller would discover the equivalence and react the same as if we'd returned "syntax_DirectoryString".
If the model API allows us to get an instance of the model based on a type we've gotten from any getType(), maybe the model ALREADY supports all 3 of these. Not happy with the type you got from getType()? Get it's model and see if you like that! Anyway, it'd be good to discuss this on a call I think.
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 01/11/08 2:55 PM >>>
On #1, I disagree. That is, if IAttributeValueModel.isSimple() == true, then it does imply that the value type is some basic XML Schema type. Maybe I'm not understanding what's being said.
On #2, the Higgins Data Model is not clear (IMO). I don't think we've ever actually made the statement that there can be:
- subject types that are sub types of other subject types,
- attribute sub types of other attribute types, or
- value types that are sub- types of other value types (aside from what sub- typing already exists in XML schema. Even then, I don't think we've even gone as far as saying you can put an xsd:byte into a value which is said to be of type xsd:integer (byte is a subtype of integer in XML Schema)).
If we want this behavior, we'll need to define what aspects of the supertypes are inherited (or not) and which aspects can be overridden on the subtypes.
On #3, would this be done by allowing IModel.getType to return multiple URIs?
I don't know what IAttributeModel.isDirect() is for. I specifically asked Valery in http://dev.eclipse.org/mhonarc/lists/higgins- dev/msg03624.html but got no response. I propose we remove it.
If no one objects to me removing IAttrbuteValueModel.get*Cardinality() I'll do it. We might as well do it before the end of 1.0
>>> "Tom Doman" <tdoman@xxxxxxxxxx> 12/19/07 5:47 PM >>>
My goal in this iteration is to make generation of an OWL ontology possible through the IModel interface and thus, able to be written once for every Context Provider. That is, getSchema() could be written once for all. We may not be able or wish to support everything that OWL supports (just as we may not wish to support everything an LDAP schema might), however, we need to support basic data model constructs that the IModel interface currently does not. Many of the issues I raise below are a result of this goal. That is, I cannot express things in the current IModel that need to be expressed in an OWL ontology (or, as I said, most data models).
1. IsSimple() - Just because a given IAttributeValueModel is simple, does not imply that it's type is a basic xsd type. If it isn't already a basic xsd type, I believe it should only be required to "eventually" be a subProperty something that is a basic xsd type. The model API should provide for this possibility.
2. Hierarchies - Any given DS or Attribute Model may be a sub- class (or sub- property) of another model element.
3. Equivalencies - Any given DS or Attribute Model may be equivalent to another model element.
Other ancillary items:
1. isDirect() on IAttributeModel - What does this mean?
2. Are we ready to remove deprecated APIs on IAttributeValueModel now?
FWIW, a lot of this is inspired by my current getSchema() implementation which yields an OWL ontology which I've attached here for your reference.
higgins-dev mailing list