|
Interesting. So, it looks like something that could also be accomplished via multiple inheritance, but instead of introducing some of the problems of multiple inheritance, a Data Range" allows one to share just the validAttributes common to a set of different entity types.
Where did the "[0..3] get introduced? I see it where pcrd:email shows that on Person, but not on the data range.
Do we want to do this in Higgins/IdAS?
Jim
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 3:26 PM >>>
Hi Jim,
Speaking of models for datatypes...The OWL1.1 spec lifts all of the datatype definition stuff from xmlschema just as you are proposing. They have introduced a way to define what are called “Data Ranges”. Here’s an example of an “Entity Class” called “Person” in a context that uses the “person” namespace. This “Person” class makes use of Attribute Types links such as “pcrd:email” and “pcrd:phone” (where pcrd is the namespace for information card claim types). The reason I included this diagram is that the person ontology includes a datatype (DataRange) called EmailDataRange that is the “range” of the “person:work-email, pcrd:email.
Here is the OWL code to define EmailDataRange (RDF/XML):
<rdf:Description rdf:about="http://www.eclipse.org/higgins/ontologies/2008/6/examples/person.owl#EmailDataRange"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DataRange"/> <owl11:pattern>^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$</owl11:pattern> <owl11:onDataRange rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </rdf:Description>
Or N3 if you prefer:
person:EmailDataRange a owl:DataRange ; owl11:onDataRange xsd:string ; owl11:pattern "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}$" .
“owl11” is the namespace for OWL 1.1.
-Paul
On 9/2/08 5:05 PM, "Jim Sermersheim" <jimse@xxxxxxxxxx> wrote:
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 $0.02 inline ##.
On 9/2/08 2:40 PM, "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> wrote:
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:
|
