Re: URLs in Data Working Draft

On 11 July 2013 10:49, Jeni Tennison <jeni@jenitennison.com> wrote:

> Dear public-lod, RDF WG,
>
> Some of you will have seen that the First Public Working Draft of "URLs in
> Data" has been published by the TAG [1].
>
> This document is the outcome of the call for change proposals [2] for the
> TAG's 2005 decision on httpRange-14 [3].
>
> The document purposefully does not address the issue of what a URI
> 'identifies' or how to discover additional information about it (beyond
> best practice that has been documented elsewhere). It aims instead to
> clarify the circumstances in which different communities of practice may
> draw different conclusions about the content of a document on the web, and
> how to avoid this by having clear definitions for the properties you use
> when publishing data that uses URIs.
>
> For RDF and linked data, the implication is that applications should focus
> on the statements that are being asserted about a given URI in the data
> that they have (from whatever source) to determine what to do. To avoid
> misinterpretation and misuse, and particularly where there's the
> possibility of ambiguity (eg 'license' or 'creator'), vocabulary authors
> should state whether a given property applies to the content retrieved from
> the subject URI or to something that content describes.
>
> The TAG does not intend to work further on these issues in the immediate
> future, except to respond to and integrate comments on this document.
> Please send any comments on the document to www-tag@w3.org.
>

Hash URIs are exemplified once as a footnote in section 5.2.1 HTTP Responses

"When presented with a hash URL, such as
http://photo.example.com/psd/12345#comment-67890 or
http://photo.example.com/psd#me, applications can locate its content by
resolving the base URL"

My experience on the web is that it is difficult to explain to people the
value of separating documents and data using the # value, and also of
having multiple data items in a document.  For example you might have an
identity for a user, and also, a public key for authentication and
signing.  IMHO, publication of this document will make explanation that
much harder.  I can picture a scenario of a divided web where documents are
used as entities in wilful violation of TAG recommendations, and less
interoperable with standards compliant material.


>
> Cheers,
>
> Jeni
>
> [1] http://www.w3.org/TR/urls-in-data/
> [2] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
> [3] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
> --
> Jeni Tennison
> http://www.jenitennison.com/
>
>
>
>
>
>