RE: LRDD Update (Resource Descriptor Discovery) and Proposed Changes

Xiashou, 

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@musc.edu] 
> Sent: 01 July 2009 13:52

<snip/>

> >> Then, this comes back to the definition of Information Resource, with a 
> >> URN, wouldn't IR be the set of all URL's referent?
> >>     
> >
> > By Fieldings writings a resource is modelled as a function from time to 
> > [(sets of equivalent awww:representations) OR (URI)].
> >   
> By no means to disrespect Fieldings, do we have to take someone's past 
> writing as a bible that we should never change?  If that, how can we 
> ever advance? 

You propose IR as ".. The set of all URL's referents". This makes no sense to me. In your view are those referent things resources or representations - it is not clear from what you write.

I invoke the model written about in REST and I think mostly accepted in the community... which I happen to like and find it makes sense to me. 

You take umbrage...

> >> If we have not taken 
> >> IR as *representation*, would this (the duality of URI as name and 
> >> locator) be the cause? 
> >>     
> >
> > But... we have *not* taken "IR as *representation*"....
> >
> > Just think of the web as a great big machine that answers 
> (amongst other things) "get" questions of the form "Please 
> 'get' me a (current) awww:representation *of* the 'thing' 
> named with this 'uri'"
> >
> > Responses that you might get back are one of following kind 
> (non-exhaustive):
> >
> > 	- an awww:representation of the 'thing'
> > 	- advice that 'thing' has another name (temporary or permanent)
> > 	- advice that more information *about* requested 
> >     'thing' *may* be available by asking the 'get question' of a 
> >     different 'thing'.
> > 	- advice that the requested 'thing' cannot be found/accessed...
> > 	- something more catastropic.
> >   
> That is my view, there is no "information resource".

Information resources are just those that can have webarch repesentations...

> > The point is that in web architecture the 'thing' referred 
> to by the 'uri' in the question, and the 'thing' that the 
> awww:representation (if any) is an awww:representation of are 
> supposed to be the *same* 'thing'.
> >   
> You have repeatedly assured me that no one has taken the view of 
> "Resource = Representation".

Yes... no-one I know of on the TAG... and I would continue to assure you of that...

>  What was this supposed *sameness*?  Define it objectively and clearly.

I think I'd refer you earlier responses from Pat or Jonathan about the meaning of sameness.

Best I can do is:

ForAll ?u:uri ?r:wa-representation SuchThat http-get(?u:uri) yields ?r:wa-representation,
Exists ?t:thing SuchThat
	?u:uri refers-to ?t:thing, 
	?r:wa-representation wa-representationOf ?t:thing .  	

Thing ?t is the same thing t in both clauses that m. That's it!

<snip/>

> Don't and don't ever take that view. Communication is simple. 

I don't!

>  You get a message and judge the truth of the claim.  There isn't 
> something magic about it.  This is how we humans know the universe.
> >> Now, let's go back to Pat's question, how a far away galaxy can be 
> >> connected to the Web?  Say Orion (let's make it a schemeless URN 
> >> again).  Then, you chose your information path by selecting your 
> >> transportation protocol.  When you choose "http", your information 
> >> resource would be http:Orion, which makes it a URL now.  
> Wouldn't you know what kind of access that you are getting into?
> >>     
> >
> > Well... you are having to invent here a new construct here 
> > that the web as it is does not support - the schemeless URN. 
> > As things stand right now there is no defined relationship 
> > between the things referenced by URI whose spelling differs 
> > only in the spelling of the scheme component.
> >   
> Of course, this is why I am proposing TAG to consider it. It helps solve 
> many problems.

Oh well... good luck... I suppose! I think you'd actually have more success in proposing a new scheme that fits with URI architecture as it is (and BTW URI schemes (as they are now) are orthogonal to fragID syntax/semantics). Not that would be without significant impedance.

> > Also, whilst I think this is the topic of TAG issue 
> schemeProtocol-49, what a URI refers to and how you access 
> that 'thing' (if you can) should be regarded as orthogonal. 
> The HTTP protocol itself can be used with URI from any scheme 
> - though there are obvious practicalities in setting up the 
> relevant gateways/proxies.
> >   
> Wouldn't my proposal help clarify that? A scheme denotes a path to 
> acquire "awww:representation" of a resource, denoted by the 
> schemeless-URI? If we give a default namespace to the scheme 
> part. 

*But* that is what the web already is - a machine that obtains wa-representions (where possible) of things (resources) designated by URIs.

> Then, people can follow their nose to understand what is the protocol, right?  
> If you take a static view point, then what a schemed URI denotes is the 
> "information resource". Besides, it also solve the problem between the 
> equivalence of http-URI and https-URI.

