W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2008

Re: Example for consideration: Resource versus Representation

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 24 Jan 2008 13:20:35 -0500
Message-Id: <5FE336F3-7D5D-4127-85E2-987A619E17CF@creativecommons.org>
To: public-awwsw@w3.org

I characterized the recent discussion trying to straighten out  
definitions of 'resource' and 'representation' as 'bickering'. I  
meant this playfully and generally, not as a chastisement, and my  
message was meant to steer and ground, not squelch. I was not aiming  
this at Pat - if anything I had in mind the exchange between Alan and  
Noah.

My lecture on RDF was meant to surface disconnects, since it seems  
that among us we may have inconsistent assumptions about the nature  
and use of RDF and URIs. Since there be many different ways in which  
unstated assumptions  result in disagreement, I've tried lay out my  
understanding in discrete steps so that you can pick the best point  
at which to disagree.

Best
Jonathan

On Jan 24, 2008, at 12:02 PM, Jonathan Rees wrote:

> 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 18:20:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 July 2008 07:55:27 GMT