LRDD Update (Resource Descriptor Discovery) and Proposed Changes

[Eran Hammer-Lahav]

(LRDD and /host-meta were previously discussed on www-talk@.... Moving forward, this discussion is being relocated to the IETF Application area discussion list. This will be indicated in future drafts.)

- A quick (re)introduction

I am working on a proposal called LRDD [1] which attempts to define how a descriptor (metadata, information about, etc.) can be attached or associated with a resource. LRDD, which stands for Link-based Resource Description Discovery (and pronounced 'lard') uses the Link Relation framework proposed by the Link Header draft [2]. LRDD does not define the document format of the descriptor itself, just how to obtain it if the URI of the resource is known. Existing descriptor formats include XRDS, XRD, POWDER, Metalink, etc.

As previously proposed, LRDD includes three methods for linking a resource (identified by a URI) to another resource which describes it:

1. HTTP Link: header
2. <LINK> element where supported (HTML, XTHML, ATOM)
3. Link-Pattern: records [3] in the proposed /host-meta well-known-location document [4]

The first two methods simply link to the location of the descriptor document from the resource itself (<LINK> element) or via the transport protocol used to retrieve it (HTTP Link: header). The third option provides a simple mechanism to map between the resource URI to the descriptor URI using a basic URI template syntax (removing the need to GET a representation of the resource or even have one available).

The obvious issue with regard to the third option is where to store the template used for mapping between resource URIs and descriptor URIs. What was previously proposed was to create a new well-known-location resource called /host-meta which will have a similar semantic meaning as an HTTP header for the abstract 'host' entity (the combination of domain and port). A long discussion of terms (host, site, origin, domain, etc.) was held on the Apps list [5]. A discussion about placing the mapping template in a DNS record did not mature into a proposal but is still desired by many people.

For a complete discussion of other (non link-based) methods considered see LRDD Appendix B: Methods Suitability Analysis [6].

- Proposed changes

Focusing on the third method using /host-meta, two separate discussions took place. The first was about the security of using a /host-meta file which can be easily created on many social networking sites by creating an account called 'host-meta' or on URI shortners [7]. The second was about the need in some use cases (namely OpenID) to sign the /host-meta document with some certificate to establish trust (this is part of a much bigger discussion but for the purpose of this thread, we can just assume that the document needs to be signed somehow).

These two discussions (and the focus on current use cases that are waiting for this to be resolved to move forward), has led to the following proposed changes:

* Introduce a new I-D called 'Well-Known' which will establish the path prefix /.well-known/ as a home for all future well-known-location solutions. We were already committing a namespace sin by curving out /host-meta as (yet) another well-known-location document so this will simply replace that with a path prefix and a lightweight registry for documents under that path. The main reason for this is that people are still concerned that a list registry under /host-meta will not be enough to deter future protocols from creating more well-known-location documents.

* Move /host-meta into this new /.well-known/ directory (http://example.com/.well-known/host-meta) and replace its text-based document format with XRD [8]. Since host-meta will no longer be needed as a generic link registry with the introduction of a well-known directory and registry, the only use case left for it is to store the URI template defined by LRDD. XRD already has a <URITemplate> element under <Link>, and will support document signatures (which is an important requirement for some use cases). Since most use cases at the moment will need to speak XRD anyway, and XRD is truly a lightweight schema, it makes sense to use it for host-meta instead of inventing another format just for that. We might drop the name host-meta altogether and name this XRD document under /.well-known/ something else.

- Next steps

* Submit a proposal for /.well-known as an I-D
* Publish the first committee draft (OASIS XRI TC) of XRD
* Update LRDD to use /.well-known and XRD as the third method instead of /host-meta

Both XRD and LRDD depend on the Link I-D to be published as RFC.

Any comments, feedback, or concerns are requested.

EHL

[1] http://tools.ietf.org/html/draft-hammer-discovery
[2] http://tools.ietf.org/html/draft-nottingham-http-link-header
[3] http://tools.ietf.org/html/draft-hammer-discovery-03#section-6
[4] http://tools.ietf.org/html/draft-nottingham-site-meta
[5] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00227.html
[6] http://tools.ietf.org/html/draft-hammer-discovery-03#appendix-B
[7] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00556.html
[8] http://www.hueniverse.com/hueniverse/2009/03/xrd-document-structure.html

[Xiaoshu Wang]

Eran Hammer-Lahav wrote:

> (LRDD and /host-meta were previously discussed on www-talk@.... Moving forward, this discussion is being relocated to the IETF Application area discussion list. This will be indicated in future drafts.)
>
> - A quick (re)introduction
>
> I am working on a proposal called LRDD [1] which attempts to define how a descriptor (metadata, information about, etc.) can be attached or associated with a resource. LRDD, which stands for Link-based Resource Description Discovery (and pronounced 'lard') uses the Link Relation framework proposed by the Link Header draft [2]. LRDD does not define the document format of the descriptor itself, just how to obtain it if the URI of the resource is known. Existing descriptor formats include XRDS, XRD, POWDER, Metalink, etc.
>
> As previously proposed, LRDD includes three methods for linking a resource (identified by a URI) to another resource which describes it:
>
> 1. HTTP Link: header
> 2. <LINK> element where supported (HTML, XTHML, ATOM)
> 3. Link-Pattern: records [3] in the proposed /host-meta well-known-location document [4]
>  

In AWWW, there is the principle of orthogonal specification.  In
practice, there is this DRY principle.

Now, given one information, you are proposing three mechanisms to
specify it.  Isn't it obvious that something is *fundamentally* wrong
about the proposal?

Xiaoshu

[Eran Hammer-Lahav]

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: Thursday, June 25, 2009 4:17 PM

> Now, given one information, you are proposing three mechanisms to
> specify it.  Isn't it obvious that something is *fundamentally* wrong
> about the proposal?

No. That's like saying an HTML document should never repeat any of the links provided in the HTTP header, etc. The reality is that there isn't any single solution that satisfies all the use cases we have. After over a year of debating it, this combination of three methods is the best we have come up with, and it works fine. Is it a beautiful solution with clean architecture? No. But it is the only solution we can deploy today and expect people to use.

If you read the proposal, it clearly goes through the list of available methods and states why this approach was chosen.

EHL

[Xiaoshu Wang]

Eran Hammer-Lahav wrote:

>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> Sent: Thursday, June 25, 2009 4:17 PM
>>    
>
>  
>> Now, given one information, you are proposing three mechanisms to
>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>> about the proposal?
>>    
>
> No. That's like saying an HTML document should never repeat any of the links provided in the HTTP header, etc.

Of course, it shouldn't.  In fact, no HTTP header should use URI except
the Content-type, which unfortunately is not defined in this way.

> The reality is that there isn't any single solution that satisfies all the use cases we have. After over a year of debating it, this combination of three methods is the best we have come up with, and it works fine. Is it a beautiful solution with clean architecture? No. But it is the only solution we can deploy today and expect people to use.
>  
Define your "fineness"?  Making something works does not mean solving
the desired problem.  If you know the solution is not clean, you should
not that it should not be proposed at this level because it will have
long term effects.
> If you read the proposal, it clearly goes through the list of available methods and states why this approach was chosen.
>  
Nope.  Your evaluation on content negotiation is very vague and, in my
opinion, partial.

Xiaoshu
> EHL
>  

[Jonathan Rees-3]

[less cc:]

Tracker, I write this email primarily for you. This whole thread is
about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].

Xiaoshu, you're essentially pressing the TAG again to make a formal
statement on recommended use of conneg, as Michael Hausenblas did in
February [3]. I'm sorry that this has fallen to the periphery of the
TAG business heap. The best I can do now is to point you to the advice
[4] that we gave to the Cool URIs for the Semweb editors, which agrees
with Eran's reading.

Jonathan