Hmmm... you may think you have solved it others with deployed systems that depend on the fact that such an equivalence is not stipulated probably see neither a problem or a solution!

> I am not saying this is currently supported.  That is why I ask TAG to 
> consider. We do use URI in two senses, one as URN and the other URL. Do 
> you agree? 

As a name and as a locator... Yes I see those uses, but the intention of webarchitecture AIUI is that in those case where both usages are possible they are (should be) aligned - what is named is that which is located (ie. that which an obtained representation is a representation *of*).

> >> If we have one URN, I believe all these problems will be gone.  Sure, we 
> >> can make URI to keep its duality.  But in the latter case, we must be 
> >> aware which sense we are using when we make a statement.  We should not 
> >> try to cure one linguistic confusion with another because that only 
> >> gives rise to new problem while still not settling the old one.
> >>     
> >
> > IIUC, you have:
> >
> > 	//en.wikipedia.org/wiki/Magna_Carta (or possibly 
> Mogna_Carta) is a 'URN' 
> > 		which names 
> > 			the Magna Carta (a conceptual work with 
> a small number of original transcriptions on vellum)
> >
> > 	http:////en.wikipedia.org/wiki/Magna_Carta (or possibly 
> http:Mogna_Carta) is a 'URL'
> > 		which names
> > 			a wikipedia page *about* the Magna Carta.
> >
> > In this scheme, what 'URN' do I use for the wikipedia page 
> so that I can write a page *about* it (and so on)?
> >   
> You want to propose an http://ftp://http://... .

No!!! I am asking you what you would propose. I'd leave things as they are!

> Sure.  I don't think 
> my proposal is theoretically against that. ou have to define how the 
> inner scheme is grounded on.   In other words, you have to construct a 
> meta-Web to do that.  But do you think that it is practically useful?  I 
> think Godel has told us there is no system that can be self-complete. We 
> have to stop our recursion somewhere.  Otherwise, we will go nowhere.
> > I don't think that we need such rigidity. We just need to 
> > be careful about what it is that is being named, and some 
> > named things contain information about other named things.
> >   
> Sure.  I am all for that.  Then, think about IR/httpRange-14, is it 
> rigid or not?

It is very flexible - it does not lock in any rigid syntactic relationship between things whose names have similar but slightly different names. Descriptive information about a thing could be anywhere on the web.

>  
> >> I *sincerely* wish that when we define our engineering terms, we can 
> >> follow Wittgenstein's version of "meaning is use".  A *definition* must 
> >> be distinguished from a *description*.  The former is aimed at clear 
> >> usage while the latter comprehension.  If we define a vocabulary X, and 
> >> no one can tell X from not-X, X must be treated as its subsuming 
> >> concept.  This is my logical argument for the word "descriptor/metadata" 
> >> etc. because their definitions make them semantically equivalent to 
> >> "resource".  Then, it offers no more therapeutic (in Wittgenstein's 
> >> term) value than what we already have, except making it worse.
> >>     
> >
> > I think that you are overreading what people are saying. 
> > Most people AFAICT, are comfortable with the notions that 
> > resources can described other resources and will speak of the 
> > former as being metadata about the latter. One doesn't then 
> > have to get into meta-'x',  meta-meta-'x' .... One just has 
> > 'x' and some 'x's have things to say about other 'x's.
> >   
> Did I?  I am not against people using the word "meta-data".  I am 
> against people trying to propose a standard approach based on that 
> word.  I don't care what the word is.  What I care is how I can tell one 
> thing from the other.  I am engineers.  

Ok... so the engineering problem is:

	"Given a name 'u' for a thing 't' how do I find descriptions of 't' as opposed to awww:representations of 't'"

> All works is in essence a bunch 
> of "if elese".  If my "if" always return one result, what is the 
> "else"?  

skw parser failure!

> And someone told me that there is an "else".
> 
> (As a history, I remember when I first heard RDF back in 2000, it was 
> called a metadata framework.  I guess there is a reason for 
> that TAG no longer use that.)

I doubt it. There is also a 'D' in the middle of RDF. RDF lets you make statement about 'things', but one of the problems is completely the reverse - I want to find what is said (and by whom) about some 'thing'. The natural operation of the web enable you find what a 'thing' has to say of 'itself' in the form of awww:representations (if of course it is of a kind that can do that).

<snip/>

> > I think that with careful use the web as it is today works 
> just fine.
> >   
> Yes.  This is my point.  The web works just fine without the 
> concept of IR.  We need to be careful about our vocabulary, i.e., URI.  That is 
> all.  Then why compound us with "httpRange-14"?
> 
> Cheers
> 
> Xiaoshu

Stuart
--

Received on Wednesday, 1 July 2009 13:54:36 UTC