W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

Re: Link: relation registry and 303

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Fri, 30 Jan 2009 09:05:37 +0000
Message-ID: <4982C2E1.8070603@musc.edu>
To: Tim Berners-Lee <timbl@w3.org>
CC: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Mark Nottingham <mnot@mnot.net>, Lisa Dusseault <lisa@osafoundation.org>



Tim Berners-Lee wrote:
>
> On 2009-01 -29, at 18:44, Jonathan Rees wrote:
>
>> Tim,
>>
>> Thanks for your comments on this, they are helpful.
>>
>> On Jan 29, 2009, at 2:39 PM, Tim Berners-Lee wrote:
>>
>>> This architectural decision has been made and the cost in time
>>> of reopening it would be huge.  Further, there is a very large
>>> number of large resources in the Linked Open Data community which use
>>> the architecture and Linked Data clients which would have problems 
>>> with an IANA site
>>> which equates a document and a property.
>>
>> Fine, but that won't matter to anyone unless they hear a convincing 
>> argument as to why respecting the httpRange-14 rule is important - 
>> what breaks? Why? What clients? (This is a genuine plea, one I've 
>> made previously, for information, not a challenge.)
>
> Well, the Tabulator even in these early stages behaves differently for 
> say people and documents. For documents, it will show you their 
> contents, and for people their friends etc.  Using the same URI for 
> both end up with things which have
>
> born: 1965-03-07
> length: 24056 bytes
> height: 1.89m
> created: 2009-01-03
>
> which is clearly no way to run a restaurant!   There is important 
> stuff about people to record, and about documents.
I wonder how this conclusion is reached.  If the conclusion is derived 
from an RDF document that says it in this way, then that is the thing 
its author intends it to be.  The receiver don't have to believe and 
accept it but s/he cannot deny the sender's intension either. On the 
other hand, if the conclusion is derived from some HTTP header code 
etc., then it is the receiver's fault.  Even if a document/IR can be 
conveyed in a byte-stream, it is NOT a byte-stream.  Hence, the above 
conclusion is due to poor implementation but the fault of web architecture.

httpRange-14, IMHO, is nothing more than a way to get hold on the 
traditional file system.  The issue is not technical but conceptual.

