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

Garret--

I'm a bit pushed for time right now, but some immediate comments on your
"schema" issues:

Garret Wilson wrote:
> 
snip
> 
> How the schema processor *uses* the information, perhaps (that is, whether
> and how a processor "accepts" or "rejects" a document), but I would think
> that how the information is semantically *interpreted* would be unambiguous.
> If there is no formal semantics of which RDF instances comply with which RDF
> Schema instances, then however could one find RDF Schema useful other than
> as an informal documentation tool? Why not call it "RDF Annotation," or,
> "RDF Give You a Rough Idea of Schema But Use Your Own Intuition As Needed?"
> 
> (Please excuse the sarcasm as I slowly become more disillusioned... ;) )

I've no problem with sarcasm (he said sarcastically).  I think what an
RDF Schema says is reasonably unambiguous (at least so far), but the
problem is I don't think it says as much as you think it does (and a lot
is bound up in what "compliance" means).  In the specific case we're
talking about, all the schema says is that the range of dc:creator is a
resource of type Person, right?  It *doesn't* say that if I look at the
resource that is the value of a dc:creator property, I will necessarily
find, right there, a rdf:type property that points to type Person (it
would say something like that if this were an OO type system, but it
isn't).  One of the reasons why you might not want to interpret an RDF
Schema as requiring that this rdf:type property be there is that, in the
Web, we don't require all the assertions describing a resource to be in
one place.  So if I find where the resource is defined, and don't find
the rdf:type property I'm expecting, that doesn't mean it doesn't
exist;  it may be someplace else.  But how many other places do I look
before concluding there's a validity problem?  Certainly decisions can
be made about these things (in particular, for lots of applications it
would make sense to require that all the data be in the same document),
but that involves defining more of a processing model than we have so
far (and assumes we'd want such a thing, and that it wouldn't need to be
application-specific), as well as lots of other stuff.  You're
interpreting the RDF Schema as necessarily defining *redundant*
information that you can check for consistency against the instances
(e.g. that if dc:creator has a range of Person, the resource that's the
value of a dc:creator must have a rdf:type property with value Person),
but technically the Schema can be equally interpreted as being
additional descriptive information about instances (so if you find a
resource that's the value of a dc:creator, you can assume it's of type
Person because the schema says it must be).  

> 
> > Second, if you wanted to do strict validity checking and have this
> > example pass, you could always add an rdf:type property having a value
> > of type Person to the b-node, right?
> 
> Right, but oh, that would confuse an RDF Schema Processor to no end---if the
> b-node is explicitly declared to be of type Person, what about all the
> constraints on Person that would not be present in the b-node? If the RDF
> Schema Processor doesn't impute a type of Person on the b-node through
> rdf:value, thereby imputing to the b-node all the properties of the
> rdf:value as well, then this would just be a mess...
> 

Depends on the Schema processor, because once again, you're assuming a
particular interpretation of these additional schema declarations.  For
example, if we'd declared an Age property with a domain of Person, that
wouldn't necessarily mean that every Person resource has to have an Age
property value (it would in an OO type system, but not in RDF).  That
would actually be a separate constraint (not currently expressible, I
think, in RDF), saying that if there is a Person resource, there must be
a triple with that Person instance as subject, and Age as predicate (and
some value as object); (and enforcing that constraint would make some
assumptions about our being able to find that triple.  

--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Tuesday, 11 June 2002 14:32:07 UTC