[1] http://www.w3.org/2001/tag/group/track/issues/53
[2] http://www.w3.org/2001/tag/group/track/issues/62
[3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
[4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01

On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@...> wrote:

> Eran Hammer-Lahav wrote:
>>>
>>> -----Original Message-----
>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>
>>> Now, given one information, you are proposing three mechanisms to
>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>> about the proposal?
>>>
>>
>> No. That's like saying an HTML document should never repeat any of the
>> links provided in the HTTP header, etc.
>
> Of course, it shouldn't.  In fact, no HTTP header should use URI except the
> Content-type, which unfortunately is not defined in this way.
>
>> The reality is that there isn't any single solution that satisfies all the
>> use cases we have. After over a year of debating it, this combination of
>> three methods is the best we have come up with, and it works fine. Is it a
>> beautiful solution with clean architecture? No. But it is the only solution
>> we can deploy today and expect people to use.
>>
>
> Define your "fineness"?  Making something works does not mean solving the
> desired problem.  If you know the solution is not clean, you should not that
> it should not be proposed at this level because it will have long term
> effects.
>>
>> If you read the proposal, it clearly goes through the list of available
>> methods and states why this approach was chosen.
>>
>
> Nope.  Your evaluation on content negotiation is very vague and, in my
> opinion, partial.
>
> Xiaoshu
>>
>> EHL

[Xiaoshu Wang]

Jonathan Rees wrote:

> [less cc:]
>
> Tracker, I write this email primarily for you. This whole thread is
> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>
> Xiaoshu, you're essentially pressing the TAG again to make a formal
> statement on recommended use of conneg, as Michael Hausenblas did in
> February [3]. I'm sorry that this has fallen to the periphery of the
> TAG business heap. The best I can do now is to point you to the advice
> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
> with Eran's reading.
>  

Yes.  I am pressing and I hope TAG can take it seriously.  I am not
pressing TAG to make a recommended use on conneg.  Conneg is there and
people is start using it.  I don't think AJAX community needs to ask TAG
before using conneg.  The mechanism is there, thanks to the well design
of HTTP, we can just use it.  What I am asking TAG to rethink
httpRange-14 because it will let us know how much nonsense that issue-62
as well as LRDD proposal is.  (Sorry for my bluntness, but why waste
time on propose something that you cannot even define?)

If we know that Information Resource does not make sense, then Generic
Resource does not make sense either because what is the definition of
this genericity?  As I have discussed in the manuscript "Is the Web a
Web of Document or Things?" (Going to be presented in IR-KR 2009,
http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all
these concepts are based on a somewhat "one resource to one
representation" assumption. It is the same on "the uniform access to
metadata".  What is "metadata"?  If you cannot define it, do you
honestly think that a proposal will be of any use?

The web is built on three things: URI, Resource, Representation.  There
is no fourth or fifth essential concepts.  Metadata,  generic resource,
information resource, whatever they are must be one of the three
entities.  Thus, you have to follow the design pattern of the first
three entities and then consider what we can standardize next for a more
specific problem.

Without solving httpRange-14, proposing anything else is like building a
house from top and hope that all those design can consistently converge
to a solid foundation.  I don't think that is the way it works and I
don't think it can work either.

Xiaoshu

> Jonathan
>
> [1] http://www.w3.org/2001/tag/group/track/issues/53
> [2] http://www.w3.org/2001/tag/group/track/issues/62
> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>
> On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@...> wrote:
>  
>> Eran Hammer-Lahav wrote:
>>    
>>>> -----Original Message-----
>>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>>
>>>> Now, given one information, you are proposing three mechanisms to
>>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>>> about the proposal?
>>>>
>>>>        
>>> No. That's like saying an HTML document should never repeat any of the
>>> links provided in the HTTP header, etc.
>>>      
>> Of course, it shouldn't.  In fact, no HTTP header should use URI except the
>> Content-type, which unfortunately is not defined in this way.
>>
>>    
>>> The reality is that there isn't any single solution that satisfies all the
>>> use cases we have. After over a year of debating it, this combination of
>>> three methods is the best we have come up with, and it works fine. Is it a
>>> beautiful solution with clean architecture? No. But it is the only solution
>>> we can deploy today and expect people to use.
>>>
>>>      
>> Define your "fineness"?  Making something works does not mean solving the
>> desired problem.  If you know the solution is not clean, you should not that
>> it should not be proposed at this level because it will have long term
>> effects.
>>    
>>> If you read the proposal, it clearly goes through the list of available
>>> methods and states why this approach was chosen.
>>>
>>>      
>> Nope.  Your evaluation on content negotiation is very vague and, in my
>> opinion, partial.
>>
>> Xiaoshu
>>    
>>> EHL
>>>      
>
>  

[Jonathan Rees-3]

Xiaoshu,

The architecture you advocate is plausible. The preferred architecture
that I hear coming the TAG is a different one. The TAG obviously can't
go back and change RFC2616 and expect anyone to listen, but it is
required by charter to give architectural advice. You can follow it or
not, that's your choice.

Rather than argue this conneg point yet again now, I will just say
I'll do what I can in the coming months to ensure that the TAG's
advice gets stated clearly enough that you and others can at least
give it a fair hearing, even if in the end you don't agree with it.

Best
Jonathan

On Sat, Jun 27, 2009 at 11:55 PM, Xiaoshu Wang<wangxiao@...> wrote:

> Jonathan Rees wrote:
>>
>> [less cc:]
>>
>> Tracker, I write this email primarily for you. This whole thread is
>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>
>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>> statement on recommended use of conneg, as Michael Hausenblas did in
>> February [3]. I'm sorry that this has fallen to the periphery of the
>> TAG business heap. The best I can do now is to point you to the advice
>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>> with Eran's reading.
>>
>
> Yes.  I am pressing and I hope TAG can take it seriously.  I am not pressing
> TAG to make a recommended use on conneg.  Conneg is there and people is
> start using it.  I don't think AJAX community needs to ask TAG before using
> conneg.  The mechanism is there, thanks to the well design of HTTP, we can
> just use it.  What I am asking TAG to rethink httpRange-14 because it will
> let us know how much nonsense that issue-62 as well as LRDD proposal is.
>  (Sorry for my bluntness, but why waste time on propose something that you
> cannot even define?)
>
> If we know that Information Resource does not make sense, then Generic
> Resource does not make sense either because what is the definition of this
> genericity?  As I have discussed in the manuscript "Is the Web a Web of
> Document or Things?" (Going to be presented in IR-KR 2009,
> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all these
> concepts are based on a somewhat "one resource to one representation"
> assumption. It is the same on "the uniform access to metadata".  What is
> "metadata"?  If you cannot define it, do you honestly think that a proposal
> will be of any use?
>
> The web is built on three things: URI, Resource, Representation.  There is
> no fourth or fifth essential concepts.  Metadata,  generic resource,
> information resource, whatever they are must be one of the three entities.
>  Thus, you have to follow the design pattern of the first three entities and
> then consider what we can standardize next for a more specific problem.
> Without solving httpRange-14, proposing anything else is like building a
> house from top and hope that all those design can consistently converge to a
> solid foundation.  I don't think that is the way it works and I don't think
> it can work either.
>
> Xiaoshu
>>
>> Jonathan
>>
>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>
>> On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@...> wrote:
>>
>>>
>>> Eran Hammer-Lahav wrote:
>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>>>
>>>>> Now, given one information, you are proposing three mechanisms to
>>>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>>>> about the proposal?
>>>>>
>>>>>
>>>>
>>>> No. That's like saying an HTML document should never repeat any of the
>>>> links provided in the HTTP header, etc.
>>>>
>>>
>>> Of course, it shouldn't.  In fact, no HTTP header should use URI except
>>> the
>>> Content-type, which unfortunately is not defined in this way.
>>>
>>>
>>>>
>>>> The reality is that there isn't any single solution that satisfies all
>>>> the
>>>> use cases we have. After over a year of debating it, this combination of
>>>> three methods is the best we have come up with, and it works fine. Is it
>>>> a
>>>> beautiful solution with clean architecture? No. But it is the only
>>>> solution
>>>> we can deploy today and expect people to use.
>>>>
>>>>
>>>
>>> Define your "fineness"?  Making something works does not mean solving the
>>> desired problem.  If you know the solution is not clean, you should not
>>> that
>>> it should not be proposed at this level because it will have long term
>>> effects.
>>>
>>>>
>>>> If you read the proposal, it clearly goes through the list of available
>>>> methods and states why this approach was chosen.
>>>>
>>>>
>>>
>>> Nope.  Your evaluation on content negotiation is very vague and, in my
>>> opinion, partial.
>>>
>>> Xiaoshu
>>>
>>>>
>>>> EHL
>>>>
>>
>>
>
>

[Xiaoshu Wang]

Jonathan Rees wrote:
> Xiaoshu,
>
> The architecture you advocate is plausible. The preferred architecture
> that I hear coming the TAG is a different one. The TAG obviously can't
> go back and change RFC2616 and expect anyone to listen, but it is
> required by charter to give architectural advice. You can follow it or
> not, that's your choice.
>  
Who said that we need to change RFC2616 to make it work?  As defined in
section 14.1 of RFC2616, the HTTP’s Accept header can be extended with
an “accept-extension” field by appending sets of name-value pairs after
the “accept-params”.  For instance, the

Accept: application/xml;q=1;d=
“http//psidev.sourceforge.net/mi/rel25/src/MIF25.xsd”

would allow a client to content negotiate the PSI-MI format.

All that is needed is a standard convention for the token *d*, which I
use it for short of (document-type).

Xiaoshu

> Rather than argue this conneg point yet again now, I will just say
> I'll do what I can in the coming months to ensure that the TAG's
> advice gets stated clearly enough that you and others can at least
> give it a fair hearing, even if in the end you don't agree with it.
>
> Best
> Jonathan
>
> On Sat, Jun 27, 2009 at 11:55 PM, Xiaoshu Wang<wangxiao@...> wrote:
>  
>> Jonathan Rees wrote:
>>    
>>> [less cc:]
>>>
>>> Tracker, I write this email primarily for you. This whole thread is
>>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>>
>>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>>> statement on recommended use of conneg, as Michael Hausenblas did in
>>> February [3]. I'm sorry that this has fallen to the periphery of the
>>> TAG business heap. The best I can do now is to point you to the advice
>>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>>> with Eran's reading.
>>>
>>>      
>> Yes.  I am pressing and I hope TAG can take it seriously.  I am not pressing
>> TAG to make a recommended use on conneg.  Conneg is there and people is
>> start using it.  I don't think AJAX community needs to ask TAG before using
>> conneg.  The mechanism is there, thanks to the well design of HTTP, we can
>> just use it.  What I am asking TAG to rethink httpRange-14 because it will
>> let us know how much nonsense that issue-62 as well as LRDD proposal is.
>>  (Sorry for my bluntness, but why waste time on propose something that you
>> cannot even define?)
>>
>> If we know that Information Resource does not make sense, then Generic
>> Resource does not make sense either because what is the definition of this
>> genericity?  As I have discussed in the manuscript "Is the Web a Web of
>> Document or Things?" (Going to be presented in IR-KR 2009,
>> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all these
>> concepts are based on a somewhat "one resource to one representation"
>> assumption. It is the same on "the uniform access to metadata".  What is
>> "metadata"?  If you cannot define it, do you honestly think that a proposal
>> will be of any use?
>>
>> The web is built on three things: URI, Resource, Representation.  There is
>> no fourth or fifth essential concepts.  Metadata,  generic resource,
>> information resource, whatever they are must be one of the three entities.
>>  Thus, you have to follow the design pattern of the first three entities and
>> then consider what we can standardize next for a more specific problem.
>> Without solving httpRange-14, proposing anything else is like building a
>> house from top and hope that all those design can consistently converge to a
>> solid foundation.  I don't think that is the way it works and I don't think
>> it can work either.
>>
>> Xiaoshu
>>    
>>> Jonathan
>>>
>>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>>
>>> On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@...> wrote:
>>>
>>>      
>>>> Eran Hammer-Lahav wrote:
>>>>
>>>>        
>>>>>> -----Original Message-----
>>>>>> From: Xiaoshu Wang [mailto:wangxiao@...]
>>>>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>>>>
>>>>>> Now, given one information, you are proposing three mechanisms to
>>>>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>>>>> about the proposal?
>>>>>>
>>>>>>
>>>>>>            
>>>>> No. That's like saying an HTML document should never repeat any of the
>>>>> links provided in the HTTP header, etc.
>>>>>
>>>>>          
>>>> Of course, it shouldn't.  In fact, no HTTP header should use URI except
>>>> the
>>>> Content-type, which unfortunately is not defined in this way.
>>>>
>>>>
>>>>        
>>>>> The reality is that there isn't any single solution that satisfies all
>>>>> the
>>>>> use cases we have. After over a year of debating it, this combination of
>>>>> three methods is the best we have come up with, and it works fine. Is it
>>>>> a
>>>>> beautiful solution with clean architecture? No. But it is the only
>>>>> solution
>>>>> we can deploy today and expect people to use.
>>>>>
>>>>>
>>>>>          
>>>> Define your "fineness"?  Making something works does not mean solving the
>>>> desired problem.  If you know the solution is not clean, you should not
>>>> that
>>>> it should not be proposed at this level because it will have long term
>>>> effects.
>>>>
>>>>        
>>>>> If you read the proposal, it clearly goes through the list of available
>>>>> methods and states why this approach was chosen.
>>>>>
>>>>>
>>>>>          
>>>> Nope.  Your evaluation on content negotiation is very vague and, in my
>>>> opinion, partial.
>>>>
>>>> Xiaoshu
>>>>
>>>>        
>>>>> EHL
>>>>>
>>>>>          
>>>      
>>    

[Jonathan Rees-3]

On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@...> wrote:

> Jonathan Rees wrote:
>>
>> Xiaoshu,
>>
>> The architecture you advocate is plausible. The preferred architecture
>> that I hear coming the TAG is a different one. The TAG obviously can't
>> go back and change RFC2616 and expect anyone to listen, but it is
>> required by charter to give architectural advice. You can follow it or
>> not, that's your choice.
>>
>
> Who said that we need to change RFC2616 to make it work?

I sure didn't! You misunderstood. I meant to say that almost arbitrary
use of content negotiation, such as what you want to do, seems
technically OK according to RFC 2616, because it never says precisely
what a "representation" is. The cool-uris-for-semweb opinion and
httpRange-14 give specific good-practice-style advice that is supposed
to discourage certain otherwise defensible uses of GET/200 and content
negotiation. Technically speaking, any attempt to make a server stay
within the TAG's advice would mean holding it to a contract that it
didn't sign. The TAG doesn't have jurisdiction to change RFC 2616 to
disallow things that are currently allowed. Therefore its advice,
while some people may find it persuasive (especially in the
linked-data world), is not rule of law but just a request for a
certain "good practice". So it is the TAG who must persuade you, not
the other way around. That's why I take your and Michael's email as
requests for a piece of writing. The case hasn't been made clearly
enough.

I didn't want to defend either architecture just now, but don't you agree that
1. you are promoting one pattern of use of conneg
2. the cool-uris/httpRange-14/etc. advice promotes a different pattern
3. both patterns can seen as compatible with RFC 2616, and
4. the two architectures are just plain different?
These seems terribly neutral and uncontroversial to me.

But I should note that if you want a tweak to the syntax of accept
headers you are asking for an extension to the HTTP protocol. That's
easier than getting agreement to a restriction, which is what the TAG
would like to do.

If we can first agree on these basics, we can then put the two
architectures side by side and see how well each meets various goals
that we might have. The real difference between them might be a
difference in what each is trying to accomplish.

Jonathan

(still ISSUE-53)

[Xiaoshu Wang]

Jonathan Rees wrote:

> On Sun, Jun 28, 2009 at 11:13 PM, Xiaoshu Wang<wangxiao@...> wrote:
>  
>> Jonathan Rees wrote:
>>    
>>> Xiaoshu,
>>>
>>> The architecture you advocate is plausible. The preferred architecture
>>> that I hear coming the TAG is a different one. The TAG obviously can't
>>> go back and change RFC2616 and expect anyone to listen, but it is
>>> required by charter to give architectural advice. You can follow it or
>>> not, that's your choice.
>>>
>>>      
>> Who said that we need to change RFC2616 to make it work?
>>    
>
> I sure didn't! You misunderstood. I meant to say that almost arbitrary
> use of content negotiation, such as what you want to do, seems
> technically OK according to RFC 2616, because it never says precisely
> what a "representation" is. The cool-uris-for-semweb opinion and
> httpRange-14 give specific good-practice-style advice that is supposed
> to discourage certain otherwise defensible uses of GET/200 and content
> negotiation. Technically speaking, any attempt to make a server stay
> within the TAG's advice would mean holding it to a contract that it
> didn't sign. The TAG doesn't have jurisdiction to change RFC 2616 to
> disallow things that are currently allowed. Therefore its advice,
> while some people may find it persuasive (especially in the
> linked-data world), is not rule of law but just a request for a
> certain "good practice". So it is the TAG who must persuade you, not
> the other way around. That's why I take your and Michael's email as
> requests for a piece of writing. The case hasn't been made clearly
> enough.
>
> I didn't want to defend either architecture just now, but don't you agree that
> 1. you are promoting one pattern of use of conneg
> 2. the cool-uris/httpRange-14/etc. advice promotes a different pattern
> 3. both patterns can seen as compatible with RFC 2616, and
> 4. the two architectures are just plain different?
> These seems terribly neutral and uncontroversial to me.
>
> But I should note that if you want a tweak to the syntax of accept
> headers you are asking for an extension to the HTTP protocol. That's
> easier than getting agreement to a restriction, which is what the TAG
> would like to do.
>
> If we can first agree on these basics, we can then put the two
> architectures side by side and see how well each meets various goals
> that we might have. The real difference between them might be a
> difference in what each is trying to accomplish.
>  

That is a very good summary.  But the question is: what is the problem?

If the problem is: let us find a way to uniform access to
metadata/descriptor" etc. Then, I don't even know what the problem is,
then how can we propose anything to do something about it?  Then, please
define the "metadata/descriptor" first.

I want to emphasize that I am not opposing people to use 303.  That is
*their* design choice and I have no business to tell them what is best
for them.  What I am opposing is the practice of proposing an approach
based on ambiguous concept.  I came to conneg not because I prefer it
but because it is the only choice.  All alternatives force me to ask
questions that bring the questions themselves into questions.  That puts
me in a forever loop but I need to get out of that.  I hope that TAG can
understand that the latter is my purpose but not "conneg".

Xiaoshu

[Williams, Stuart (HP Labs, Bristol)]

Xiaoshu,

> -----Original Message-----
> From: www-tag-request@... [mailto:www-tag-request@...]
> On Behalf Of Xiaoshu Wang
> Sent: 28 June 2009 04:55
> To: Jonathan Rees
> Cc: www-tag@...
> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
> Proposed Changes
>
> Jonathan Rees wrote:
> > [less cc:]
> >
> > Tracker, I write this email primarily for you. This whole thread is
> > about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
> >
> > Xiaoshu, you're essentially pressing the TAG again to make a formal
> > statement on recommended use of conneg, as Michael Hausenblas did in
> > February [3]. I'm sorry that this has fallen to the periphery of the
> > TAG business heap. The best I can do now is to point you to the advice
> > [4] that we gave to the Cool URIs for the Semweb editors, which agrees
> > with Eran's reading.
> >  
> Yes.  I am pressing and I hope TAG can take it seriously.  I am not
> pressing TAG to make a recommended use on conneg.  Conneg is there and
> people is start using it.  I don't think AJAX community needs to ask TAG
> before using conneg.  The mechanism is there, thanks to the well design
> of HTTP, we can just use it.  What I am asking TAG to rethink
> httpRange-14 because it will let us know how much nonsense that issue-62
> as well as LRDD proposal is.  (Sorry for my bluntness, but why waste
> time on propose something that you cannot even define?)

Specifically, what is it that you are asking the TAG to rethink?

The TAGs httpRange-14 resolution and subsequent contributions to the "Cool URIs for the Semantic Web" amounts to saying that:

- fragment-less http URI can be used to refer-to, name... any kind of thing

- and for things that do not/cannot possibly have awww:representations (and I am such a thing)
  please deploy a redirection (303) to a different thing that (if the redirection is to be useful)
  has something say about the thing first asked about.

> If we know that Information Resource does not make sense, then Generic
> Resource does not make sense either because what is the definition of
> this genericity?  As I have discussed in the manuscript "Is the Web a
> Web of Document or Things?" (Going to be presented in IR-KR 2009,
> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all
> these concepts are based on a somewhat "one resource to one
> representation" assumption.

I think I have to cry foul again here. You state repeatedly that this assumption is made in the AWWW or by the TAG and then proceed to argue against it. I can assure you that I know of no-one on the TAG or that contributed to the writing of AWWW that makes that assumption.

Maybe you are speaking here of an assumption that you make in your work, but I don't think that is the case.

> It is the same on "the uniform access to metadata".  
> What is "metadata"?  If you cannot define it, do you
> honestly think that a proposal will be of any use?
>
> The web is built on three things: URI, Resource, Representation

AWWW is about those three things (and Interaction).

> There is no fourth or fifth essential concepts.  Metadata,  generic resource,
> information resource, whatever they are must be one of the three
> entities.  Thus, you have to follow the design pattern of the first
> three entities and then consider what we can standardize next for a more
> specific problem.
>
> Without solving httpRange-14,

What (in your view) is not solved? [You may not like the solution, but that is a different matter].

[And if you want a framing of the question, it is "What should be deployed on the web at http://example.net/people/skw where the intention is that URI is used to name and to refer-to me (the person)? Further the deployment should be such as to avoid the possibility of confusing a reference to me as reference to a document about me."]

> proposing anything else is like building a
> house from top and hope that all those design can consistently converge
> to a solid foundation.  I don't think that is the way it works and I
> don't think it can work either.
>
> Xiaoshu
> > Jonathan
> >
> > [1] http://www.w3.org/2001/tag/group/track/issues/53
> > [2] http://www.w3.org/2001/tag/group/track/issues/62
> > [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
> > [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01

Stuart
--

<snip/>

[Xiaoshu Wang]

Williams, Stuart (HP Labs, Bristol) wrote:

> Xiaoshu,
>
>  
>> -----Original Message-----
>> From: www-tag-request@... [mailto:www-tag-request@...]
>> On Behalf Of Xiaoshu Wang
>> Sent: 28 June 2009 04:55
>> To: Jonathan Rees
>> Cc: www-tag@...
>> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
>> Proposed Changes
>>
>> Jonathan Rees wrote:
>>    
>>> [less cc:]
>>>
>>> Tracker, I write this email primarily for you. This whole thread is
>>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>>
>>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>>> statement on recommended use of conneg, as Michael Hausenblas did in
>>> February [3]. I'm sorry that this has fallen to the periphery of the
>>> TAG business heap. The best I can do now is to point you to the advice
>>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>>> with Eran's reading.
>>>  
>>>      
>> Yes.  I am pressing and I hope TAG can take it seriously.  I am not
>> pressing TAG to make a recommended use on conneg.  Conneg is there and
>> people is start using it.  I don't think AJAX community needs to ask TAG
>> before using conneg.  The mechanism is there, thanks to the well design
>> of HTTP, we can just use it.  What I am asking TAG to rethink
>> httpRange-14 because it will let us know how much nonsense that issue-62
>> as well as LRDD proposal is.  (Sorry for my bluntness, but why waste
>> time on propose something that you cannot even define?)
>>    
>
> Specifically, what is it that you are asking the TAG to rethink?
>  

(1) The necessity for the definition of "Information Resource".
(1a) If TAG thinks IR is necessary, please give a concrete definition so
that every can be used objectively. The current definition is not a
definition. It is more like a wish but a definition.
(1b) If TAG cannot define IR, then eliminate it.
> The TAGs httpRange-14 resolution and subsequent contributions to the "Cool URIs for the Semantic Web" amounts to saying that:
>
> - fragment-less http URI can be used to refer-to, name... any kind of thing
>
> - and for things that do not/cannot possibly have awww:representations (and I am such a thing)
>   please deploy a redirection (303) to a different thing that (if the redirection is to be useful)
>   has something say about the thing first asked about.
>  
But *please* define the "can", whose capability in what regard? Is it
O.K. for me to 200 an HTML-representation for myself, which is a person?
I definitely think that I *can* but I guess you would think so. Then,
what is the standard of this "can or cannot" list or criteria?

If TAG think that it is O.K. for my kind of "can", then I am fine with
that because it only says that the concept of "information resource"
varies from person to person. Else, let me know how to tell IR from
non-IR because, currently, to be safe (i.e., not being accused of
violating the web architecture), the only thing that I can do is to 303
forever.

Note, using hash-URI doesn't get me out of the predicament of "Can I 200
now? because my hash URI still have to be rooted on some slash URI,
which IR-ness I must ponder by the httpRange-14.

>> If we know that Information Resource does not make sense, then Generic
>> Resource does not make sense either because what is the definition of
>> this genericity?  As I have discussed in the manuscript "Is the Web a
>> Web of Document or Things?" (Going to be presented in IR-KR 2009,
>> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all
>> these concepts are based on a somewhat "one resource to one
>> representation" assumption.
>>    
>
> I think I have to cry foul again here. You state repeatedly that this assumption is made in the AWWW or by the TAG and then proceed to argue against it. I can assure you that I know of no-one on the TAG or that contributed to the writing of AWWW that makes that assumption.
>
> Maybe you are speaking here of an assumption that you make in your work, but I don't think that is the case.
>  

Sure, I sincerely *wish* that I am wrong. But then it is beyond my
comprehension why TAG is so obsessed with IR/httpRange-14. I remember
that a few months back TAG was even proposing IETF to 404 back some
documents. So, suddenly 404 isn't that bad any more, huh? Then, why we
ask people to make "cool URI"? It really sound ridiculous to me.

It is interesting that in AWWW it says "We define the term “information
resource” because we observe that it is useful in discussions of Web
technology and may be useful in constructing specifications for
facilities built for use on the Web."

I wonder if after so many years of debate. No one has shown even one
application that has benefited from using the concept of IR. It perhaps
is what it is -- only useful in *discussion*. Why compound people with
some concept that we don't even know what it is?
>> It is the same on "the uniform access to metadata".  
>> What is "metadata"?  If you cannot define it, do you
>> honestly think that a proposal will be of any use?
>>
>> The web is built on three things: URI, Resource, Representation
>>    
>
> AWWW is about those three things (and Interaction).
>  
Of course. But interaction is how the Web is implemented and realized.
And what a URI denote should have nothing to do with how a message is
retrieved by a particular protocol. Can I use a ftp-URI to denote a
person? I sure can, right? And then how do I 303 that? httpRange-14
breaks the most fundamental principle -- the principle of orthogonal
specification.

>> There is no fourth or fifth essential concepts.  Metadata,  generic resource,
>> information resource, whatever they are must be one of the three
>> entities.  Thus, you have to follow the design pattern of the first
>> three entities and then consider what we can standardize next for a more
>> specific problem.
>>
>> Without solving httpRange-14,
>>    
>
> What (in your view) is not solved? [You may not like the solution, but that is a different matter].
>  

In my view, httpRange-14 solves no problem at all. What it does is to
create a problem (at least for me). And the created problem is a very
huge one because the semantics of 200 suddenly becomes murky.
> [And if you want a framing of the question, it is "What should be deployed on the web at http://example.net/people/skw where the intention is that URI is used to name and to refer-to me (the person)? Further the deployment should be such as to avoid the possibility of confusing a reference to me as reference to a document about me."]
>  
You use "http://example.net/people/skw" just as you use your name.
People needs to realize that what they get is a document retrieved from
the URI but not what the URI denotes. I have proposed to use
"http://example.net/people/skw#(mine-type)" to denote the document of a
particular mine-type retrieved from that document. The treatment is the
same whether the URI in question contains a fragment or not. Thus, if
you use "http://example.net/people#skw" to denote you. Then the URI
"http://example.net/people#(mine-type)skw" would denote a particular
document-fragment describing you.

Of course, such a #(mine-type) is not absolutely needed, since we can
always design properties and using b-node, etc to describe it. The
syntax just makes it more convenient. But no matter what, what a URI
denotes is always up to the owner of a URI. A client retrieves
information and judge if s/he should accept it or not. httpRange-14
basically takes the ownership of URI's meaning away from its owner.

Xiaoshu

>  
>> proposing anything else is like building a
>> house from top and hope that all those design can consistently converge
>> to a solid foundation.  I don't think that is the way it works and I
>> don't think it can work either.
>>
>> Xiaoshu
>>    
>>> Jonathan
>>>
>>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>>      
>
> Stuart
> --
>
> <snip/>
>  

[Jonathan Rees-3]

On Mon, Jun 29, 2009 at 11:46 AM, Xiaoshu Wang<wangxiao@...> wrote:
> >I don't even know what the problem is, then
> how can we propose anything to do something about it?  Then, please define
> the "metadata/descriptor" first.

I don't understand what the difficulty is with the definition (which
you've heard many times now)? A description resource is simply a
document in the role of describing something. Is it hard for you to
figure out when a document describes something? The relation is
foaf:primaryTopic, or the related powder:describedby, both of which
are widely used.

If the trouble is distinguishing a "document" or "information
resource" from a chair, or "describing" from "being", I can't help
you.

If the trouble is the dual sense of "document" as in
"webarch-representation" (what's transmitted) vs. "information
resource" (something that can be changed, re-expressed, etc.), first
note that "representation" is a term of art in the webarch document
and shouldn't be taken to mean "representation" in common usage (as if
there were a single sense). But I think the overloading is plausible.

IR is a sort of ontological reverse engineering: If one were to use a
URI in an href= attribute to refer to something, to what would it
refer? Fill in the blank in "the source page links to a ____." It
might refer to a thing that has an author or a subject (chairs don't),
or that carries information digitally (chairs don't). The target is
something that is (or could be) "on the web" in a way that a chair
can't be. If you click on a link, and get to a picture of a chair, you
have gone to the picture, not to the chair.  -- This is simply an
architectural choice, not a matter of fact. There is no point in
arguing against it as if it were wrong. You have to argue on the basis
of utility.

If the trouble is the exact line between "document" or "information
resource" and something like a chair that isn't, I have some sympathy,
and I'm working on addressing this (in my spare time; see previous
paragraph). But I think most parties to the conversation agree that
some things are IRs and some aren't, even if the boundary is unclear.
And for various reasons not everyone agrees that a rigorous definition
is either necessary or possible. Anyhow what are the consequences of
disagreeing over the boundaries of the GET/200 restriction? It's just
advice, and if you don't like it or don't know how to apply it, then
just ignore it! And by all means send in your difficult use cases to
help us figure it out (I already have a collection).

So you asked what problems are there to be solved. The problems here
that *I* would be trying to solve in a web architecture are not
philosophical or even ontological but rather pragmatic, and include
(1) following a hyperlink to get something, and finding garbage,
because conneg did a bait-and-switch; (2) concluding that a person has
an author, or that a person was a book, or that the author of a book
was someone who wasn't, after collecting RDF from two different
locations (the RDF having been separately curated in response to
observing 200 responses.) The current TAG advice is one approach to
addressing these. The only solution to (1) is having all simultaneous
webarch-representations convey the same message, not merely different
messages about the same thing. *Any* solution to (2) will attempt to
get the community to make X vs. about-X reference decisions
consistently, but one design steers everyone towards serving
expressions (wa-representations, translations, etc.), and the other
steers everyone the other.

Model T of 200-responding URI U:

. U identifies web page
. U refers to web page ("information resource")
. Response R from U is an expression (restatement, rendering,
representation, translation, reformatting, ...) of referent by U
. R says what U's referent says (expresses its information)

Model X:
. U identifies web page ...per 2616...?
. U refers to arbitrary thing (supposed to be obvious by looking at R?)
. Response R from U is somehow related (how?) to referent of U
. R says anything it wants to about referent of U (not necessarily the
same as other wa-representations)

To compare these, consider what each model predicts about how someone
might use 200-responding URIs to refer. For example, consider the URI
"http://en.wikipedia.org/wiki/Magna_carta". Someone following Model T
would take the URI to refer to the wikipedia article about the Magna
Carta. Someone following Model X would take it to refer to the Magna
Carta.

Then what about "http://www.thelatinlibrary.com/magnacarta.html" ?
Under Model T, the URI refers to the Magna Carta (or maybe that
particular incarnation of; but the difference may not matter for the
application at hand) - the same thing that the wikipedia URI referred
to under Model T. Under Model X, the URI refers to... what? The rights
of man? By failing to distinguish between a document and a description
of a document, one is deprived of URIs for things that one wants to
refer to - the same things that one wants hyperlink-followers to see
by following links. If I link to wikipedia, I want you to go to the
wikipedia article, darnit, not to the Magna Carta.

And if I ask to follow a link to the Magna Carta, I similarly *don't*
want to see a description of it, even if my preferred content-type is
RDF! The RDF I get should be an RDF *expression* (translation) of the
Magna Carta, because I read RDF more easily than I read Latin; not
some random pile of other information, no matter how useful.

Exercise: Apply the two models to this URI: http://news.google.com/

I'm not saying the work on this subject is over; I'm just saying that
the X/about-X confusion (which is a kind of use/mention confusion) is
a legitimate problem, and justifies some amount of "obsession". I
think the solution will be a sensible explanation, and you and Michael
are right that at present there is no good consensus document, and
that there should be.

-Jonathan

[Xiaoshu Wang]

Jonathan Rees wrote:

> On Mon, Jun 29, 2009 at 11:46 AM, Xiaoshu Wang<wangxiao@...> wrote:
>  
>>> I don't even know what the problem is, then
>>>      
>> how can we propose anything to do something about it?  Then, please define
>> the "metadata/descriptor" first.
>>    
>
> I don't understand what the difficulty is with the definition (which
> you've heard many times now)? A description resource is simply a
> document in the role of describing something. Is it hard for you to
> figure out when a document describes something? The relation is
> foaf:primaryTopic, or the related powder:describedby, both of which
> are widely used.
>  

O.K. Assuming that you are a URI owner.  So, given a set of
informations, say it is put in an RDF document, then tell me which
sub-graph that I should put in as "descriptive" while the other "not"?  
If you cannot tell them apart by a definite criteria, then how should
you know what to put in the entity and what to put in the LINK header.  
(Don't think the case of internal link, it is different).

Now, imagine being a client, should you just get the entity or LINK or
both?  How do you know?  I know I want some information about say,
Dublin-core metadata, how do I know if it is in LINK or in Entity or both?

If your answer is anything goes, then where is the "uniformity"?
> If the trouble is distinguishing a "document" or "information
> resource" from a chair, or "describing" from "being", I can't help
> you.
>  
Define your word "document" because it is sometimes in AWWW used as an
"information resource", which I do have trouble grasping.  So, please
explain.

> If the trouble is the dual sense of "document" as in
> "webarch-representation" (what's transmitted) vs. "information
> resource" (something that can be changed, re-expressed, etc.), first
> note that "representation" is a term of art in the webarch document
> and shouldn't be taken to mean "representation" in common usage (as if
> there were a single sense). But I think the overloading is plausible.
>
> IR is a sort of ontological reverse engineering: If one were to use a
> URI in an href= attribute to refer to something, to what would it
> refer? Fill in the blank in "the source page links to a ____."

Hold on!  Define your source page first, is it a representation or a
resource.
> It
> might refer to a thing that has an author or a subject (chairs don't),
> or that carries information digitally (chairs don't).
Why chair doesn't?  Can I say "the page is laying on a chair"?
> The target is
> something that is (or could be) "on the web" in a way that a chair
> can't be. If you click on a link, and get to a picture of a chair, you
> have gone to the picture, not to the chair.  -- This is simply an
> architectural choice, not a matter of fact. There is no point in
> arguing against it as if it were wrong. You have to argue on the basis
> of utility.
>  
Yes, if it is an architectural choice of a particular user, then it is
fine because it does not affect me.  But if TAG means intends to make it
an architectural choice of everyone.  In the latter case, I have
complain because it makes it impossible to work with.

Which choice is TAG's?  Please be clear.
> If the trouble is the exact line between "document" or "information
> resource" and something like a chair that isn't, I have some sympathy,
> and I'm working on addressing this (in my spare time; see previous
> paragraph). But I think most parties to the conversation agree that
> some things are IRs and some aren't, even if the boundary is unclear.
>  
Really? Is an image an IR?  I think everyone has a very firm answer on
that.  But I really have trouble to figure it out.  When put under the
examination of conneg, I can no longer be sure what a URI denote.

> And for various reasons not everyone agrees that a rigorous definition
> is either necessary or possible. Anyhow what are the consequences of
> disagreeing over the boundaries of the GET/200 restriction? It's just
> advice, and if you don't like it or don't know how to apply it, then
> just ignore it! And by all means send in your difficult use cases to
> help us figure it out (I already have a collection).
>
> So you asked what problems are there to be solved. The problems here
> that *I* would be trying to solve in a web architecture are not
> philosophical or even ontological but rather pragmatic, and include
>  

Yes, Pragmatics! This is what I want.
> (1) following a hyperlink to get something, and finding garbage,
> because conneg did a bait-and-switch; (2) concluding that a person has
> an author, or that a person was a book, or that the author of a book
> was someone who wasn't, after collecting RDF from two different
> locations (the RDF having been separately curated in response to
> observing 200 responses.)
Wait.  You mean by collecting 200 responses as your personal choice or
TAG's recommended choice?   I have no saying about the former because a
client can filter  his/her information anyway s/he wants.  But if it is
the latter, then shouldn't I and you be worried?  And then this goes
back to the question of IR definition?

I want it to be pragmatic in such that I gathered a bunch of
information, whether it by HTTP, ftp, mailto, or even snail mail, etc.
and then I read its content to judge if any claim is true or not.

httpRange-14 says, no.  you cannot do that.  You have to check if a URI
200 or not.  Which one is more pragmatic?

> The current TAG advice is one approach to
> addressing these. The only solution to (1) is having all simultaneous
> webarch-representations convey the same message, not merely different
> messages about the same thing. *Any* solution to (2) will attempt to
> get the community to make X vs. about-X reference decisions
> consistently, but one design steers everyone towards serving
> expressions (wa-representations, translations, etc.), and the other
> steers everyone the other.
>  
Please!  Let's define your *equivalence* first before making any further
assumption. This is what many people has asked TAG to clarify what is
granted under content negotiation.
> Model T of 200-responding URI U:
>
> . U identifies web page
> . U refers to web page ("information resource")
> . Response R from U is an expression (restatement, rendering,
> representation, translation, reformatting, ...) of referent by U
> . R says what U's referent says (expresses its information)
>  
Define "web page"? First, do we agree that there are three entities in
the Web, URI, Representation and Resource?  Then is the "web page" a
subclass of which?  Or you have another more fundamental concept?
> Model X:
> . U identifies web page ...per 2616...?
>  
Nope.  There is no concept of "web page"
> . U refers to arbitrary thing (supposed to be obvious by looking at R?)
>  
Yes.
> . Response R from U is somehow related (how?) to referent of U
>  
Why the nature of R has anything to do with U?  R describes what U's
referent is.  As a client, you either accept it or not.  It is as simple
as that.
> . R says anything it wants to about referent of U (not necessarily the
> same as other wa-representations)
>  
Of course, you think TAG can do anything otherwise?
> To compare these, consider what each model predicts about how someone
> might use 200-responding URIs to refer. For example, consider the URI
> "http://en.wikipedia.org/wiki/Magna_carta". Someone following Model T
> would take the URI to refer to the wikipedia article about the Magna
> Carta. Someone following Model X would take it to refer to the Magna
> Carta.
>  
No.  Unless there is an explicit statement saying
"http://en.wikipedia.org/wiki/Magna_carta" is Magna Carta, then it is.  
It is up to the URI's owner but not TAG.  But the URI never denote the
thing that flies into your laptop.

> Then what about "http://www.thelatinlibrary.com/magnacarta.html" ?
> Under Model T, the URI refers to the Magna Carta (or maybe that
> particular incarnation of; but the difference may not matter for the
> application at hand) - the same thing that the wikipedia URI referred
> to under Model T. Under Model X, the URI refers to... what? The rights
> of man? By failing to distinguish between a document and a description
> of a document, one is deprived of URIs for things that one wants to
> refer to - the same things that one wants hyperlink-followers to see
> by following links. If I link to wikipedia, I want you to go to the
> wikipedia article, darnit, not to the Magna Carta.
>  

What about it?  A URI's semantics is opaque, what difference does an
extra ".html" should make?  I am not sure what you are leading to.
> And if I ask to follow a link to the Magna Carta, I similarly *don't*
> want to see a description of it, even if my preferred content-type is
> RDF! The RDF I get should be an RDF *expression* (translation) of the
> Magna Carta, because I read RDF more easily than I read Latin; not
> some random pile of other information, no matter how useful.
>  
You always sees a description.  But you always get a *description* but
never the real thing.  This is not just about philosophy but also
physics, If you read something about quantum mechanics, you will know
how much you assumptions that we have been taking.  We know things by
"interacting" with it.  We see something, such as a particle, by shining
a light on it and read its inflection.  You never really know where the
particle is and/or its velocity.  This is Heisenberg uncertainty principle.
> Exercise: Apply the two models to this URI: http://news.google.com/
>
> I'm not saying the work on this subject is over; I'm just saying that
> the X/about-X confusion (which is a kind of use/mention confusion) is
> a legitimate problem, and justifies some amount of "obsession". I
> think the solution will be a sensible explanation, and you and Michael
> are right that at present there is no good consensus document, and
> that there should be.
>  
There is never a confusion to start with. A representation retrieved
from a URI is always something about the URI's referent.  It is as
simple as that.   It is the IR/httpRange-14 that wants to define this
about-ness.  But it has given rise to all sorts of the problems.

Would you agree that if there is a syntactic difference in URI to
distinguish a Representation from a Resource, it would force people to
be clear on what they are writing in URI?  Don't you think, that is a
better way to avoid ambiguity than a definition composed of "all,
essential, can"?

Xiaoshu

Xiaoshu

[Williams, Stuart (HP Labs, Bristol)]

Xiashou,

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: 29 June 2009 18:25
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Jonathan Rees; www-tag@...
> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
> Proposed Changes
>
> Williams, Stuart (HP Labs, Bristol) wrote:
> > Xiaoshu,
> >
> >  
> >> -----Original Message-----
> >> From: www-tag-request@... [mailto:www-tag-request@...]
> >> On Behalf Of Xiaoshu Wang
> >> Sent: 28 June 2009 04:55
> >> To: Jonathan Rees
> >> Cc: www-tag@...
> >> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
> >> Proposed Changes
> >>
> >> Jonathan Rees wrote:
> >>    
> >>> [less cc:]
> >>>
> >>> Tracker, I write this email primarily for you. This whole thread is
> >>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
> >>>
> >>> Xiaoshu, you're essentially pressing the TAG again to make a formal
> >>> statement on recommended use of conneg, as Michael Hausenblas did in
> >>> February [3]. I'm sorry that this has fallen to the periphery of the
> >>> TAG business heap. The best I can do now is to point you to the advice
> >>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
> >>> with Eran's reading.
> >>>  
> >>>      
> >> Yes.  I am pressing and I hope TAG can take it seriously.  I am not
> >> pressing TAG to make a recommended use on conneg.  Conneg is there and
> >> people is start using it.  I don't think AJAX community needs to ask TAG
> >> before using conneg.  The mechanism is there, thanks to the well design
> >> of HTTP, we can just use it.  What I am asking TAG to rethink
> >> httpRange-14 because it will let us know how much nonsense that issue-62
> >> as well as LRDD proposal is.  (Sorry for my bluntness, but why waste
> >> time on propose something that you cannot even define?)
> >>    
> >
> > Specifically, what is it that you are asking the TAG to rethink?
> >  
> (1) The necessity for the definition of "Information Resource".
> (1a) If TAG thinks IR is necessary, please give a concrete definition so
> that every can be used objectively. The current definition is not a
> definition. It is more like a wish but a definition.
> (1b) If TAG cannot define IR, then eliminate it.
> > The TAGs httpRange-14 resolution and subsequent contributions to
> >the "Cool URIs for the Semantic Web" amounts to saying that:
> >
> > - fragment-less http URI can be used to refer-to, name... any kind of thing
> >
> > - and for things that do not/cannot possibly have awww:representations (and I am such a thing)
> >   please deploy a redirection (303) to a different thing that (if the redirection is to be useful)
> >   has something say about the thing first asked about.
> >  
> But *please* define the "can", whose capability in what regard?

I can offer some characteristics and have done so in the past - eg. things that have mass do not/cannot possibly have awww:representations.
Things whose state (and state history) can be serialised as a message can have awww:representations.
Things that are entirely conceptual - eg an RDF property or class fall into a bit of a grey area.

Personnally I could have lived with a resolution to httpRange-14 that allowed descriptive representations for things referenced by slash http URI and left classification of the resource (if required) to some higher level. FWIW, information/non-information resource is a bit coarse grained anyway.

However, I was also persuaded by Pat's arguments about far-distant galaxies (several light years away) how on earth could they possibly be involved in any http interaction arising from an attempt to access them using a slashed' http URI to refer to them?  Even a physical body somewhat closer?

AIUI the intention of web architecture is that URI are usable to access the things that they are use to name/denote/refer-to (all of which are intented to be aligned). There are things that cannot not possibly be accessed by the web - so the pragmatic thing to do (if you intent to respect that intention of web architecture) is *not* to deploy representations at the http: URI used to name those things.

> Is it
> O.K. for me to 200 an HTML-representation for myself, which is a person?

IMO no... it is not ok.

> I definitely think that I *can* but I guess you would think so. Then,
> what is the standard of this "can or cannot" list or criteria?
>
> If TAG think that it is O.K. for my kind of "can", then I am fine with
> that because it only says that the concept of "information resource"
> varies from person to person. Else, let me know how to tell IR from
> non-IR because, currently, to be safe (i.e., not being accused of
> violating the web architecture), the only thing that I can do
> is to 303 forever.
>
> Note, using hash-URI doesn't get me out of the predicament of  "Can I 200
> now? because my hash URI still have to be rooted on some slash URI,
> which IR-ness I must ponder by the httpRange-14.
>
> >> If we know that Information Resource does not make sense, then Generic
> >> Resource does not make sense either because what is the definition of
> >> this genericity?  As I have discussed in the manuscript "Is the Web a
> >> Web of Document or Things?" (Going to be presented in IR-KR 2009,
> >>
> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all
> >> these concepts are based on a somewhat "one resource to one representation" assumption.
> >>    
> >
> > I think I have to cry foul again here. You state repeatedly
> that this assumption is made in the AWWW or by the TAG and
> then proceed to argue against it. I can assure you that I
> know of no-one on the TAG or that contributed to the writing
> of AWWW that makes that assumption.
> >
> > Maybe you are speaking here of an assumption that you make
> in your work, but I don't think that is the case.
> >  
> Sure, I sincerely *wish* that I am wrong. But then it is beyond my
> comprehension why TAG is so obsessed with IR/httpRange-14.

:-) I think that the TAG has moved beyond it and that the obsession lies elsewhere.

> I remember
> that a few months back TAG was even proposing IETF to 404 back some
> documents. So, suddenly 404 isn't that bad any more, huh?  

Sorry... I can't ground that in anything that I'm aware of.

> Then, why we
> ask people to make "cool URI"? It really sound ridiculous to me.
>
> It is interesting that in AWWW it says "We define the term "information
> resource" because we observe that it is useful in discussions of Web
> technology and may be useful in constructing specifications for
> facilities built for use on the Web."

Well... for me the distinction is between things that are:

1) material/physical things
2) abstract/conceptual things
3) information things (serialisable in a message)

The only one category that gives some pause for thought is the 2nd one, such things certainly admit description, but can they have awww:representation of themselves? (I could go either way).

> I wonder if after so many years of debate. No one has shown even one
> application that has benefited from using the concept of IR. It perhaps
> is what it is -- only useful in *discussion*. Why compound people with
> some concept that we don't even know what it is?
> >> It is the same on "the uniform access to metadata".  
> >> What is "metadata"?  If you cannot define it, do you
> >> honestly think that a proposal will be of any use?
> >>
> >> The web is built on three things: URI, Resource, Representation
> >>    
> >
> > AWWW is about those three things (and Interaction).
> >  
> Of course. But interaction is how the Web is implemented and realized.
> And what a URI denote should have nothing to do with how a message is
> retrieved by a particular protocol. Can I use a ftp-URI to denote a
> person? I sure can, right? And then how do I 303 that? httpRange-14
> breaks the most fundamental principle -- the principle of orthogonal
> specification.

httpRange-14 was asked and resolved in the context of HTTP URI. It has nothing to say about FTP URI.

> >> There is no fourth or fifth essential concepts.  Metadata, generic resource,
> >> information resource, whatever they are must be one of the three
> >> entities.  Thus, you have to follow the design pattern of the first
> >> three entities and then consider what we can standardize next for a more
> >> specific problem.
> >>
> >> Without solving httpRange-14,
> >>    
> >
> > What (in your view) is not solved? [You may not like the
> solution, but that is a different matter].
> >  
> In my view, httpRange-14 solves no problem at all. What it does is to
> create a problem (at least for me). And the created problem is a very
> huge one because the semantics of 200 suddenly becomes murky.
> > [And if you want a framing of the question, it is "What should be deployed on the web at
> http://example.net/people/skw where the intention is that URI
> is used to name and to refer-to me (the person)? Further the
> deployment should be such as to avoid the possibility of
> confusing a reference to me as reference to a document about me."]
> >  
> You use "http://example.net/people/skw" just as you use your name.
> People needs to realize that what they get is a document retrieved from
> the URI but not what the URI denotes.

Ah... Well there we have it... See above... a different intention for the architecture.

> I have proposed to use
> "http://example.net/people/skw#(mine-type)" to denote the document of a
> particular mine-type retrieved from that document.

I don't think that you have freedom to do that. The attribution of significance to frag ids is delegated to media-types specifications, doing what you suggest would be a big change. Practically you could do something similar in ? Space eg.

        http://example.net/people/skw?mt=(mine-type)

But again it would be a stretch to get universal adoption... It is little different then from a suffix based convention:

        http://example.net/people/skw                names me, the person,
        http://example.net/people/skw.about        names a document about me (and access to the former are redirected to the latter)

> The treatment is the
> same whether the URI in question contains a fragment or not. Thus, if
> you use "http://example.net/people#skw" to denote you. Then the URI
> "http://example.net/people#(mine-type)skw" would denote a particular
> document-fragment describing you.
>
> Of course, such a #(mine-type) is not absolutely needed, since we can
> always design properties and using b-node, etc to describe it. The
> syntax just makes it more convenient. But no matter what, what a URI
> denotes is always up to the owner of a URI. A client retrieves
> information and judge if s/he should accept it or not. httpRange-14
> basically takes the ownership of URI's meaning away from its owner.
>
> Xiaoshu
> >  
> >> proposing anything else is like building a
> >> house from top and hope that all those design can consistently converge
> >> to a solid foundation.  I don't think that is the way it works and I
> >> don't think it can work either.
> >>
> >> Xiaoshu
> >>    
> >>> Jonathan
> >>>
> >>> [1] http://www.w3.org/2001/tag/group/track/issues/53
> >>> [2] http://www.w3.org/2001/tag/group/track/issues/62
> >>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
> >>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
> >>>      
> >
> > Stuart
> > --
> >
> > <snip/>
> >  

Stuart
--

[Xiaoshu Wang]

Stuart,

I will answer in one block instead of paragraph by paragraph.  I think
it will be more cohesive.

The Magna Carta example that Jonathan gave yesterday made me to think:
what went wrong for this thinking "If I link to wikipedia, I want you to
go to the wikipedia article, darnit, not to the Magna Carta."

I think it is caused by the duality of a URI for being both URN and
URL.  Here, URN is used different from other URN, such as LSID etc., I
use the URN in an absolute sense that it is independent of any
transportation protocol. If people understand this duality and knows
when they are using it in which sense, I don't think that there will be
any such confusion.  Say, let

//en.wikipedia.org/wiki/Magna_Carta = Mogna_Carta

Then, the wikipedia article would be denoted by "http:Mogna_Carta".  I
doubt there will any ambiguity.

Then, this comes back to the definition of Information Resource, with a
URN, wouldn't IR be the set of all URL's referent?  If we have not taken
IR as *representation*, would this (the duality of URI as name and
locator) be the cause?

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?

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.

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.

Honestly, I do not buy the "cost" argument.  I wonder what is the
priority of TAG?  Is it to create patchy solution here and there?  Or to
think thoroughly and tries to settle down a set of solid foundation and
methodology before evaluating anything else?

Ideally, here is the list of things I wish TAG to consider.

1.  The necessity of *one* URN.
    URN is a URI but without a pre-defined transportation protocol. We
use URN to describe anything in the world, just like a word in natural
language.
    Syntax: my proposal is to make it an HTTP-URI sans "http:".
2.  The URN can be bound to any number of URL.
    A URL denotes a (information) resource that provides information
about the URN.
    Syntax: scheme + ":" + URN.
     Here, a scheme must correspond to a transportation protocol but not
naming protocol. Thus, there will be no more argument about if we need a
new URI scheme.  If there is a new transportation protocol, then there
is one.  Otherwise, no.
    In addition, we might consider a default namespace URI for the scheme.
3. Complete the referential range of URI so that syntactically, we can
tell if a URI denotes a URI, a Resource or a Representation.
    Syntax: my proposed syntax is:
    a) If the root URI ended with a "~", it by definition denotes the
URI without the trailing "~".
    b) Use #(mine-type) to denote a representation.
4.  Consider denoting a MIME-type with URI.
5.  Optionally, make a URI syntax to denote the set of mime-type
associated with a resource.
     Syntax: A root URI ended with a trailing "?"

I believe the above design would give us a very solid foundation for the
Web.  All important concepts, URI, Representation, Resource,
Transportation, MIME, will be grounded on URI.   Thus, we know one URN
can have multiple Information Resource (URL); and one Information
Resource can have multiple Representations.  And we communicate through
the Web by fetching the most suitable *representation* to understand the
world, which is grounded on the Web by the URN.

Don't you think that is a much better and cleaner way to solve
architectural problems?  I want to point out that all my proposed design
does not define anything semantically.  It is all driven by syntactic
conventions.  We are engineers.  Our job is to design and built "syntax
or structure" for our users to deal with their semantic issues.   It is
not our job to tell our users he or she get  "X is Y" right or not.  It
is their freedom and we have no right to take it away from them.

I may have sounded that I have been bickering about semantic issues.  
But that is not my purpose.  My purpose of doing that is only to show
how shaky a ground we will stand if we ever try to built our engineering
principles from our intuitions.  To be pragmatic, that is my purpose.

Xiaoshu


Williams, Stuart (HP Labs, Bristol) wrote:

> Xiashou,
>
>  
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> Sent: 29 June 2009 18:25
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Jonathan Rees; www-tag@...
>> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
>> Proposed Changes
>>
>> Williams, Stuart (HP Labs, Bristol) wrote:
>>    
>>> Xiaoshu,
>>>
>>>
>>>      
>>>> -----Original Message-----
>>>> From: www-tag-request@... [mailto:www-tag-request@...]
>>>> On Behalf Of Xiaoshu Wang
>>>> Sent: 28 June 2009 04:55
>>>> To: Jonathan Rees
>>>> Cc: www-tag@...
>>>> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
>>>> Proposed Changes
>>>>
>>>> Jonathan Rees wrote:
>>>>
>>>>        
>>>>> [less cc:]
>>>>>
>>>>> Tracker, I write this email primarily for you. This whole thread is
>>>>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>>>>
>>>>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>>>>> statement on recommended use of conneg, as Michael Hausenblas did in
>>>>> February [3]. I'm sorry that this has fallen to the periphery of the
>>>>> TAG business heap. The best I can do now is to point you to the advice
>>>>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>>>>> with Eran's reading.
>>>>>
>>>>>
>>>>>          
>>>> Yes.  I am pressing and I hope TAG can take it seriously.  I am not
>>>> pressing TAG to make a recommended use on conneg.  Conneg is there and
>>>> people is start using it.  I don't think AJAX community needs to ask TAG
>>>> before using conneg.  The mechanism is there, thanks to the well design
>>>> of HTTP, we can just use it.  What I am asking TAG to rethink
>>>> httpRange-14 because it will let us know how much nonsense that issue-62
>>>> as well as LRDD proposal is.  (Sorry for my bluntness, but why waste
>>>> time on propose something that you cannot even define?)
>>>>
>>>>        
>>> Specifically, what is it that you are asking the TAG to rethink?
>>>
>>>      
>> (1) The necessity for the definition of "Information Resource".
>> (1a) If TAG thinks IR is necessary, please give a concrete definition so
>> that every can be used objectively. The current definition is not a
>> definition. It is more like a wish but a definition.
>> (1b) If TAG cannot define IR, then eliminate it.
>>    
>>> The TAGs httpRange-14 resolution and subsequent contributions to
>>> the "Cool URIs for the Semantic Web" amounts to saying that:
>>>
>>> - fragment-less http URI can be used to refer-to, name... any kind of thing
>>>
>>> - and for things that do not/cannot possibly have awww:representations (and I am such a thing)
>>>   please deploy a redirection (303) to a different thing that (if the redirection is to be useful)
>>>   has something say about the thing first asked about.
>>>
>>>      
>> But *please* define the "can", whose capability in what regard?
>>    
>
> I can offer some characteristics and have done so in the past - eg. things that have mass do not/cannot possibly have awww:representations.
> Things whose state (and state history) can be serialised as a message can have awww:representations.
> Things that are entirely conceptual - eg an RDF property or class fall into a bit of a grey area.
>
> Personnally I could have lived with a resolution to httpRange-14 that allowed descriptive representations for things referenced by slash http URI and left classification of the resource (if required) to some higher level. FWIW, information/non-information resource is a bit coarse grained anyway.
>
> However, I was also persuaded by Pat's arguments about far-distant galaxies (several light years away) how on earth could they possibly be involved in any http interaction arising from an attempt to access them using a slashed' http URI to refer to them?  Even a physical body somewhat closer?
>
> AIUI the intention of web architecture is that URI are usable to access the things that they are use to name/denote/refer-to (all of which are intented to be aligned). There are things that cannot not possibly be accessed by the web - so the pragmatic thing to do (if you intent to respect that intention of web architecture) is *not* to deploy representations at the http: URI used to name those things.
>
>  
>> Is it
>> O.K. for me to 200 an HTML-representation for myself, which is a person?
>>    
>
> IMO no... it is not ok.
>
>  
>> I definitely think that I *can* but I guess you would think so. Then,
>> what is the standard of this "can or cannot" list or criteria?
>>
>> If TAG think that it is O.K. for my kind of "can", then I am fine with
>> that because it only says that the concept of "information resource"
>> varies from person to person. Else, let me know how to tell IR from
>> non-IR because, currently, to be safe (i.e., not being accused of
>> violating the web architecture), the only thing that I can do
>> is to 303 forever.
>>
>> Note, using hash-URI doesn't get me out of the predicament of  "Can I 200
>> now? because my hash URI still have to be rooted on some slash URI,
>> which IR-ness I must ponder by the httpRange-14.
>>
>>    
>>>> If we know that Information Resource does not make sense, then Generic
>>>> Resource does not make sense either because what is the definition of
>>>> this genericity?  As I have discussed in the manuscript "Is the Web a
>>>> Web of Document or Things?" (Going to be presented in IR-KR 2009,
>>>>
>>>>        
>> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all
>>    
>>>> these concepts are based on a somewhat "one resource to one representation" assumption.
>>>>
>>>>        
>>> I think I have to cry foul again here. You state repeatedly
>>>      
>> that this assumption is made in the AWWW or by the TAG and
>> then proceed to argue against it. I can assure you that I
>> know of no-one on the TAG or that contributed to the writing
>> of AWWW that makes that assumption.
>>    
>>> Maybe you are speaking here of an assumption that you make
>>>      
>> in your work, but I don't think that is the case.
>>    
>> Sure, I sincerely *wish* that I am wrong. But then it is beyond my
>> comprehension why TAG is so obsessed with IR/httpRange-14.
>>    
>
> :-) I think that the TAG has moved beyond it and that the obsession lies elsewhere.
>
>  
>> I remember
>> that a few months back TAG was even proposing IETF to 404 back some
>> documents. So, suddenly 404 isn't that bad any more, huh?
>>    
>
> Sorry... I can't ground that in anything that I'm aware of.
>
>  
>> Then, why we
>> ask people to make "cool URI"? It really sound ridiculous to me.
>>
>> It is interesting that in AWWW it says "We define the term "information
>> resource" because we observe that it is useful in discussions of Web
>> technology and may be useful in constructing specifications for
>> facilities built for use on the Web."
>>    
>
> Well... for me the distinction is between things that are:
>
> 1) material/physical things
> 2) abstract/conceptual things
> 3) information things (serialisable in a message)
>
> The only one category that gives some pause for thought is the 2nd one, such things certainly admit description, but can they have awww:representation of themselves? (I could go either way).
>
>  
>> I wonder if after so many years of debate. No one has shown even one
>> application that has benefited from using the concept of IR. It perhaps
>> is what it is -- only useful in *discussion*. Why compound people with
>> some concept that we don't even know what it is?
>>    
>>>> It is the same on "the uniform access to metadata".
>>>> What is "metadata"?  If you cannot define it, do you
>>>> honestly think that a proposal will be of any use?
>>>>
>>>> The web is built on three things: URI, Resource, Representation
>>>>
>>>>        
>>> AWWW is about those three things (and Interaction).
>>>
>>>      
>> Of course. But interaction is how the Web is implemented and realized.
>> And what a URI denote should have nothing to do with how a message is
>> retrieved by a particular protocol. Can I use a ftp-URI to denote a
>> person? I sure can, right? And then how do I 303 that? httpRange-14
>> breaks the most fundamental principle -- the principle of orthogonal
>> specification.
>>    
>
> httpRange-14 was asked and resolved in the context of HTTP URI. It has nothing to say about FTP URI.
>
>  
>>>> There is no fourth or fifth essential concepts.  Metadata, generic resource,
>>>> information resource, whatever they are must be one of the three
>>>> entities.  Thus, you have to follow the design pattern of the first
>>>> three entities and then consider what we can standardize next for a more
>>>> specific problem.
>>>>
>>>> Without solving httpRange-14,
>>>>
>>>>        
>>> What (in your view) is not solved? [You may not like the
>>>      
>> solution, but that is a different matter].
>>    
>> In my view, httpRange-14 solves no problem at all. What it does is to
>> create a problem (at least for me). And the created problem is a very
>> huge one because the semantics of 200 suddenly becomes murky.
>>    
>>> [And if you want a framing of the question, it is "What should be deployed on the web at
>>>      
>> http://example.net/people/skw where the intention is that URI
>> is used to name and to refer-to me (the person)? Further the
>> deployment should be such as to avoid the possibility of
>> confusing a reference to me as reference to a document about me."]
>>    
>> You use "http://example.net/people/skw" just as you use your name.
>> People needs to realize that what they get is a document retrieved from
>> the URI but not what the URI denotes.
>>    
>
> Ah... Well there we have it... See above... a different intention for the architecture.
>
>  
>> I have proposed to use
>> "http://example.net/people/skw#(mine-type)" to denote the document of a
>> particular mine-type retrieved from that document.
>>    
>
> I don't think that you have freedom to do that. The attribution of significance to frag ids is delegated to media-types specifications, doing what you suggest would be a big change. Practically you could do something similar in ? Space eg.
>
>         http://example.net/people/skw?mt=(mine-type)
>
> But again it would be a stretch to get universal adoption... It is little different then from a suffix based convention:
>
>         http://example.net/people/skw           names me, the person,
>         http://example.net/people/skw.about     names a document about me (and access to the former are redirected to the latter)
>
>  
>> The treatment is the
>> same whether the URI in question contains a fragment or not. Thus, if
>> you use "http://example.net/people#skw" to denote you. Then the URI
>> "http://example.net/people#(mine-type)skw" would denote a particular
>> document-fragment describing you.
>>
>> Of course, such a #(mine-type) is not absolutely needed, since we can
>> always design properties and using b-node, etc to describe it. The
>> syntax just makes it more convenient. But no matter what, what a URI
>> denotes is always up to the owner of a URI. A client retrieves
>> information and judge if s/he should accept it or not. httpRange-14
>> basically takes the ownership of URI's meaning away from its owner.
>>
>> Xiaoshu
>>    
>>>> proposing anything else is like building a
>>>> house from top and hope that all those design can consistently converge
>>>> to a solid foundation.  I don't think that is the way it works and I
>>>> don't think it can work either.
>>>>
>>>> Xiaoshu
>>>>
>>>>        
>>>>> Jonathan
>>>>>
>>>>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>>>>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>>>>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>>>>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>>>>
>>>>>          
>>> Stuart
>>> --
>>>
>>> <snip/>
>>>
>>>      
>
> Stuart
> --
>
>  

[Williams, Stuart (HP Labs, Bristol)]

Xiashou,

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: 30 June 2009 14:48
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Jonathan Rees; www-tag@...
> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
> Proposed Changes
>
> Stuart,
>
> I will answer in one block instead of paragraph by paragraph. I think
> it will be more cohesive.
>
> The Magna Carta example that Jonathan gave yesterday made me to think:
> what went wrong for this thinking "If I link to wikipedia, I want you to
> go to the wikipedia article, darnit, not to the Magna Carta."
>
> I think it is caused by the duality of a URI for being both URN and
> URL.  Here, URN is used different from other URN, such as LSID etc., I
> use the URN in an absolute sense that it is independent of any
> transportation protocol. If people understand this duality and knows
> when they are using it in which sense, I don't think that there will be
> any such confusion.  Say, let
>
> //en.wikipedia.org/wiki/Magna_Carta = Mogna_Carta
>
> Then, the wikipedia article would be denoted by
> "http:Mogna_Carta".  I doubt there will any ambiguity.
>
> 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)].