Xiaoshu
>
> So, if I am I adding a friend, and type an M I would like a UI to 
> offer me "Michael" and "Mary" but not "Moby Dick".  (The tabulator 
> code to discriminate isn't in yet).
>
>> httpRange-14 still encounters heavy resistance from well-informed 
>> people after four years. It needs better marketing.
>
> Maybe.  But one has to pick ones battles.  Alternatively we put our 
> effort into making the linked data world flourish, and as time goes by 
> others will write more books about it and so on, and it will  just 
> spread. 
>
> There was always with the WWW a question of whether to spend ones time 
> moving forward or arguing with skeptics. ("Gopher is so much simpler". 
> "People will get lost in hyperspace" ...) 
> What I did figure out is that it is no use crying over new apps being 
> rolled out which don't use the technology.  There is a new legacy 
> application made every few minutes,  It is painful -- one wants to say 
> -- no, wait do it with the web stuff.   But it is better to let them 
> go by, and concentrate on the people and systems that do get it, and 
> get that n^2 law going.
>
>> Some anecdotes would really help me here. The question "what concrete 
>> problem does it solve" is one I have trouble answering. I can make up 
>> stories, talk about communication friction and so on, but the 
>> abstract answers are not very convincing. I liked the bookmarking 
>> scenario you started on the call, and would like to hear more about it.
>
> It's just that if I read something interesting on the Web, I can 
> bookmark it, and email you and in general use the URI of it to refer 
> to the thing I read.  People do that so much that we can't break it to 
> say "sometimes though it will actually refer to something else". 
>
> It isn't an arbitrary choice.  When I send you the URI of a web page, 
> my expectation is that you will get the same information.  Not 
> different information about the same subject. The same page (maybe in 
> a different language) (maybe updated).  The URI identifies the 
> document, page, whatever you call it.  that's how the web works.   you 
> can argue till the cows come home about exactly what aspects of the 
> web page you expect to be invariant under different GETs, but it isn't 
> that main subject described by the page is invariant.
>
>> I don't think IANA (or Mark N) would be equating a document and a 
>> property. They are just saying that the 200 doesn't mean it's a 
>> document,
>
> So they use the URI to refer to the concept and not the document.
> This is argument 2. 
> problem with it:
> I can bookmark the page I see there and I can just use the URI for the 
> document.
>
>> and who are the TAG and the semantic web community to tell me otherwise?
>
> Well, you don't have to use semantic web technology, but when you make 
> up URIs for binary relationships, then you are in the territory and 
> should go with the consensus.  We don't mess
> with what the bits in IP packet mean, (layer below) or what the XBRL 
> financial terms mean (layer above) we just make sure the linked data 
> layer works.
>
>>> There are best practice documents such as
>>> http://www.w3.org/TR/swbp-vocab-pub/#recipe2
>>> to help developers set up web sites.
>>
>> Difficulty of execution has not been the hurdle in the conversations 
>> I've had (but I do not deny that it's an issue for some people).
>
> No, I'm sure that IANA folks can configure Apache -- just to let them 
> know we are not asking them to do anything weird and untried.  there 
> are billions of URIs (I guess, not having counted) in the Linked Open 
> data project from all kinds of sources.
>
>>> The semantic web architecture has been developed on top of the Internet
>>> architecture. (You cannot be expected to derive it from the HTTP spec.)
>>> I can imagine IANA being hesitant to adopt linked data. It took a long
>>> time for IANA to move toward publishing linked hypertext documents, 
>>> as plain text
>>> was the rule for many years.
>>
>> This is not about IANA really; it's about two engineers active in 
>> IETF who don't care, an RFC 2616 author who doesn't get it, and a TAG 
>> member who can't sell the idea.
>
> I thought it was about IANA - we need the IANA registry to serve Sem 
> Web data about concepts they register.
>
>> I'm not sure what you mean by "Internet architecture" if not what's 
>> documented in the RFCs. What am I missing?
>
> The IETF defines internet architecture, but not web arch or sem web 
> arch. They build on top of internet arch.  [This is a great 
> simplification!]  So I am saying that you should not feel that you can 
> derive the principles if the Sem Web layer by starting with the HTTP 
> spec. You cant. It doesn't make distinctions which the Sem Web layer 
> does make.
>
>
>> I have thought of starting an httpRange-14 marketing circular, but I 
>> don't know everything I need to know, even though I've been following 
>> the discussion for over two years. I would have to dig into the 
>> www-tag archives and old TAG minutes to get some idea of how we got 
>> where we are. I'm in favor both of the particular rule (as good 
>> practice) and of the principle that the decision has been made and 
>> that we should follow it, but liking the rule is no help when asking 
>> others to follow it.
>>
>> (I vote for it even though I haven't a clue what "represent" or 
>> "information resource" mean in practice, but that's another story.)
>
> I do.
>
>>> I would note that it would in fact be great for everything at IANA 
>>> to have URIs which work in the linked data world.  All kinds of 
>>> technology would benefit from having URIs for IANA concepts.
>>> It would also be a good example for governments etc all over the world.
>>>
>>> However, if not, in the meantime, while the IANA does not wish to be 
>>> compliant with the
>>> linked data architecture, one could simply replace the iana.org
>>> domain name with w3.org and run a compliant registry there.
>>> So a possibility would be for Mark's draft to replace the namespace for
>>> describedBy in this way.
>>
>> This sounds like a good compromise. I'll be interested to hear what 
>> Mark says. Putting it in W3C space has other benefits as well, such 
>> as being closer to where HTML, XHTML, RDFa, and POWDER - basically 
>> all the specs that might make use of it - are maintained. And I have 
>> found precedent for normative non-IANA URIs in RFCs (3651 and 4452), 
>> so it's not out of the question.
>>
>> (A different compromise would be for the Link: relation URI to be 
>> defined to denote/identify a document that describes the relation...)
>
>
>
>> I'm willing to believe you when you say it's just a matter of time 
>> before the world sees that sites following the httpRange-14 rule have 
>> a clear advantage over those that don't. Unfortunately my vision of 
>> what that advantage would be is rather murky. (I'm not talking about 
>> RDF or linked data, which I think will eventually come to have 
>> recognized value. I'm only talking about httpRange-14.)
>> Tim, I'm really not trying to fight it, I'm just frustrated that I 
>> don't know how to advocate for it.
>>
>
> But httpRange-14 is necessary for linked data.
>
>
>
>>> If anyone at IANA needs help figuring out how to do this, I would be 
>>> haoppy to hep,
>>> as would typically various people in irc://irc.freenode.net/swig .
>>>
>>> Tim
>>>
>> [...]
>>> Were your discussions on an archived list?
>>
>> No, sorry.
>>
>> -Jonathan
>
Received on Friday, 30 January 2009 09:06:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:11 GMT