Re: Redefining “resource”

On 5/26/12 10:12 AM, Pat Hayes wrote:
> On May 25, 2012, at 10:40 AM, Richard Cyganiak wrote:
>
>> Hi Nathan,
>>
>> On 25 May 2012, at 15:55, Nathan wrote:
>>> Roughly, there is the set of everything named with an IRI, Set-A ("resources")
>>> then Set-B, a proper subset of Set-A, the set of all things which can be interacted with via one of the stack of network/internet protocols, including http/ftp/tor/spdy
>>> then Set-C, another proper subset of Set-A which comprises of everything else, Set-A subtract Set-B, which includes my shoes and your left ear.
>> You're contradicting yourself.
> No, he isn't.
>
>> If it has an HTTP URI, then I can, *by definition*, interact with it through the internet stack.
> No. You can REFER TO it using the internet. However, being able to name - to refer to - something is not the same as being able to interact with it. I can refer to Julius Caesar (I just did), but not I nor anyone else can interact with him, because he's been dead for two millennia. I can't GET him. I can GET sources of information about him, images of statues of him, etc., but I can't GET the actual emperor. (Similarly for the canonical example used by the W3C to make all this as clear as mud: I can't GET the weather in Oaxcala. I can get a *report* which *refers to* that weather, but I can't GET the weather itself.)
>
> Or maybe you meant something different by the phrase "it has an HTTP URI". If by "having" an HTTP URI you mean being so attached to the internet machinery that it can react to a GET request made using that URI, then yes, of course, this follows by definition. But then most things don't, and indeed cannot possibly, "have" a URI in this sense. For example, all the classes referred to by IRIs in RDFS and OWL ontologies.
>
> By the way, "Identifies", as used throughout the URI/IRI specifications and in many W3C publications, has exactly the same ambiguity: sometimes it means something like "provides a way of accessing via the Web" and sometimes it apparently means only "refers to". Often the text appears to presume that these are identical, which is a fundamental mistake I have been shouting about now for about a decade. (Several Web and internet mavens have argued for this claim directly. I call this the Earthsea confusion: the idea that things have a single True Name, and knowing this Name gives one magical power over them. It is an idea found in many fables and folklore.)
>
>> Now, RDF insists that an HTTP URI can denote anything, including your shoes and my left ear.
> Can denote, yes. Not can "identify" or "access" via HTTP, however.
>
>> Ergo, *everything* is in Set-B, and Set-C is empty. Shoes and ears are in Set-B.
> Nope, does not follow. :-)
>
>>> Personally though, I still think that Pat's suggestion of using the term "RDF Source(s)" where necessary could be used to skirt around all of this nicely, using a clear non overloaded term.
>> So, the things that REST calls resources, we should call “sources”. And everything else, we should call “resources”. That's a bit backwards.
> Indeed, but it might be the best we can do, for now. If we then try to consistently refer to things as "things", we might eventually get to a state where things are referred to, and sources are identified, and nobody talks about 'resources' any more, other than for historical reasons.
>
> Pat

Would it be clearer if one concludes the following re. identifiers:

1. RDF -- they are used for entity denotation
2. REST -- resource identification
3. Linked Data -- they denote entities that are implicitly (via 
indirection) associated with resources bearing their descriptions .

An RDF bearing Resource published to the Web is basically -- by virtue 
of mime type  and content structure -- an RDF Data Source. In addition, 
identifiers used in the RDF based content *may* also serve as RDF Data 
Source Names. In the case of Linked Data (TimBL meme variant), they are 
always Data Source Names.

Data Sources and Data Source Names are ultimately what will work. Even 
better, the same terminology is used elsewhere (e.g., RDBMS based data 
access)  in relation to the same concepts .

Kingsley
>
>> Best,
>> Richard
>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>
>


-- 

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