> 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.

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'.

> 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.

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.

> 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)?

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.

> 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.

> Honestly, I do not buy the "cost" argument.  I wonder what is the
> priority of TAG?  Is it to create patchy solution here and there?  Or to
> think thoroughly and tries to settle down a set of solid foundation and
> methodology before evaluating anything else?
>
> Ideally, here is the list of things I wish TAG to consider.
>
> 1.  The necessity of *one* URN.
>     URN is a URI but without a pre-defined transportation protocol.
> We use URN to describe anything in the world, just like a word
> in natural language. Syntax: my proposal is to make it an HTTP-URI sans "http:".

You understand that you here are asking for a HUGE change in the architecture of URI that would have to perculate a substantial amount of deployed infrastructre.


> 2.  The URN can be bound to any number of URL.
>     A URL denotes a (information) resource that provides information about the URN.
>     Syntax: scheme + ":" + URN.
>      Here, a scheme must correspond to a transportation protocol but not
>      naming protocol. Thus, there will be no more argument about if we need a
>      new URI scheme.  If there is a new transportation protocol,
>      then there is one.  Otherwise, no.
>     In addition, we might consider a default namespace URI for the scheme.

Again this is a HUGE change that you are asking for


> 3. Complete the referential range of URI so that syntactically, we can
> tell if a URI denotes a URI, a Resource or a Representation.
>     Syntax: my proposed syntax is:
>     a) If the root URI ended with a "~", it by definition denotes the URI without the trailing "~".
>     b) Use #(mine-type) to denote a representation.

