RE: On intentions of Naming Authorities and Referers

> From: Williams, Stuart (HP Labs, Bristol)
>
> Some musings that I failed so stop myself writing down... they
> seem to me worth sharing... but YMMV.
>
> I have some nagging thoughts around what David would call URI
> Declarations and the intentions of two parties:
>
> - parties that act as naming authorities and bind names to things;
>   specifically URI names; even more specifically HTTP URI
>   names. Typically by arranging that an origin server response
>   when questioned with a given name (http URI). Also, by
>   creating 'anchor' points in documents which publish.

By "naming authority" I assume you mean the "URI owner", as defined in AWWW:
http://www.w3.org/TR/webarch/#def-uri-ownership

>
> - parties that make references to things using names;
>   specifically URI names; even more specifically HTTP URI
>   names. Typically by making references using URIs in
>   documents, the publication of which involves an act of naming
>   - though these parties are generally not providers of all the
>   names that they use to make references.
>
> The general question that seems to be on the table is how an
> observer of a reference (made using a URI) is to determine the
> intended referent ie. the referent intended by the publisher of
> the reference.

Yes!

>
> Though critised by Hayes and Halpin[1], the
> "follow-your-nose" philosophy of the web is that the intended
> referent of a URI name, wherever it appears, is whatever the
> naming authority for that name intended it to be a name of.

Yes.

>
> In effect the implict contract in using the web is that when a
> party creates a reference using a URI name to refer to
> something, then what the name in the reference refers to is
> whatever the naming authority for the name intends that it
> refer to (acknowledging the chorus of "...that's fine, but how
> would anyone know *what* that is?"). Thus, the question for the
> observer of a name becomes not "what did the creator of the
> reference intend it to refer to?" but "what did the naming
> authority for the name intend that it refer to?" the intention
> of web architecture being that the answer is the same in both
> cases.

The existing AWWW document does not make this "implicit contract" clear, but the architectural contract that you describe is what I have been calling the "URI declarations" approach.  It is *not* the same as the "competing definitions" approach, which essentially permits statement authors to choose the definition they wish to use for a URI that they reference.  The difference between these architectural approaches was briefly described here:
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0084.html

> The means to obtain an answer (if any) needs to
> significantly out-live the relevant authority - whose personal
> capacity to answer such repeated enquiries will diminish to
> zero overtime :-)

Not exactly.   The "URI declarations" approach degrades to the "competing definitions" approach when follow-your-nose URI definitions become unavailable or erroneous.  But it provides greater value when the f-y-n definition is available and reliable.  In other words, just because f-y-n won't always work doesn't mean that the approach doesn't have value.

>
> The GOFHTW (good old-fashioned hypertext-web) has thrived
> largely without naming authorities giving explicit expression
> to their intentions. Often (leaf-delegated) naming authorities
> do not even realise that they were acting in such a role ("I
> just put this document on the web") or that they have or had
> any obligation to make explicit statements about what they have
> published - indeed in general there has been no such obligation
> on the GOFHTW.
>
> The GOFHTW has evolved and been 'successful' without requiring
> such expression... why is that?
>
> It seems to me to have relied on the intuition of human
> consumers of references who upon 'following' a reference (a
> hyper-link) are presented with a rendering of a representation
> of (the state of?) of the referenced thing (or are redirected
> to something related to it). In the main it has not been
> neccessary to share definitive assertions about what in fact is
> being referenced - only an understanding that whatever the
> intended referent is, it is the same for each use of the same
> name, and it is the same for all observers[*] of references.
> Statements such as
> "http:/weather.example.com/Oaxaca" is a good place to look
> for information about the weather in Oaxaca can be made. Maybe
> it would be reasonable to inuit that the referenced thing is a
> source of Oaxaca weather reports - though that is left unstated
> by the naming authority.
> On the GOFHTW human consumers of
> references content themselves with their inutitions arising
> from the 'decoration' that surrounds a reference (link) and
> what they are presented with if they follow it. Many, though by
> no means all, documents on the web are self-referential and may
> provide a human and potentially a machine readable account of
> themselves, possibly amongst other things.

Agreed, for the most part.

>
> The 'things' (ie. the referents of names) of the GOFHTW are
> also the 'things' of the NFSW (new-fangled semantic web). That
> is, the NFSW is not merely layered on top of the GOFHTW, but
> intertwined with it. The intended referent of a reference made
> using a URI in a semantic web document is the same as the
> intended referent of a reference made using the same URI in a
> hypertext document (or a pdf or... ) - or at least (FWIW) I
> assert that that remains the implicit contract of using the
> web.

I agree, however the mechanism for determining the referent is different for the Semantic Web than the GOFHTW Web, as explained in
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0140.html

> Which then leads us back to the same dangling question...
> "what does (or did) the naming authority for a given name
> intend that the name refer to?".

Right.

>
> On the GOFHTW self-reference and human inuition where adequate
> for sufficiently resolving that question in most cases. In
> cases where this is insuffient, frankly, there is no reliable
> technical mechanism. One can try to ask the naming authority
> (maybe email a question to the relevant webmaster... but over
> time I'd expect a lack the knowledge and an induced loss of
> patience to prevail :-)).
>
> The naming authority could try to publish some definitive
> information about the names under their authority that might
> help. Jonathan surveys some suggested approaches for obtaining
> such descriptions at [2]); make some narrative assertions (for
> humans) or some RDF assertions (for machines
> - and some humans :-).

