From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 02/20/01
Mike,
This is useful feedback on the practical use of concrete datatypes. I
have suggested a few possible solutions to your problems below. This
is not intended to suggest that your concerns are not legitimate or
that the current proposal is perfect.
On February 20, Mike Dean writes:
> In developing a new ontology for high-level project plans
> (using OilEd) today, I ran into 2 issues related to our
> current discussions regarding abstract classes and concrete
> datatypes.
>
> 1) I wanted to add a "collaborator" property to the class
> Task, which could refer to either a specific Project
> instance known to me or a string representing a more fuzzy
> entity such as "various experts, as needed". The
> alternatives (2 separate properties, defining FuzzyProject
> as a subclass of Project, etc.) to use of an
> abstract/concrete union type seemed less desirable.
You can assert that a task has a collaborator without specifying the
actual collaborator. This kind of incomplete knowledge is perfectly
normal in KR. You could do it by introducing a class
"TaskWithCollaborator" (or whatever) or by simply in-lining the
specification with the task instance in question, e.g.:
<Task rdf:ID="t1">
<rdf:type>
<daml:Restriction>
<daml:onProperty rdf:resource="#collaborator"/>
<daml:hasClass rdf:resource="#Expert"/>
</daml:Restriction>
</rdf:type>
</Task>
This gets around the problem and is more precise than simply using a
string. If you don't know the type of collaborator you could just use
Thing. You could also extend the description by adding cardinality
constraints etc. Doing it this way has the advantage that you can
identify t1 as a kind of task that has an expert collaborator, which
you wouldn't be able to do if the information was just buried in a
string.
> 2) I wanted to associate dates with Deliverable, but need to
> label different dates (e.g. alpha, beta, and final for
> Software). I defined a Date class with properties
> descriptor (currently a string) and date (an XML Schema
> date). It was most natural to also use the date property to
> associate the Date with the Deliverable. This won't work if
> the date property has to be either concrete or abstract.
True, but you really shouldn't be using the same property in the two
cases as they refer to quite different relationships. The Date class
is a bit of a misnomer - it should perhaps be called something like
"Version" or "Release", and the property similarly
renamed. Alternatively, you could just define separate properties
(alphaReleaseDate, betaReleaseDate, etc.).
> Slightly new topic: I got to look at the latest
> DAML+OIL+CONCRETE proposal [1] as somewhat of an outsider,
> since I wasn't able to participate in the Language breakout
> at the PI Meeting. I gather that consensus was reached (a
> good thing). However, I fear that we've gone full circle,
> and created a baroque compromise. I've got 2 major
> concerns:
>
> 1) ConcreteProperty definitions containing range
> restrictions seem like a step backward. In the early stages
> of DAML+OIL, folks convinced me and others that the RDF
> property range constraint was too "constraining" and that we
> should adopt the OIL notion of declaring properties just as
> names and employing restrictions on class/property pairs (to
> allow reuse of properties such as color in different
> classes, etc.).
We do have "local" restrictions for concrete properties. To quote from
the example file:
<daml:Class rdf:ID="BigFoot">
<daml:intersectionOf rdf:parseType="daml:collection">
<daml:Class rdf:about="#Person"/>
<daml:Restriction>
<daml:onProperty rdf:resource="#shoesize"/>
<daml:hasClass rdf:resource="http://www.cs.man.ac.uk/~horrocks/daml+oil/datatypes/daml+oil+concrete-ex-datatypes#over12"/>
</daml:Restriction>
</daml:intersectionOf>
</daml:Class>
> It seems to me that there are several
> levels at which we might be able to enforce the
> concrete/abstract dichotomy:
>
> AbstractProperty vs. ConcreteProperty
>
> AbstractRestriction vs. ConcreteRestriction
>
> hasClass vs. hasDataType
>
> I'd prefer the lowest possible of these levels, and that we
> be able to support at least unconstrained properties that
> can take on any value. We touched on this a bit during our
> last telecon.
There is a technical reason (to do with negation) why we need
separation at the property level.
> (I also now have similar reservations about UniqueProperty,
> UnambiguousProperty, and probably TransitiveProperty -- that
> these attributes should instead be specified for
> class/property pairs -- e.g. a socialSecurityNumber
> unambiguously identifies a Person but not a BankAccount).
You can do the first two things using cardinality constraints and
inverse properties (Unique and Unambiguous can be seen as global
versions of cardinality constraints). TransitiveProperty is a bit more
tricky. We could use a transitive closure "operator", but this has
serious consequences for the tractability of implemented
systems. However, you can usually achieve what you want by using
a non-transitive subProperty.
> 2) I think any language that requires coding like
>
> <shoesize>
> <xsd:decimal rdf:value="14"/>
> </shoesize>
>
> rather than
>
> <shoesize>14</shoesize>
>
> will be a very hard sell. Will all the instances have to
> change if the ontology evolves to use a float instead? XML
> documents using XML Schema don't require this. What's the
> internal representation for tools like RDF API that produce
> triples? What if the ontology says xsd:int and the instance
> says xsd:short? What happens if I use mysd:shoeSize rather
> than xsd:decimal?
>
> I think we're going to a whole lot of trouble to accommodate
> a specific class of tools that want to convert data types
> during lexical analysis (vs. a later phase) without having
> previously read in the ontology. I'd prefer to stay closer
> to RDF and adopt a simpler set of constructs that optionally
> constrain Literal property values to be strings in the
> lexical space of a specified XML Schema datatype.
You don't have to put a range restriction on the property, and if you
don't you can use any concrete type you like with instances. Moreover,
everything should be OK if the instance has a more "specific" type
than any restriction on the property (e.g., shoeSize will be OK if it
is a specialisation of decimal). We also discussed the fact that this
can be seen as another tool issue - sensible editing tools should
allow you to enter "14" as the shoesize and simply add the appropriate
type according to its knowledge of the range restriction on the
property.
>
>
> Am I now the odd man out on the Committee? I do appreciate
> everyone's hard work in this area, and apologize if I'm
> ruffling feathers.
I don't know about anyone else, but my feathers are OK.
Talk to you later.
Ian
>
> Mike
>
> [1] http://www.cs.man.ac.uk/~horrocks/DAML+OIL/Datatypes/
This archive was generated by hypermail 2.1.4 : 04/02/02 EST