FWIW: I take the view that in general Representations do not have URI. If you have a Representation like thing that you want to give a URI to... You have to promote it to being a Resource which then has its own Representations (which may happen to be invariant - and which may or may not be identical to the repesentation that you are tying to name). Much easier on the whole to avoid naming representations IMO.

> 4.  Consider denoting a MIME-type with URI.
> 5.  Optionally, make a URI syntax to denote the set of mime-type associated with a resource.
>      Syntax: A root URI ended with a trailing "?"
>
> I believe the above design would give us a very solid foundation for the
> Web.  

Well... It would be a different web from the one that we have. If you wanted to get there you would also need an effective transition plan - this is not a greenfield site - more brown field in some respects with movement restricted by earlier decisions.

> All important concepts, URI, Representation, Resource,
> Transportation, MIME, will be grounded on URI.   Thus, we know one URN
> can have multiple Information Resource (URL); and one Information
> Resource can have multiple Representations.  And we communicate through
> the Web by fetching the most suitable *representation* to understand the
> world, which is grounded on the Web by the URN.
>
> Don't you think that is a much better and cleaner way to solve
> architectural problems?  

Honestly... you have not sold it to me!

I think that with careful use the web as it is today works just fine.

> I want to point out that all my proposed design
> does not define anything semantically.  It is all driven by syntactic
> conventions.  We are engineers.  Our job is to design and built "syntax
> or structure" for our users to deal with their semantic issues.   It is
> not our job to tell our users he or she get  "X is Y" right or not.  It
> is their freedom and we have no right to take it away from them.
>
> I may have sounded that I have been bickering about semantic issues.  
> But that is not my purpose.  My purpose of doing that is only to show
> how shaky a ground we will stand if we ever try to built our engineering
> principles from our intuitions.  To be pragmatic, that is my purpose.
>
> Xiaoshu