For URIs of Web documents, such definitive information or assertions may be considered definitive in the sense that they came from the URI owner and most users believe them.  But they cannot be architecturally considered definitive (i.e., they must not be considered core assertions of the URI's declaration -- they must be ancillary assertions), for the reason explained in
http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0003.html

> However we are in a free floating
> world of symbols grounded by symbols with, in some cases,
> symbols grounded in social documents (specifications) which
> capture some level of common social agreement (sometimes weak
> agreement!) about the intended use of particular names.
>
> I think that the best that we are likely to be able to do from
> descriptions is:
>
> - detecting when some different names are being used to
> reference the same thing (without being definitive about what
> that same thing 'is');
> - detecting when what is being said about a thing is
> inconsistent - ie. that there is no-thing for which the set of
> assertions being considered could possibly all be true.
> - infering some other things that can be deduced from what
> has been said (classifications, closures...)
>
> Of themselves these are useful things to be able to do... but
> they are way short of a machine being able to determine say,
> that the referent of a given URI is the 'actual moon'

Right, but as I point out in
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0140.html
that isn't what matters in Semantic Web architecture.  What matters is that a SWeb application is able to make useful inferences, and useful inferences are enabled by step 1 being unambiguous in the two-step mapping from the URI to its real-life referent (such as the actual moon).  To quote::
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0140.html
[[
  Step 1: Mapping from a name to something in that model, e.g., the name "x" to a particular set of assertions, or a particular memory location.

  Step 2: Mapping from the thing in the model to a real-world entity, e.g., interpreting those assertions, or that memory location, as a stand-in for an actual bank account or a particular person.
]]

Step 2 certainly matters to humans, but it is outside the control of SWeb architecture.

> 'that
> orbits' 'the earth' 'inhabited by' 'us' [all of those quoted
> strings themselves being symbols whose referents need to be
> understood in order to understand the description of the
> original referent]. Pat Hayes' by now infamous PatHayesAbout
> document[3] (oh Pat I see that you've rearranged the way [4]
> responds to accesses) is appealing in that it establishes a
> number of invariants of the person which it describes. However
> I almost failed to notice that it is replete with a number of
> other names for which no similar attempt is made - thus CYC I
> guess, by induction - and there Pat would have had me - though
> much later onced I'd had warmed to that style of description
> and sprung the trap :-)
>
> Jonathan/Alan seems to speak in terms of there being a strong
> obligation on naming authorities to give an account of what the
> names they deploy are used to refer to. They may go further to
> speak of such accounts as definitive. I believe that is at best
> hard and probably impossible.

>From a SWeb architectural perspective, such an account certainly *can* be definitive if the architecture says it is.  In SWeb architecture, URIs are used as names to denote things.  For the SWeb to best succeed, SWeb architecture can and MUST specify how the association between the URI and the thing it denotes is created.  If it doesn't, the alternative is the "competing definitions" approach, which as I point out at
http://lists.w3.org/Archives/Public/www-tag/2008Mar/0084.html
causes harmful URI collision.  One must bear in mind that this only applies to step 1 of the URI referent mapping, but that's the step that matters to SWeb apps that want to make useful inferences.

> That's not to say that descriptions are useless.
> That a particular description may be entailed in the deployment
> of a name by a naming authority (eg. by association through a
> link header or one of the other mechanisms in [2]) may lend it
> some particular weight (eg. its a "URI Declaration"), but it
> most respects it is just another description like any other
> that you might find. You still have to evaluate whether it is
> worthy of more regard than a description of the same thing
> given elsewhere.

Right.  Metadata referenced from a Resource-Description or similar header must be considered ancillary assertions rather than core assertions of the URI declaration.

>
> Regards
>
> Stuart
> --
> [1]
> http://www.ibiblio.org/hhalpin/homepage/publications/indefense
> ofambiguity.html
>    "It places the responsibility for deciding the
> relationship between referring
>     and accessing at the wrong end of the communication
> channel, that of the person
>     who hosts representations accessible at the URI, not the
> user of the URI."
> [2] http://esw.w3.org/topic/FindingResourceDescriptions
> [3] http://www.ihmc.us/users/phayes/PatHayesAbout
> [4] http://www.ihmc.us/users/phayes/PatHayes
> [*] This neglects such purtibations as might be induced by a
> change in ownership of a domain name, or the wholesale
> reorganisation of a site that results in reuse of some of the
> names therein.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.

Received on Thursday, 3 April 2008 04:49:03 UTC