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

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 <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
>>
>>
>>
>>
>>
>


-- 

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