Stuart
--

[Xiaoshu Wang]

Williams, Stuart (HP Labs, Bristol) wrote:

> Xiashou,
>
>  
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> Sent: 30 June 2009 14:48
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Jonathan Rees; www-tag@...
>> Subject: Re: LRDD Update (Resource Descriptor Discovery) and
>> Proposed Changes
>>
>> Stuart,
>>
>> I will answer in one block instead of paragraph by paragraph. I think
>> it will be more cohesive.
>>
>> The Magna Carta example that Jonathan gave yesterday made me to think:
>> what went wrong for this thinking "If I link to wikipedia, I want you to
>> go to the wikipedia article, darnit, not to the Magna Carta."
>>
>> I think it is caused by the duality of a URI for being both URN and
>> URL.  Here, URN is used different from other URN, such as LSID etc., I
>> use the URN in an absolute sense that it is independent of any
>> transportation protocol. If people understand this duality and knows
>> when they are using it in which sense, I don't think that there will be
>> any such confusion.  Say, let
>>
>> //en.wikipedia.org/wiki/Magna_Carta = Mogna_Carta
>>
>> Then, the wikipedia article would be denoted by
>> "http:Mogna_Carta".  I doubt there will any ambiguity.
>>
>> 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?

>> 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".
> 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".  What was this supposed *sameness*?  Define
it objectively and clearly. Otherwise, scratch it.  (Meaning is use,
please!)

