Re: Computer science publisher needs help with RDFa/HTTP technical issue [Re: How are RDFa clients expected to handle 301 Moved Permanently?]

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.

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.

Best, Nathan

On Fri, Oct 25, 2013 at 5:44 PM, Kingsley Idehen <kidehen@openlinksw.com> 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
>
>
>
>
>

Received on Friday, 25 October 2013 16:57:00 UTC