Re: Link: relation registry and 303

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.

Cheers,


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