|
What I mean to ask when I asked: Do we want to do this in Higgins/IdAS? is "Do we want to add the ability to build up these "data ranges" which can be re-used by different definitions in Higgins/IdAS?"
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 09/02/08 4:56 PM >>>
Jim, the N3 examples got scrambled by email. In case it happens again here they are repeated at the top:
pcrd:email a owl:DatatypeProperty ;
rdfs:comment "Generic email address as defined by Microsoft ISIP" ;
rdfs:domain person:Person ;
rdfs:range person:EmailDataRange ;
higgins:category person:email-attributes ;
higgins:displayOrder "1" ;
owl:equivalentProperty <http://xmlns.com/foaf/0.1/mbox> ;
skos:definition "Email address"@en ;
skos:example "ptrevithick@xxxxxxxxx" ;
skos:prefLabel "Email"@en .
person:Person a owl:Class ;
rdfs:subClassOf higgins:Person ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:maxCardinality "3"^^xsd:nonNegativeInteger ;
owl:onProperty pcrd:email ] .
On 9/2/08 6:20 PM, "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> wrote:
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.
## A Data Range is something that you define and use in place of one of the std xml schema built-in types like integer or string. Any attribute type can simply define its “range” as being the id of the Data Range.
## Here’s the (N3) code for the pcrd:email Attribute Type in OWL 1.1. I’ve highlighted the relevant line
pcrd:email a owl:DatatypeProperty ;
rdfs:comment "Generic email address as defined by Microsoft ISIP" ;
rdfs:domain person:Person ;
rdfs:range person:EmailDataRange ;
higgins:category person:email-attributes ;
higgins:displayOrder "1" ;
owl:equivalentProperty <http://xmlns.com/foaf/0.1/mbox> ;
skos:definition "Email address"@en ;
skos:example "ptrevithick@xxxxxxxxx" ;
skos:prefLabel "Email"@en .
## Note: you can ignore all of the other lines than the red/highlighted one. I just included them to show what kinds of metadata (with the exception of owl:equivalentProperty —which is needed for the “community dictionary service” that some of us still dream of) are needed on Attribute Types for real-world apps that plan someday to support dynamic metadata-driven UIs.
Where did the "[0..3] get introduced? I see it where pcrd:email shows that on Person, but not on the data range.
## Here is the OWL for the Person “Entity Class”
person:Person a owl:Class ;
rdfs:subClassOf higgins:Person ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:maxCardinality "3"^^xsd:nonNegativeInteger ;
owl:onProperty pcrd:email ] .
Do we want to do this in Higgins/IdAS?
## I’m just showing that OWL provides a way to define entity classes and attribute definitions by recursively using entities and attributes. Our goal with IdAS is to put as little into the API as possible while supporting our use cases. Personally I think both min and max cardinality is worth including, yes.
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:
|
