Re: Uniform access to descriptions

At 9:08 PM -0600 4/12/08, Michaeljohn Clement wrote:
>Xiaoshu Wang wrote:
>>  Michaeljohn Clement wrote:
>>>  - Is this view an accurate view of the Web which exists?   A goal?  Or
>>>  simply an alternative, interesting idea?
>>>  (I would say only the latter.  And I thought I detected a bit of a
>>>  gleam in your eye, Pat, throughout.)
>>  Honestly, does it matter? (I.e., if it is accurate or not?)
>Yes.  The Web is based on shared standards and conventions, and if you
>base your conventions on a model different from the one the rest of the
>Web is using, things stop working together.

Of course. But we can invent new such standards and conventions, and 
Xiaoshu is intending, I believe, to suggest this: to suggest an 
extension to our way of thinking.

>>  Neither Pat
>>  nor I have re-invented and demanded any re-invention of anything new.
>Your redefinition of "resource" and "representation" to me is a new
>re-invention of the Web.

Its not a RE invention. Nothing about the current Web changes at all: 
it allows for a new way of using some existing Web technology, is 
all. This way is rational and seems to conform to the current 
architecture, provided we are willing to think a little outside of 
our current box. And this might come as news to non-semantic Web 
mavens, but wa are already outside that box. We've been outside it 
ever since the TAG insisted that URIs can identify non-information 

>  >> - Would the effective dropping of awww:resources out of the universe 
>>>  of (convenient) discourse a desirable or acceptable state of affairs?

Nobody is suggesting that. Well, Im certainly not. Tim just got this wrong.

>  >  
>>  What matters is the conceptual understanding.  But the tendency of our
>>  human history is simply reuse the word but readjust the understanding.
>Let me ask the question differently: Do you believe the ability to
>make statements about Web pages, simply identifying the page by its
>URI, is worthwhile?

Yes, that is worthwhile.

>Your way of looking at (or redefining) the Web would lose that

NO IT WOULD NOT. This is false. All it would do is move the 
responsibility of deciding what a URI denotes from a rather messy and 
widely ill-understood distinction based on http codes, to a matter of 
content negotiation. This would allow phenomena which violate 
http-range-14, but it would by no means insist on such violations in 
all cases. In fact, if we were to agree on some simple protocols for 
content negotiation which themselves referred to http codes, it could 
provide a uniform mechanism for implementing the http-range decision.

>ither the URI from which you get a 200 OK response
>identifies an information resource, in which case we can make
>statements about it, or it does not in which case we cannot any longer
>make statements about the page by using the URI.

Nonsense. There is also the possibility of using some other URI to 
refer to it, for example by asserting explicitly that URI-1 refers to 
the thing identified by URI-2, perhaps using RDF to do the asserting. 
Again, I'm not suggesting that this would be required, or even a very 
common, situation; but it would be possible.  Moreover, this approach 
would put 'information resources' on exactly the same footing as all 
other things in the matter of how to choose representations of them 
for various purposes, a uniformity which means little at present but 
is likely to increase in value in the future.

>  We can't even say
>what the URI identifies anymore without getting out-of-band data
>about it, which in will not often exist.

We can treat http-range-14 as a default when no such data is available.

>>>  - In this view, do you consider it desirable for a storyteller to be
>>>  able   to tell precisely 0 or 1 stories about R per media type?
>  >>  
>>  I have explained my design pattern for the web in my respond to Tim's
>>  argument.  If you are the resource owner, you understand your resource
>>  better than anyone else, and you know who your potential clients are.
>>  Don't you think it is reasonable to make it your decision rather than mime.
>I think it's better to choose a decision and then all our software can

But right now, for the case where a URI is understood to denote 
something other than an information resource, we have a completely 
blank slate. There is nothing which tells our software how to 
interoperate in this case. Our situation is not a kind of paradise of 
reference-determination from which Xiaoshu and I are threatening to 
have everyone banished. Right now for the semantic web, things are 
about as bad as they can get.

>>  But I can give you a use case of people that I am working with.  We have
>>  some data we would like to provide.  This is what I tell them.
>>  [...]
>>  I only recommend design pattern and tell them if they desire to get
>>  their data be more broadly found and useful.  The rest is up to them, do
>>  you think this make sense?
>As you describe it, that sounds almost fine.  But the thing your story
>doesn't seem to clearly mention is serving something completely different,
>like a style steet, or RDF metadata /about/ the HTML Web page (not about
>what the HTML page is about), from the same URI.

Hmm, perhaps this is where Xiaoshu and I part company. I agree its 
important to keep representation and meta-representation as clearly 
separate as possible.

>  If you are doing that
>then I must say that is not what conneg is for, and it matters because
>the expectations of many others will break.

It matters that we all agree on expectations, of course. But I really 
dislike the tone of pronouncements like "not what conneg is for". Who 
has the authority to say what conneg is for? All this means is "not 
what conneg has been used for until now". Conneg is just machinery, 
and we, as a society, can use for whatever we decide and find 
convenient. The Web and the Internet are replete with mechanisms 
which are being used for purposes not intended by their original 
designers, and which are alien to their original purpose. For a 
pertinent example, the http-range-14 decision uses http codes in this 
way. That isn't what http codes are for.



IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell

Received on Sunday, 13 April 2008 20:33:04 UTC