Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)

On 2002-06-13 2:13, "ext Garret Wilson" <garret@globalmentor.com> wrote:


> I'm coming to the realization (through your help, and through the help of
> others) that RDF Schema is merely descriptive, not prescriptive. It is
> assertive rather than constraining. It's an "everyone is right" sort of
> language: if my RDF Schema says that dc:creator has a range of foo:Person
> and then someone creates an RDF instance that has an rdf:Bag as the object
> of dc:creator, then both are correct: the rdf:Bag must also be a foo:Person.
> (I'm still not convinced of how useful this is, but for now I'm just trying
> to accept that...)

(some comments from the "other" Patrick...  ;-)

I think this is taking things too far in the other direction.

RDF Schema provides the mechanisms for folks to say what they mean or
expect.

An rdf:type statement expresses what something is. An rdfs:range or
rdfs:domain statement expresses what something is expected to (should)
be. These are just facts that may or may not agree.

Whether or not a given application requires that everyone agree is
a secondary issue (a very useful one, certainly, but secondary), and
the mechanisms for determining such agreement are (presently) outside
the scope of RDF and RDFS proper.

Thus, if you define the range of some property to be foo:Person, and
someone else who uses that property specifies a value to be rdf:Bag
then that simply means that you disagree about what type a value
can/should be. Now, if you "own" the property, then you might fairly
say that the other person is "wrong". But if neither of you own
the property (e.g. dc:creator) and the owner of the property does
not specify any such expectation, then neither of you are right or
wrong, you simply disagree.

If the type of the value is left implicit, then that *might* mean
that you are free to presume that it conforms to the expectations
defined by the range, but then again, it might not. The other user
may actually have meant something else but forgotten to be explicit
about it (perhaps in their context, they have another range defined
that does not come along with the value).

So RDF Schema is not saying that everything must agree, nor is it
saying that everything is equally correct. Rather, it is simply
providing a means for folks to express expectations and facts, and
applications are then free to reconcile or reject those as needed,
to whatever degree they agree or disagree (and sometimes, it's
not even possible to be sure about whether two statements disagree,
you may simply not have enough information to know for sure).

Some time ago, I got all caught up in whether RDF Schema was
prescriptive or descriptive, and have come to hold the view that
it is neither -- insofar as the usual interpretation of those
terms is concerned (prescriptive = must be, descriptive = is).
Rather, I just like to say it is 'expressive', and nothing more.

I outlined what I thought would be a very useful, basic form
of validation based on RDF Schema expressed facts and expectations,
which would serve as a test of completeness and agreement for
a given body of statements. It does embody the prescriptive
view, in that all values are required to be explicitly typed.
It could be weakened a bit to embody a "hybrid" prescriptive
and descriptive view in that values not types are presumed to
be of (one of) the defined range or domain types.

C.f. http://lists.w3.org/Archives/Public/www-rdf-interest/2002Jun/0141.html

It's interesting, though, to note that alot of inference rules
seem to reflect a descriptive view for range and domain, having
definitions akin to:

{
   ?p rdfs:range ?c1 .
   ?p rdfs:domain ?c2 .
   ?s ?p ?o .
}
log:implies
{
   ?s rdf:type ?c2 .
   ?o rdf:type ?c1 .
}

Now this does not necessarily (IMO) mean the range and domain statements
are descriptive, per se, but simply is reflecting the presumptions
about the types of the subject and object based on the expressed
expectations of the domain and range constraints. And this is a
necessary step towards identifying contradictions, which is the
logical basis for validation of such expectations. Thus, if it
turns out that 

   ?o rdf:type ?c3 .

is explicitly defined, and something cannot be both an instance
of ?c1 and ?c3, then we have a contradiction and we know there is
disagreement about the correctness of ?o as a value of ?p. Note,
though, that it's important not to conclude that ?o actually *is*
an instance of ?c1. Also, in order to determine such a contradiction
between ?c1 and ?c3, you need more than RDF or RDFS provides; which
is where DAML and OWL come into the picture, by allowing you to say
that something can't be both a member of ?c1 and ?c3.

So RDF and RDFS provide the foundation for expressing facts and
expectations, but we need additional machinery to ultimately
test the agreement between a set of RDF statements.

And whether or not range and domain constraints (expectations) are
tested automatically or left for human inspection, they are equally
clear and explicit and thus a very useful tool for communicating
what values *should* be used for properties and which kinds of
resources particular properties *should* be used with.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 13 June 2002 03:34:25 UTC