W3C home > Mailing lists > Public > public-lod@w3.org > July 2013

Re: URLs in Data Working Draft

From: David Booth <david@dbooth.org>
Date: Thu, 11 Jul 2013 23:50:44 -0400
Message-ID: <51DF7D14.3070002@dbooth.org>
To: David Wood <david@3roundstones.com>
CC: Uche Ogbuji <uche@ogbuji.net>, Jeni Tennison <jeni@jenitennison.com>, public-lod <public-lod@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
:)

It is interesting how this characterization of the httpRange-14 debate 
as "angels on pinheads" so nicely parallels the exact point I have tried 
so hard and long to articulate about the ambiguity of a URI's resource 
identity: that ambiguity is *relative* to the beholder.

To some, certain distinctions are a pointless waste of time -- like 
debating the number of angels that can dance on a pin.  To others, those 
same distinctions are essential!  Important!  And must be debated to the 
end of the earth!

David


On 07/11/2013 06:20 PM, David Wood wrote:
> Hi Uche,
>
> Yes, but David Booth will reply shortly.
>
> Over to you, David!
>
> Regards,
> Dave
> --
> http://about.me/david_wood
>
>
>
> On Jul 11, 2013, at 16:28, Uche Ogbuji <uche@ogbuji.net
> <mailto:uche@ogbuji.net>> wrote:
>
>> <delurk>
>> Amen! Amen! Amen! <sing>Hallelujah!</sing>. After over a decade of
>> angels dancing on pinheads, and coming dangerously close to
>> reinventing the topic/occurrence dichotomy with httprange-14, we once
>> again find ourselves back in the untidy but happy world of common
>> sense. Well done TAG!
>> </delurk>
>>
>>
>>
>> On Thu, Jul 11, 2013 at 2:49 AM, Jeni Tennison <jeni@jenitennison.com
>> <mailto: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 <mailto:www-tag@w3.org>.
>>
>>     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/
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Uche Ogbuji http://uche.ogbuji.net <http://uche.ogbuji.net/>
>> Founding Partner, Zepheira http://zepheira.com <http://zepheira.com/>
>> http://wearekin.org <http://wearekin.org/>
>> http://www.thenervousbreakdown.com/author/uogbuji/
>> http://copia.ogbuji.net <http://copia.ogbuji.net/>
>> http://www.linkedin.com/in/ucheogbuji
>> http://twitter.com/uogbuji
>
Received on Friday, 12 July 2013 03:51:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:52 UTC