As in all science and philosophy, the "reference" and "dereference" are
NOT symmetric.  Trying to make it symmetric gives rise all sort of
puzzles.  Decartes thought about it and he proclaimed "Cogito, ergo sum"
and Russel tried from logic point of view and then he got a paradox
named after him.

Don't and don't ever take that view. Communication is simple.  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.
> 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. 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.

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?
 

>> 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://... .  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?
 

>> 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.  All works is in essence a bunch
of "if elese".  If my "if" always return one result, what is the
"else"?  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.)
 

>> Honestly, I do not buy the "cost" argument.  I wonder what is the
>> priority of TAG?  Is it to create patchy solution here and there?  Or to
>> think thoroughly and tries to settle down a set of solid foundation and
>> methodology before evaluating anything else?
>>
>> Ideally, here is the list of things I wish TAG to consider.
>>
>> 1.  The necessity of *one* URN.
>>     URN is a URI but without a pre-defined transportation protocol.
>> We use URN to describe anything in the world, just like a word
>> in natural language. Syntax: my proposal is to make it an HTTP-URI sans "http:".
>>    
>
> You understand that you here are asking for a HUGE change in the architecture of URI that would have to perculate a substantial amount of deployed infrastructre.
>  

Yes.  But it also solve huge problems.  I remember the debate about the
"XRI" scheme.  I remember from the oasis site, the proposal almost
passed (I think they fell just short of 75%) even with the strong
opposition from TAG.  And then, there was the very heated debate on
HCLS-IG about LSID.  What it means to me that most people are just not
comfortable with the duality of URN and URL.  

