Re: Example for consideration: Resource versus Representation

Pat, welcome back to the fray.

The chair would really like to find a way to avoid on this list the  
style of bickering prevalent on semantic-web and www-tag lists. Let  
me attempt to reiterate and expand upon the contrasting method of  
bickering that is proposed for the AWWSW activity.

We are attempting to come up with some things that one might say *in  
RDF* as a result of an HTTP interaction. Ultimately we would like to  
express, formally, things that we might have learned about the  
referent of the URI of the requested... thing, but along the way we  
will need to be able to use, as evidence in inference chains, things  
that we know about some of the ephemeral phenomena that arise during  
the interaction, and we may (*may* - I'm not sure) need to reason  
about entities that lurk behind the scenes, such as software,  
authors, and so on.

Here's how RDF works, in my view. It is a language of discourse, much  
as natural language is; a formal notation for expressing *any* kind  
of declarative information - information about biology and physics,  
about authorship and publication, about data structures and screw  
pitch. You might say it is a knowledge representation language,  
although I find "knowledge" to be pretentious, and "representation" a  
bit questionable. But let's not worry about this. The important thing  
is that there is no a priori limit to what may be the intended  
(denotation of the) subject, object, or verb of an RDF statement.

In order for this to work, it must be permissible to assign a URI to  
anything at all. (We all agree on this, right?) Assigning a URI  
incurs a sort of moral obligation to resolve it somehow, but lack of  
resolution doesn't make the assignment invalid. (We all agree on  
this, right?)

In order to write meaningful RDF, you have to have subjects and  
objects, and verbs (= predicates = properties). A fundamental  
assumption - speak up now if you don't believe this - is that to be  
clear and useful a property [a terrible word but we're stuck with it]  
must have a specified domain and range -- classes to which the  
subject and object must belong in order for statements using the  
property to be acceptable in discourse.

Our task is to define these properties and classes so that we can  
make formal statements, ones that might be inferable from HTTP  
interactions, that are helpful for all the things you want to do in  
the semantic web: nonsense detection, query, inference, action (such  
as sending or paying a bill), and so on. Beyond specifying domain and  
range, of particular interest are subsumption (subclassing),  
disjointness, and property restrictions such as "inverse functional".

Specify which definition you're using in whatever you are saying, if  
you have to use words like "resource" at all. Do you think you're  
expressing what's in a spec, or are you making it up as you go along?  
Use a qname (e.g. rfc2616:Entity) if possible. Ask for clarification  
of someone else's definition if it's unclear (I think this is what  
Alan is trying to do in trying to draw out Noah). Talk about how you  
would like to interpret some spec if you have to, although if a spec  
is found to be vague or inadequate it is probably better to just  
articulate a new definition. But remember that the task at hand is to  
specify properties, the classes that are to be their domains and  
ranges, and relationships among the classes and properties that  
permit useful inference.

Defining the "right" class (or property) is usually an iterative  
process.  You may start out by knowing that some particular thing is  
in a class that you need to articulate, and then attempt  
generalizations in a variety of directions. Or you may know that you  
have to write a property, and while you don't know what its domain is  
yet, you give the domain class a name as a temporary placeholder.  
Getting precise limits for classes, so that all the boundary cases  
are neatly handled, can be very difficult. We have to tolerate some  
amount of imprecision as we figure out what classes we need.  
Eventually, though, class definitions have to converge to relatively  
rigorous forms.

I have started to write down some classes and properties here: http:// 
esw.w3.org/topic/AwwswAnalysis. David Booth has done this in his  
email as well.  If I/we have mischaracterized some of these things  
(e.g. if you disagree with me that rfc2616:Representation is a class  
- fine, we don't need it since we have the more rigorously defined  
rfc2616:Entity), then the best response is to propose a different  
class that can be the domain or range of the properties we care about  
(e.g. of rfc2616:representation), or a different property that better  
captures the heretofore unarticulated web architecture that you want  
to promote. I think this is the best way to make progress.

Also remember that we're not trying to come up with the right answer;  
I think the best result would be a set of architectural alternatives  
specified using a clear vocabulary.

Best
Jonathan

Received on Thursday, 24 January 2008 17:02:22 UTC