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

Re: Link: relation registry and 303

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 30 Jan 2009 15:35:49 +1100
Cc: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Lisa Dusseault <lisa@osafoundation.org>
Message-Id: <906D6F3A-F031-4993-8F53-F48C9E14A622@mnot.net>
To: Tim Berners-Lee <timbl@w3.org>

FWIW -- I'm in the process of editing link-04, and consensus was  
already moving in the direction of NOT having the registered relations  
be URIs, because of the complexity that brought to interpreting  
(historically, they've been compared case-insensitively). That means  
that, to some degree, this discussion is moot.

The extension relations (i.e., non-registered) are still URIs, and as  
mentioned before, I'm happy to say that those URIs refer to documents  
describing the relations, if that will allow us to move forward.


On 30/01/2009, at 2:54 PM, 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.
> 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

Mark Nottingham     http://www.mnot.net/
Received on Friday, 30 January 2009 04:36:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:26 UTC