- From: Dickinson, Ian J <Ian_J_Dickinson@hplb.hpl.hp.com>
- Date: Fri, 13 Jul 2001 18:17:15 +0100
- To: www-rdf-logic@w3.org
In the DAML 2001/3 spec, the way to create a transitive, unique or unambiguous DatatypeProperty is as follows: <daml:DatatypeProperty rdf:ID="p"> <rdf:type rdf:resource="http://www.daml.org/2001/03/daml+oil#UniqueProperty /> </daml:DatatypeProperty> (and equivalently for transitive and unambiguous properties). Thus p has two rdf:type's - daml:DatatypeProperty and daml:UniqueProperty. Now I know that where a resource has multiple constraints upon it, the general position is to treat them as a conjunction. Hence, p is a member of the class of Properties that are both datatypes and unique. This kind of thing is done elsewhere in DAML, but not usually by overloading rdf:type ... more commonly subPropertyOf is used. The reason I bring this up is in thinking about API's for DAML. Typically, resources have at most one rdf:type property, and indeed, DAML defaults the type to daml:Thing. So, ordinarily, we can talk about *the* type of an object, and an API could comfortable support a get/set semantics for *the* type. If, OTOH, rdf:type should always be thought of as multi-valued, then the semantics for the API will have to be modelled on adding/removing/listing the types plural, with an attendant increase in complexity. So, my question is whether unique (transitive, unambiguous) datatypes, with multiple rdf:type's, are the exception or the rule. If they are the exception, is it more reasonable to (a) trap them as special cases in an API, or (b) change the spec so that there is a more elegant way of expressing the additional semantic qualifiers on datatype properties? Regards, Ian ____________________________________________________________________ Ian Dickinson HP Labs, Bristol, UK mailto:Ian_Dickinson@hp.com
Received on Friday, 13 July 2001 13:17:19 UTC