RE: is rdfs:domain useful as currently defined?

>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:
> "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

Received on Wednesday, 7 June 2000 06:29:20 UTC