On Nov 4, 2010, at 13:14, Ian Davis wrote: > Hi Dave, > > On Thu, Nov 4, 2010 at 4:56 PM, David Wood <da...@3roundstones.com> wrote: >> Hi all, >> >> This is a horrible idea, for the following reasons (in my opinion and >> suitably caveated): >> >> - Some small number of people and organizations need to provide back-links >> on the Web since the Web doesn't have them. 303s provide a generic >> mechanism for that to occur. URL curation is a useful and proper activity >> on the Web, again in my opinion. > > The relationship between 303 redirection and backlinks isn't clear to > me. Can you expand?
Sure. I should have said that *PURLs and DOIs* provide a general solution to back links and use 303s. Exploitation of relationships between resources on the Web remains incomplete for an excellent reason: The very design decision that allowed the Web to scale (distribution of resource servers) removed the ability to monitor links bidirectionally (the link maintenance problem). Prior to the Web, all hypertext systems were centralized and all included back-links. Some services exist to track and retain inter-resource metadata, such as Technorati. Technorati requires a publisher to register with them so that inter-resource monitoring may be accomplished. PURLs and DOIs allow other third parties, including the general public, to provide links to arbitrary resources that may be maintained with time. If a resource that you point to moves, you just change the URL that a PURL or DOI resolves to. 303s come into the picture when the resource that you point to is not (technically, *may* not be) an information resource, but the use case is the same. > >> >> - Overloading the use of 200 (OK) for metadata creates an additional >> ambiguity in that the address of a resource is now conflated with the >> address of a resource described by metadata. > > My post addresses that case. I don't encourage people to use the same > URI for both the metadata and the thing but to link them using a new > predicate ex:isDescribedBy. I also say that you should believe the > data. If the data says the thing you dereferenced is a document then > that's what you should assume it is. If it says it's a toucan then > that's what it is. Yes, I agree that your post addresses that case. Your solution is a reasonable one and is even implementable. I've had similar thoughts in the past. However, I don't see a need to get rid of the 303 to implement your proposal. > > >> >> - W3C TAG findings such as http-range-14 are really very difficult to >> overcome socially. >> > > Maybe so, but I don't think that should stop 5 years of deployment > experience from informing a change of practice. This isn't really > relevant to my main question though: what breaks on the web. > > >> - Wide-spread mishandling of HTTP content negotiation makes it difficult if >> not impossible to rely upon. Until we can get browser vendors and server >> vendors to handle content negotiation in a reasonable way, reliance on it is >> not a realistic option. That means that there needs to be an out-of-band >> mechanism to disambiguate physical, virtual and conceptual resources on the >> Web. 303s plus http-range-14 provide enough flexibility to do that; I'm not >> convinced that overloading 200 does. > > My proposal isn't dependent on conneg. You can use it with the same > caveats as anywhere else. But the simple case is just to serve up some > RDF at the URI being dereferenced. BTW, conneg is very widely deployed > in the Linked Data web and doesn't seem to have been a problem. I agree that conneg seems to be back in favor recently. I suppose that is because we in the Linked Data community are not relying on browsers as much as the syntactic Web folks. Conneg remains a problem in browser handling. I also agree that your proposal isn't dependent on conneg. However, consider the original use cases for conneg: You could serve various representations based upon the context of a request. That is, you could serve either metadata or data (as well as format variations). In the context of this discussion, I would argue that conneg is another way to get to metadata about a resource by resolving the URL for the resource. > > >> >> /me ducks for the inevitable mud slinging this list has become. > > We can improve the quality of discussion on this list. Oh, I hope so. Let's try to do that, please :D Regards, Dave
