Also on the subject of data types:
I assume we'll want to define a set of classes or something that can be used by a context provider to expose all the primitive and derived built-in datatypes found at http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
We already have classes for instances of these datatypes in the idas.spi project (we obviously don't have classes for their "models" yet). If/when we add these, do we want to extend some other interface similar to org.eclipse.higgins.idas.api.model.IAttributeSimpleValueModel? That interface give one the ability to pass some string into the model for a datatype (where the string is a lexical representation of a value) and get back an instance for that datatype. For example, one could get the model for xsd:string, and on that IEntity call myStringModel.getInstanceFromLexical("blah blah blah"); and have that return a BasicValueString.
Further, should we start making comparison routines or objects available on a per-datatype basis? Maybe this question can be asked later :)
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 09/02/08 3:05 PM >>>
I previously made a misstatement. validAttributes will always point at an "attribute type" definition. It's the attribute type definition which might point at either a simple type (TBD in the model) or point at an entity (complex type) in the attribute type definitions data range.
Anyway, I'm looking at what needs to be in the definition of a data type. I think we need everything available at http://www.w3.org/TR/xmlschema-2
In other words, we (possibly) need:
* a way to do derivation. in xmlschema, this is done by restriction, list, or union
* a way to define the value space including constraining facets
* a way to define the lexical space?
I don't really want to carve out space to define things regarding data types that no one will ever use. Let's look at the xml schema "language" data type for example:
<xs:simpleType name="language" id="language">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/xmlschema-2/#language"/>
</xs:annotation>
<xs:restriction base="xs:token">
<xs:pattern value="[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
id="language.pattern">
<xs:annotation>
<xs:documentation source="http://www.ietf.org/rfc/rfc3066.txt">
pattern specifies the content of section 2.12 of XML 1.0e2
and RFC 3066 (Revised version of RFC 1766).
</xs:documentation>
</xs:annotation>
</xs:pattern>
</xs:restriction>
</xs:simpleType>
Do we need the ability to annotate? Do we want to allow people to specifiy derivation in terms of a restriction as shown here and allow for provide regex patterns? What I'm wondering is whether this data will actually be read and used by IdAS consumers.
Jim >>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 1:06 PM >>>
My opinion is that it's fine.. I don't know how close we want to be to RDF/OWL, but if we want to be as close as possible, then we could do the following:
1. If we want to define what attributes an instance of a model can have, we may want to only have one property for that. I.e. only higgins:validAttributes, not higgins:attributeModelAttributes, higgins:entityAttributes, etc. This higgins:validAttributes is then basically the owl:inverseOf of rdfs:domain. I spent some time in #swig on irc.freenode.net <http://irc.freenode.net> today.. It's funny, in RDF/OWL they have no way of saying that Class X can have Property Y. You can only say it the other way round, i.e. Property Y rdfs:domain Class X. What we want (higgins:validAttributes) is the exact opposite concept.
## That is correct. Properties (attributes) are first class objects in RDF. Takes some getting used to if you’re used to object oriented programming.
2. Allow minCardinality and maxCardinality only at the Entity Model, not at the Attribute Model.
## Yes. As a byproduct of the fact that properties are first class objects, you can use the same property with N>1 classes. Which means that the cardinality restrictions must be on the class not the attribute.
3. The idea that higgins:validAttributes has complex values is a slight contraction of what RDF/OWL people would do with rdfs:subClassOf and owl:Restriction, but it seems to be equally powerful, so that looks great to me.
Anyway, just ideas..
Markus
On Tue, Sep 2, 2008 at 7:31 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
|