- From: McBride, Brian <bwm@hplb.hpl.hp.com>
- Date: Wed, 7 Jun 2000 11:29:10 +0100
- To: "'Ralph R. Swick'" <swick@w3.org>
- Cc: www-rdf-interest@w3.org, www-rdf-comments@w3.org, w3c-rdf-schema-wg@w3.org
> > >As we've been studying the uses of the RDF Schema vocabulary for >reasoning about models described in RDF, we've come to realize >that the defined 'domain' property is not particularly useful >for inferencing: > >http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s3.1.4 > > "If there is more than one domain property, the constrained > property can be used with instances of <em>any</em> of the classes" > >Since we are working in a non-closed world, we can never know whether >we have all the possible domain statements that might apply to a >property so we can never compute a definitive list of the possible >classes of the subject of a statement with this property as predicate. > Is rdfs:range any better off? Given a non-closed world, is it possible to know all the subclasses of a given class? And if that is not known, how can one determine when either a domain or a range constraint has been violated? If the schema spec were to constrain the rdfs:subClassOf property such that its domain was restricted to classes in the same namespace as the schema, then this wouldn't be a problem. No such constraint is mentioned in 2.3.2 of the schema spec. Is it mentioned anywhere else? Or is there some other way an rdf processor can know it has all the relevant subClassOf properties? In implementing my schema validator, I have tended to assume that an application would have to define an applicable set of schemas and 'reason' within those. Was that an incorrect assumption? I was tempted at one time to comment that the schema spec does not define an algorithm for schema validation. I didn't, because I felt that the spec was sufficiently clear, and such a change might slow the process. Now I think that there may be enough scope for misunderstanding that writing a separate 'implementors note' or whatever might be a good thing. Brian McBride HPLabs
Received on Wednesday, 7 June 2000 06:29:20 UTC