- From: Dan Brickley <danbri@w3.org>
- Date: Thu, 4 May 2000 12:43:59 -0400 (EDT)
- To: R.van.Dort@Everest.nl
- cc: www-rdf-interest@w3.org, ricko@gate.sinica.edu.tw
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