Re: Distributed querying on the semantic web

On Apr 22, 2004, at 13:11, ext Jon Hanna wrote:

>
>
> Patrick Stickler quoted Phil Dawes  as saying:
>
>>> Ah - I see your point now. It's not that you don't think that having
>>> information at the URI is a bad thing, it's that you don't think it
>>> should be considered the *authoritative* description of that
>>> information.
>>> I think I agree with you here - better to let society decide what
>>> information it trusts and wants to use rather than mandating it.
>>>
>
> And then added:
>
>> Here is where I disagree.
>>
>> If I mint a term, denoted by a URI that I own, then I consider the
>> description/definition of that term that *I* give it to be the
>> authoritative description.
>>
>> Whether others respect that authoritative definition is a secondary,
>> social issue -- not a technical one.
>
> I agree with Patrick when it comes to the definiton of the URI, but 
> not when it
> comes to the description.
>
> Patrick might reasonably coin a URI to refer to the HTTP extension 
> method MGET
> in URIQA. This is reasonable, and the URI should be used to refer to 
> MGET and
> not to anything else, neither because of a mistake that could arise 
> from
> natural
> language (in natural language we could confuse it with the MGET 
> extension method
> that was proposed as a
> multiple-GET circa 1994, with URIs this should not be possibe), nor 
> because
> someone simply wants to use the same URI to denote their family recipe 
> for
> chowder. In this since Patrick is the authority, if I
> don't agree with him I am not being a good citizen.
>
> Patrick might, equally reasonably, want to describe MGET in subjective 
> terms.
> And assert that <http://domainPatrickControls/MGET> <rdf:type>
> <http://www.catb.org/~esr/jargon/html/G/Good-Thing.html> . However 
> here I don't
> necesarily agree with him. Indeed I might consider him to be a less 
> than
> objective authority, and often those who would produce the most 
> popular URIs to
> denote a given resource would have some sort of bias one way or 
> another.
>
> Of course the only way to know how a URI is defined is by reading 
> descriptions
> of it, so in practice it's hard to say where authoritative definition 
> ends and
> subjective description begins.
>

Agreed. Which is why I try to speak simply in terms of 'description' 
rather
than 'definition'. I was including the term 'definition' in recent posts
in an attempt to contextualize my response, but I can see where it may
have resulted in misrepresenting my actual position.

An authoritative description is what the authority of the denoting URI
wants to tell you about that thing, in a formal, precise manner (i.e.
in RDF).

That description may include statements which constitute some form of
definition per some use of that term. Or they may simply be subjective
information. That's really a matter of which terms are used to make 
which
particular statements -- which again feeds into the need for 
authoritative
descriptions of those other terms (which may, and likely are, from some 
other
authority than the URI denoting the thing described).

URIQA defines a mechanism by which authoritative, formal descriptions of
resources can be obtained having nothing more than the denoting URI. The
actual meaning of those descriptions, and their suitability to any 
particular
purpose, is disjunct from the functionality of the URIQA machinery 
itself,
and depends entirely on the meaning of the terms used in the 
description.

A given agent may choose to selectively prefer/rank certain kinds of
claims made by a 3rd party over those of the authority. Fine. But that
is a choice made by a particular agent. It still remains clear which
claims are authoritative and which are not, insofar as that particular
URI denoted resource is concerned.

Patrick

> -- 
> Jon Hanna
> <http://www.hackcraft.net/>
> "…it has been truly said that hackers have even more words for
> equipment failures than Yiddish has for obnoxious people." - jargon.txt
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 22 April 2004 06:35:52 UTC