On 10/25/13 12:56 PM, Nathan Rixham wrote:
It's simpler than that and there are two quite simple issues.1) They have said they have changed from /Vol-1010/ to /Vol-1010 when they have not - as the 301 Moved Permanently to /Vol-1010/ illustrates, if they had moved URIs it would be the other way around, /Vol-1010/ would 301 to /Vol-1010. 2) Difference between web browser and rdfa base URI calculation and ambiguity of not being specific have compounded and confused the issue further. To address the situation they can just be specific, set the base of the document to be either http://ceur-ws.org/Vol-1010/ or http://ceur-ws.org/Vol-1010, if they set it to be the variant with the trailing slash, they'll find both HTML and RDFa are correct, if they set it to be variant without the trailing slash they'll find both the HTML and the RDFa have incorrect links.
Yes!
Separately, it does raise the question as to why uriburner and pyrdfa both use the input URI http://ceur-ws.org/Vol-1010 as base rather than the one instructed by the HTTP 301 redirect, namely http://ceur-ws.org/Vol-1010/ - perhaps this is an issue, or perhaps it should be left as is to encourage the good practise of explicitly saying what you mean.
Ideally, we want to encourage the "good practice" of being explicit about what's being denoted :-)
Kingsley
Best, Nathan On Fri, Oct 25, 2013 at 5:44 PM, Kingsley Idehen <[email protected]> wrote:On 10/25/13 12:03 PM, Christoph LANGE wrote:it seems the RDFa mailing list is not that active any more, as I haven't got an answer for this question for two weeks. As my question is also related to LOD publishing, let me try to ask it here. We, the publishers of CEUR-WS.org, are facing a technical issue involving RDFa and hash vs. slash URIs/URLs.What is your problem re. entity denotation? Simple rule of thumb: 1. Denote documents using URLs 2. Denote every other kind of entity using hash (as "#") based HTTP URIs. If "#" based HTTP URIs pose deployment problems, then you can consider using "/" based HTTP URIs, but you then have to take look to one of the following issues that require tweaks to your data server: 1. Use the Path component (part) of your HTTP URIs to set up regular expression pattern-friendly markers that distinguish HTTP URIs that denote documents from those that denote every other type of entity -- basically, this is what you see re. "/page/" (for description documents) and "/resource/" (for every other entity type/kind) re., DBpedia 2. Use 303 to redirect entity URIs to the document URLs that denote their descriptors (description documents). If using 303 redirection presents deployment challenges, bearing in mind latest revisions to HTTP, you can use a 200 OK instead of a 303, but you MUST place the URL of the entity descriptor (description document) in the "Location: " header of your HTTP responses i.e., use HTTP response metadata to handle the ambiguity that "/" based HTTP URIs present. In my experience with RDFa, I've found it easiest to deploy using relative hash based HTTP URIs. Links: [1] http://bit.ly/15tk1Au -- hash based Linked Data URI illustrated [2] http://bit.ly/11xnQ36 -- hashless or slash based Linked Data URI illustrated -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
-- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