>> 2.  The URN can be bound to any number of URL.
>>     A URL denotes a (information) resource that provides information about the URN.
>>     Syntax: scheme + ":" + URN.
>>      Here, a scheme must correspond to a transportation protocol but not
>>      naming protocol. Thus, there will be no more argument about if we need a
>>      new URI scheme.  If there is a new transportation protocol,
>>      then there is one.  Otherwise, no.
>>     In addition, we might consider a default namespace URI for the scheme.
>>    
>
> Again this is a HUGE change that you are asking for
>
>
>  
>> 3. Complete the referential range of URI so that syntactically, we can
>> tell if a URI denotes a URI, a Resource or a Representation.
>>     Syntax: my proposed syntax is:
>>     a) If the root URI ended with a "~", it by definition denotes the URI without the trailing "~".
>>     b) Use #(mine-type) to denote a representation.
>>    
>
> FWIW: I take the view that in general Representations do not have URI. If you have a Representation like thing that you want to give a URI to... You have to promote it to being a Resource which then has its own Representations (which may happen to be invariant - and which may or may not be identical to the repesentation that you are tying to name). Much easier on the whole to avoid naming representations IMO.
>  

That is why the (mine-type) is appended after the # to denote
Representation. I said in an earlier email to "Martin J. Dürst" that
this is not needed, but it is for convenience.  But a convention to
denote a URI, I do believe is a necessity because there is indeed need
to describe a URI but not the referent, as shown in XRI's usecase.

