Re: Are rdfs:range and rdfs:domain really constraints?

Jan Algermissen wrote:
> Hi,
> DCMI has today published a new draft on how to use DC with RDF[1].
> Quote:
> "6. Using domains and ranges
> RDF supports using "domain" and "range" constraints on RDF properties, 
> for limiting the kinds of resources that a property apply to, and the 
> kinds of resources that may occur as values, respectively. This is not 
> currently part of the DCMI Abstract Model. However, some properties may 
> still come with such constraints, expressed formally in RDF schemas or 
> informally in accompanying documentation. It is strongly recommended 
> that metadata implementors be careful to follow such contraints when 
> they exist, to ensure maximum interoperability. This is even more 
> important in RDF than in other expressions of Dublin Core, as RDF adds a 
> well-defined model for automatic processing of domain and range 
> contraints."
> I would think that the above paragraph reveals a deep misunderstanding 
> about the nature of rdfs:range and rdfs:domain (and the purely 
> descriptive nature of RDF in general), is that correct?


> My reading has allways been that RDF is purely descriptive and that 
> there is no possibility to express the kinds of contraints mentioned in 
> the quoted paragraph: that only instances of *certain* classes may 
> occurr as subjects or objects of statements with a certain property.
> So, if I say that foo:employer rdfs:range foo:company the I say that 
> every resource that happens to be the object of a foo:employer statement 
> is a foo:company but I do not say that only (see 'may' in quote) 
> foo:company instances may be objects fo such statements.

It's certainly true that the statements

foo:employer rdfs:range foo:company  .
foo:fred foo:employer foo:sam  .


foo:sam rdf:type foo:company  .

It's also true that the statements

foo:employer rdfs:range foo:company  .
foo:fred foo:employer foo:sam  .
foo:sam rdf:type foo:Person  .

still RDFS-entail

foo:sam rdf:type foo:company  .

and violate no "constraint" (at least not as far as RDFS is concerned). 
   That is, RDFS per se doesn't care that you've said that Sam is both a 
Person and a Company, since there's no way in RDFS to say that's invalid.

> Therefore, I don't understand what interoperability benefit rdfs:range 
> and rdfs:domain can bring...since they do not license any assumptions 
> about the data exchanged.

This depends on how range and domain are being used.  As you're 
suggesting, it's a mistake to assume that a purely RDFS interpretation 
of these declarations implies the constraints that someone may, perhaps, 
have in mind.  However, that doesn't mean that a group like the Dublin 
Core folks can't agree among themselves to interpret them as constraints 
(e.g., in generating metadata), provided that they understand that:

a.  this interpretation is over and above that defined by RDFS, and

b.  this may lead to difficulties in processing RDF data not generated 
in accordance with their enhanced interpretation.

Note that they are considering constraints "...expressed formally in RDF 
schemas *or informally in accompanying documentation*" [emphasis added]. 
   Certainly it makes sense from an interoperability perspective for 
people to pay attention to any constraints expressed informally in 
documentation when generating metadata.  For example, if the 
documentation says that the intended value of the foo:employer property 
is the URI of a company, you shouldn't willfully ignore that, even 
though RDFS itself won't complain about it.  It similarly makes sense to 
pay attention to domain and range declarations when generating metadata 
under the same assumptions, that is, that the range and domain 
declarations express the intentions of those defining the schema.

However, as you're suggesting, the text should be clear about what's 
going on here and, in particular, be clear to distinguish the "RDFS 
meaning" of range and domain declarations from any additional meaning 
that the users of the Dublin Core specs may want to associate with them.


> Can someone clarify if I am right or wrong or what?
> Jan
> [1]

Received on Wednesday, 31 May 2006 21:38:36 UTC