> As this ever been discussed? I can obviously see the drawback of > having /id/ vs /id .
I think that's not a content negotiation issue, but rather a resource specification issue.
/id/ is a directory, and you're actually asking for the Directory Index. The specific resource will typically be something like /id/index.html, and be determined by the server.
/id is a specific resource -- though some servers may rewrite it to /id/ if there is such a directory and no such resource -- as yours appears to be doing.
Or have I misunderstood?
Ted
-- A: Yes. http://www.guckes.net/faq/attribution.html | Q: Are you sure? | | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon?
>> However, there is a difference when it is /id and /id/. When I dereference >> http://www.juansequeda.com/id I get a 301 (Moved Permanently) but with >> http://www.juansequeda.com/id/ I get 200 (and everything validated by >> Vapour!).
>> As this ever been discussed? I can obviously see the drawback of having >> /id/ vs /id .
> I think that's not a content negotiation issue, but rather a resource > specification issue.
I guess that is a good way to put it.. but it "appears" to be a content negotiation issue.
> /id/ is a directory, and you're actually asking for the Directory Index. > The specific resource will typically be something like /id/index.html, > and be determined by the server.
Yup. In this case, it is an index.php file
> /id is a specific resource -- though some servers may rewrite it to > /id/ if there is such a directory and no such resource -- as yours > appears to be doing.
The server does rewrite it if you put it in your browser. But if I do for example
I'm just wondering if this is something that is frown upon or something? I have always seen discussion about hash uri and 303, but not about this approach.
> -- > A: Yes. http://www.guckes.net/faq/attribution.html > | Q: Are you sure? > | | A: Because it reverses the logical flow of conversation. > | | | Q: Why is top posting frowned upon?
On Wed, Jul 15, 2009 at 8:43 AM, Juan Sequeda<juanfeder...@gmail.com> wrote: > and the objective is not to start another long philosophical thread :P and > it may be a very dumb question
Well, if it's not pseudo-code, there's a small bug in that the content-type can contain a ranked list of acceptable formats, so checking for the exact string may fail. I assume that really wasn't the point, though :-)
More on topic, I think the scenario would be:
- Install the "I (Heart) LinkedData" browser extension - Surf to http://www.juansequeda.com/id - Hit the "I like this" button
How can the extension tell if you're talking about Juan Sequeda, the person, vs the web page? Maybe I like your page and really don't like you very much at all. Or the other way 'round.
The "What do HTTP URIs Identify?" writeup seems pretty exhaustive in going through the options and the various associated compromises (I suspect this one is 2.2 "Author Definition"[1], but I could be wrong).
As you can see, your code above will not work. You really need a proper implementation of content negotiation rather than such simplistic hacks.
Vapour just checks some very simple cases. A green light from Vapour does not necessarily mean that your content negotiation works with any real client. (Unfortunately! I wish it was better at validating conneg.)
(The former header is from the any23 library in default configuration. The latter is from Safari. Note that modern RDF clients can consume several RDF syntaxes, including RDFa.)
About the "/id/" vs. "/id" thing. This behaviour is more or less hardcoded in Apache and similar web servers. After you follow the 301 redirect at "/id", you get the same 200 at "/id/". Essentially this means that "/id/" and "/id" identify the same resource, and that resource is a document.
> As you can see, your code above will not work. You really need a proper > implementation of content negotiation rather than such simplistic hacks.
> Vapour just checks some very simple cases. A green light from Vapour does > not necessarily mean that your content negotiation works with any real > client. (Unfortunately! I wish it was better at validating conneg.)
> (The former header is from the any23 library in default configuration. The > latter is from Safari. Note that modern RDF clients can consume several RDF > syntaxes, including RDFa.)
> About the "/id/" vs. "/id" thing. This behaviour is more or less hardcoded > in Apache and similar web servers. After you follow the 301 redirect at > "/id", you get the same 200 at "/id/". Essentially this means that "/id/" > and "/id" identify the same resource, and that resource is a document.
>> However, there is a difference when it is /id and /id/. When I dereference >> http://www.juansequeda.com/id I get a 301 (Moved Permanently) but with >> http://www.juansequeda.com/id/ I get 200 (and everything validated by >> Vapour!).
>> As this ever been discussed? I can obviously see the drawback of having >> /id/ >> vs /id .
It is not necessarily a good way. But if you must, a better way of doing the first line is (as in http://www.rkbexplorer.com/blog/?p=11) if (isset($_SERVER['HTTP_ACCEPT']) && strpos($_SERVER['HTTP_ACCEPT'], 'application/rdf+xml') !== false) { Now others can address the 303/# issues if they feel like it... Best Hugh
On 15/07/2009 15:16, "Christopher St John" <ckstj...@gmail.com> wrote:
On Wed, Jul 15, 2009 at 8:43 AM, Juan Sequeda<juanfeder...@gmail.com> wrote: > and the objective is not to start another long philosophical thread :P and > it may be a very dumb question
Well, if it's not pseudo-code, there's a small bug in that the content-type can contain a ranked list of acceptable formats, so checking for the exact string may fail. I assume that really wasn't the point, though :-)
More on topic, I think the scenario would be:
- Install the "I (Heart) LinkedData" browser extension - Surf to http://www.juansequeda.com/id - Hit the "I like this" button
How can the extension tell if you're talking about Juan Sequeda, the person, vs the web page? Maybe I like your page and really don't like you very much at all. Or the other way 'round.
The "What do HTTP URIs Identify?" writeup seems pretty exhaustive in going through the options and the various associated compromises (I suspect this one is 2.2 "Author Definition"[1], but I could be wrong).