Re: RDF and polymorphism

On Thu, 4 May 2000 R.van.Dort@Everest.nl wrote:

> In my knowledge RDF does not support polymorphism.
> Properties are identified by their name.
> When you are using domain and range for a property, this forces you to
> define separate propertynames for each domain and/or range.
> Isn't this a big handicap with respect to the expressiveness of RDF?

We do have the sub-property relationship that can be used to relate
hierarchies of properties, so using separate names for properties that are
similar but have different constraints isn't entirely chaotic.

You might for example specialise the dublin core's dc:creator property 
by declaring a sub-property such as foo:author, and set tighter range
constraints on this (eg. the class wordnet:Person). Others could then
specialise your property eg bar:techAuthor with a tighter range (eg. some
sub-class of wordnet:Person eg. wordnet:Engineer).
 
So if you come across information that doc1.html has a bar:techAuthor of
[some anonymous resource] whose mailbox is mailto:connolly@w3.org, you can
deduce: (a) that the anonymous resource is an Engineer, and hence a
Person. (b) that the dc:creator of doc1.html is also that same entity.

Someone else might have defined a different property specialising
dc:creator, independent of this activity; sub-property provides a simple
basis for hooking these indendent but related properties back together
again.


Slightly different angle:

I also believe there'll be a need for the description
of application/context specific contraints that are only applicable in
very particular processing scenarios, and which may not need defining in
a schema. Rick Jelliffe suggested something similar in the
XSLT/Schematron-RDF thread
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Apr/0027.html

Excerpt from Rick's msg:

> My personal feeling is that Xpath-based assertion languages are proving a
> really convenient tool for many problems, especially those which fall
> between the cracks of a structural schema language and a semantic schema
> language: for example, for "business logic" schemas or anything else   where
> there are co-occurrence constraints (perhaps only appropriate at certain
> phases in a workflow) between various elements and values.   

This 'certain phases in a workflow' thing seems key. RDF Schema is pretty
neutral to this: we do provide the extensibility flag for indicating
new constraint types, but don't enumerate any fancy constraint types
that are context-specific. So you might for example
imagine a specific scenario where an application wanted not only the
foo:author of some resource, but for that foo:author to have an email
address specified. I don't believe this calls for a specialised property
based on foo:author that has the constraint that it must point to a
resource whose email address we know. Rather it's a workflow / data
checking thing that we can build on top of RDF query tools. Since we don't
have a common RDF query expression language right now, doing the
equivalent of Rick's Schematron/XPath check in RDF isn't a totally solved
problem. But I think we're beginning to see what it would look like.

Rather than make the Schema language do all the work (or rather, the
owners of the various namespaces we're using do all the constraining
work), I expect application authors will want an RDF-query based mechanism (not
unlike Schematron) for expressing ad-hoc context specific constraints
over RDF models. The difference is that the constraints are properties
not of the vocabulary, but of the use to which the vocabulary is being
put. 

IMHO If the RDF Schema WG had attempted to address all possible constraint
forms, in the absense of an RDF query language, we'd have a huge
monolithic and hard-coded spec to implement. I believe
we're better off doing this in modest layers, and re-visiting the
fancy-constraints problem once we've got some more expressive mechanisms
for talking about RDF graphs.

Dan

--
mailto:danbri@w3.org

Received on Thursday, 4 May 2000 12:44:25 UTC