W3C home > Mailing lists > Public > public-annotation@w3.org > November 2016

Re: [web-annotation] Web resources SHOULD be dereferencable via their IRI

From: gsergiu via GitHub <sysbot+gh@w3.org>
Date: Thu, 03 Nov 2016 06:32:32 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-258072380-1478154751-sysbot+gh@w3.org>
Hi @iherman,

I think that the text we have at hand, being a W3C recommendation is 
perfect to assess this issue.

1. I would like to indicate that your interpretation of the text, 
refers **to the existance of Http URIs** and not to their 
dereferenciability. 

> That is not the way I read it. Authorities MAY create a HTTP URI; 
*if* they do, then there should be an additional mechanism. But the 
operative term is 'MAY'. 

However, in the definition of the WebResource, in the WA it is already
 imposed that the Resources MUST have IRIs. Meaning that for WA it is 
a must that all Resources have IRIs (<code>@id</code>)

2. The issue that I raise is that, _in the case when we have the Http 
URIs_ for the resources (IN WA we do have IRIs for all resources), 
than by using these URIs it **SHOULD be possible to dereferenciate the
 resources** (directly or indirectly).  

And I think this is perfectly inline with the W3C recommendation:

> In addition, the URI owner SHOULD make the URI of an associated 
information resource available using the mechanism based on returning 
an HTTP response code of 303 to the original request._

3. From logical point of view, I find it quite strange to claim that 
we are developing a standard for web annotations, that are using Web 
Resources, but it is optional to be able to access these resources. 
In other words, ... do we find it perfectly OK, that when the user 
accesses the target URL, to get an 404 Response? 
(I don't find it ok) 

-- 
GitHub Notification of comment by gsergiu
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/372#issuecomment-258072380
 using your GitHub account
Received on Thursday, 3 November 2016 06:32:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC