Re: Cool URIs (was: Re: Java Framework for Content Negotiation)
On 1 Jun 2010, at 19:37, Bernhard Schandl wrote: I want to throw in another question, are there currently arguments for or against the two alternatives: http://www.example.org/doc/alice.html vs http://www.example.org/doc/html/alice and the same for .rdf vs rdf/ In terms of web architecture both options are the same. But the first one has several “soft” advantages: - more idiomatic and hence easier to remember and use - more compatible with the Hierarchical URIs pattern [1] - yields an obvious URI for the generic, format-independent version of the resource (chop off the extension) Best, Richard [1] http://patterns.dataincubator.org/book/hierarchical-uris.html Best Bernhard
Re: Cool URIs (was: Re: Java Framework for Content Negotiation)
Hi, >> - serve html at http://www.example.org/doc/alice.html always >> - serve rdf/xml at http://www.example.org/doc/alice.rdf always >> >> Right? > > Correct! I want to throw in another question, are there currently arguments for or against the two alternatives: http://www.example.org/doc/alice.html vs http://www.example.org/doc/html/alice and the same for .rdf vs rdf/ Best Bernhard
Re: Cool URIs (was: Re: Java Framework for Content Negotiation)
Hi Angelo, On 31 May 2010, at 10:32, Angelo Veltens wrote: DBpedia has copied the approach from D2R Server. The person who came up with it and designed and implemented it for D2R Server is me. This was back in 2006, before the term Linked Data was even coined, so I didn't exactly have a lot of experience to rely on. With what I know today, I would never, ever again choose that approach. Use 303s if you must; but please do me a favour and add that generic document, and please do me a favour and name the different variants and rather than and . Thanks a lot for sharing your experience with me. I will follow your advice. So if i'm going to implement what is described in section 4.2. i have to - serve html at http://www.example.org/doc/alice if text/html wins content negotiation and set content-location header to http://www.example.org/doc/alice.html - serve rdf/xml at http://www.example.org/doc/alice if application/ rdf+xml wins content negotiation and set content-location header to http://www.example.org/doc/alice.rdf - serve html at http://www.example.org/doc/alice.html always - serve rdf/xml at http://www.example.org/doc/alice.rdf always Right? Correct! By the way: Is there any defined behavior for the client, what to do with the content-location information? Do Browsers take account of it? Not really. It's generally recommended to put the format-specific URIs into the Content-Location header, but I don't think that clients really use that information much (neither in Linked Data nor in other contexts where content negotiation is used). So I'd still recommend using the header, but more important is perhaps to have the format- specific URIs linked from the HTML and RDF representations, so that users of the data -- both in the RDF form and in the HTML form -- can discover a URI where they can reliably retrieve a representation in a specific format. The DBpedia guys are probably stuck with my stupid design forever because changing it now would break all sorts of links. But the thing that really kills me is how lots of newbies copy that design just because they saw it on DBpedia and therefore think that it must be good. I think the problem is not only, that dbpedia uses that design, but that it is described in many examples as a possible or even "cool" solution, e.g. http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ (one of the first documents i stumbled upon) If we want to prevent people from using that design it should be clarified that and why it is a bad choice. Yes, that's a good point. Best, Richard Kind regards and thanks for your patience, Angelo
Cool URIs (was: Re: Java Framework for Content Negotiation)
On 27.05.2010 15:51, Richard Cyganiak wrote: On 27 May 2010, at 10:47, Angelo Veltens wrote: What I am going to implement is this: http://www.w3.org/TR/cooluris/#r303uri I think, this is the way dbpedia works and it seems a good solution for me. It's the way DBpedia works, but it's by far the worst solution of the three presented in the document. DBpedia has copied the approach from D2R Server. The person who came up with it and designed and implemented it for D2R Server is me. This was back in 2006, before the term Linked Data was even coined, so I didn't exactly have a lot of experience to rely on. With what I know today, I would never, ever again choose that approach. Use 303s if you must; but please do me a favour and add that generic document, and please do me a favour and name the different variants and rather than and . Thanks a lot for sharing your experience with me. I will follow your advice. So if i'm going to implement what is described in section 4.2. i have to - serve html at http://www.example.org/doc/alice if text/html wins content negotiation and set content-location header to http://www.example.org/doc/alice.html - serve rdf/xml at http://www.example.org/doc/alice if application/rdf+xml wins content negotiation and set content-location header to http://www.example.org/doc/alice.rdf - serve html at http://www.example.org/doc/alice.html always - serve rdf/xml at http://www.example.org/doc/alice.rdf always Right? By the way: Is there any defined behavior for the client, what to do with the content-location information? Do Browsers take account of it? The DBpedia guys are probably stuck with my stupid design forever because changing it now would break all sorts of links. But the thing that really kills me is how lots of newbies copy that design just because they saw it on DBpedia and therefore think that it must be good. I think the problem is not only, that dbpedia uses that design, but that it is described in many examples as a possible or even "cool" solution, e.g. http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ (one of the first documents i stumbled upon) If we want to prevent people from using that design it should be clarified that and why it is a bad choice. Kind regards and thanks for your patience, Angelo