>> 4.  Consider denoting a MIME-type with URI.
>> 5.  Optionally, make a URI syntax to denote the set of mime-type associated with a resource.
>>      Syntax: A root URI ended with a trailing "?"
>>
>> I believe the above design would give us a very solid foundation for the
>> Web.  
>>    
>
> Well... It would be a different web from the one that we have. If you wanted to get there you would also need an effective transition plan - this is not a greenfield site - more brown field in some respects with movement restricted by earlier decisions.
>  

HTTP's Accept header allows extension.  It is a matter of standardizing
a token.

>> All important concepts, URI, Representation, Resource,
>> Transportation, MIME, will be grounded on URI.   Thus, we know one URN
>> can have multiple Information Resource (URL); and one Information
>> Resource can have multiple Representations.  And we communicate through
>> the Web by fetching the most suitable *representation* to understand the
>> world, which is grounded on the Web by the URN.
>>
>> Don't you think that is a much better and cleaner way to solve
>> architectural problems?  
>>    
>
> Honestly... you have not sold it to me!
>
> 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

>> I want to point out that all my proposed design
>> does not define anything semantically.  It is all driven by syntactic
>> conventions.  We are engineers.  Our job is to design and built "syntax
>> or structure" for our users to deal with their semantic issues.   It is
>> not our job to tell our users he or she get  "X is Y" right or not.  It
>> is their freedom and we have no right to take it away from them.
>>
>> I may have sounded that I have been bickering about semantic issues.  
>> But that is not my purpose.  My purpose of doing that is only to show
>> how shaky a ground we will stand if we ever try to built our engineering
>> principles from our intuitions.  To be pragmatic, that is my purpose.
>>
>> Xiaoshu
>>    
>
> Stuart
> --

[Williams, Stuart (HP Labs, Bristol)]

Xiashou,

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> 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
--

[Xiaoshu Wang]

Williams, Stuart (HP Labs, Bristol) wrote:

> Xiashou,
>
>  
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> 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...
>  

Nope.  I did not.  My wording my imply that I suggested Fielding's model
is wrong.  This is not the case.  I am simply questioning the approach
that you are using.  What Fielding has done is simply explain what is
working.  It is not the reverse that the Web runs because of his
interpretation.  What I am doing is just the same.  I am trying to find
an interpretation that gives me a peace of mind and makes my daily job
easier.

I couldn't careless about the existence of "information resource" or
not.  I am simply trying to offer a comfort to those who think so.   If
there is any umbrage, there is the one at TAG's demand for me to judge
if "x is IR" or not.  My life before that is easy but it no longer is
after that.

>>>> 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...
>  

Please, please, define the "can"!  Whose capability?  I told you that
"I" can give any awww:representation to any resource.  And 200 signals
*my* capability.  But I cannot speak for anyone-else or anything-else.  
Who or what gives the awww:representation of a web-page?  Is it the web
page itself that gives it a awww:representation? Or you, or I, he or she?

I do *not* think that a web-page can have an awww:representation by
itself.  Then, I can only 303 forever.

>>> 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!
>  

Then, what criteria to evaluate "wa-representationOf"?  Please, you
think it says anything?  Just like in a programming language, the
language itself has an object identity equivalence, same as the
equivalence of URI comparison by char by char.  All other semantic
equivalence is delegated to the programmers.  What is did in that is to
simply delegate it to the Web user to implement the
"wa-representationOf".  There is no definition.

> <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.
>  

I am asking TAG to consider.  Sure, we could built a schemeless or other
named URN. That really doesn't matter to me.  What I want is first, to
make people aware of the two sense of a HTTP-URI that is currently
used.  So people won't try to make a quibble by using tricks in natural
languages.   For instance, I have to stop Jonathan's earlier example
time and time again, just wanting him to be clear which thing, i.e., a
representation/referent that his use of "web page" is referring to.
Otherwise, there is no way the argument can proceed.

Second, we need *syntactic* difference to denote the concept that we
used quite often.  It is a matter of convenience. For instance, we do
not have to invent the word "red" to mean a particular kind of color.  
We can just do it by how it relate to other colors.  But we do it in
life because it makes our life easier.  Providing a syntactic construct
just forces a certain clarity.  You can consider it to be too rigid.  
But so does the grammar in a natural language.  The purpose is to ensure
the clarity of language use.

>>> 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!
>  

Honestly, as a person, I couldn't careless because I, as a web engineer,
know the intrinsic relation between an HTTP and HTTPS URI.  But handling
that job to an RDF reasoner and see where kind of problem it may give rise?

>> 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*).
>  
We go back to full circle.  I think anything can be *of* anything-else.  
If you think otherwise, define your "of"-ness.

I cannot help pleading Wittgenstein's principle -- "Meaning is use."  If
you think that a term will affect people's engineering practice.  Then,
please *define* it with objectivity and clarity.

If we really want the web architecture to be pragmatic, as Jonathan has
said before, I really hope that we can understand how Wittgenstein has
changed philosophy.  Let's *please* not use these all purpose term to
convey our criteria because it can be used in all purpose to either
support or against our criteria.  Let's *please* define pragmatic terms
so we will not be trapped by our linguistic ambiguity.

>>>> 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!
>  

Then that is what I propose, if we want to make the syntax of URI
syntactically complete.  Say if you are given a URI in the form of
"http://http://URN".  Then, from the default scheme URI, say
"http://example.com/scheme/http", where you will find that currently
HTTP protocol only supports one level of scheme-recursion. Meaning: the
thing still exists (if you ask the meaning of this letter word, I will
refer you to Quine) but currently there is no implementation.  That is,
you cannot write a *page* about it.  Please note, the *page* that you
are referring, w.r. to http://URN, is not the same kind of *page* w.r.
to URN.  If you only want to write the-web page but not the meta-web
page, you write it in say: http://URN2, where you make an assertion to
say "URN2 = http://URN1".  Isn't it right and clear?

>> 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.
>  

Really?  Flexible to whom?  Then, why you said that I cannot 200 back
http://example.com/aperson, which denote a person????

>>  
>>    
>>>> 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'"
>  

I got lost.  Dereference U, what-else?

Or you mean find t's description without getting any t's representation?
Then, should I say more?

>> 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.

Seriously?  See the 1999 version of RDF at
http://www.w3.org/TR/1999/PR-rdf-schema-19990303/.

> 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'.
 From where?  From the Web, you (1) dereference it or (2)
google/yahoo/bing etc.
> 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).
>  
I am not sure what it has to do with the LRDD proposal?  What LRDD
recommends is: in addition to wrap your information into the
HTTP-entity, you need to make two wraps -- one descriptive/metadata and
the other (non-)descriptive/data -- and place the former in LINK while
the latter in Entity.  I told them now I have trouble making two
separate wraps.  I want them to be clear on what I should put in the
Link bucket and what Entity? I am perhaps the numbest people in the
world.  But so far, no one has been able to demonstrate his or her acute
sense to me yet.

Xiaoshu