W3C home > Mailing lists > Public > www-tag@w3.org > January 2009

RE: "Authority" of HTTP-based Resource Descriptor

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Fri, 23 Jan 2009 10:56:41 +0000
To: David Orchard <orchard@pacificspirit.com>, Larry Masinter <masinter@adobe.com>
CC: Jonathan Rees <jar@creativecommons.org>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <233101CD2D78D64E8C6691E90030E5C8293B9D632D@GVW1120EXC.americas.hpqcorp.net>
Hello David,

+1 to what Larry said wrt to belief, trust and authority.

Web architecture doesn't prevent retrived represpresentation making assertions "...about the location of metadata on non http resources - such as mailto: URIs."

I think that the problem Eran and the OID community is interested in is given, say a mailto: URI as as an OpenID, how do I find a location for some metadata about services related to the person whose OpenID it is. For mailto: URIs one strategy that they seem to be thinking of is to extract the mailbox name, then the host dns name and ask the web server with the same dns name (via /site-meta) on the *assumption* that the 'authority' for say http://example.com is to be believed about email addresses @example.com. There is discussion around whether /site-meta at http://www.example.com  should be consulted as well in the absense of http://example.com (or as well as) and which if any should be considered authoritative (in the absolute sense that Larry mentions - and I agree that it is really a question of belief/trust rather than authority). I believe that DNS records are also been explored as an alternative means to find links to metadata about thing's whose names are rooted in the DNS.

The strategy of extracting DNS names from URIs that leverage from DNS and asking web servers that share some part of the DNS name (via /site-meta) for metadata locations can probably at best only be though of as providing hints about where useful information *might* be found. Agents visiting those locations still need to make their own evaluation on whether the information that they find there (if any) is to believed - and they would likely be wise to be skeptical (of any information which they find).

I think that there may be an assumption floating around that across URI schemes, and certainly schemes grounded in DNS in some way, that URIs with lexically identical authority fields (and/or common most significant parts - com.example. ...) have the same authority (in the sense of person, agent, legal entity indicated by the field) underwriting whatever is said in retrieval responses that use those URI. It think that such an assumption is flawed - at best it may be true in some cases, but not generally true.

In terms of something that might be a statement of web architecture (and I'm just trying this out):
    "In general the authority indicated by the authority field of a URI is scoped by the corresponding URI scheme."

So... the authority (in the sense of person...) for http://example.com and the authority for https://example.com are in general distinct - though there may be cases where they are not.

Jonathan is interested in reliable strategies for finding meta-data about anything referred to by a URI and in particular anything that is the intended referent of an htp URI. The TAG advice in the httpRange-14 resolution (amplified in http://www.w3.org/TR/cooluris) provides *a* mechanism for reaching descriptive *some* metadata for referents that are not information objects (*if* that advice is followed with the intention of making such metadata available). However, what about a uniform approach that works information objects aswell, recognising that they don't all carry their own metadata - eg. something served up as text/plain (there are probably more compelling examples of information resources that do not carry their own metadata and which for pragmatic reasons are effecitively immutable). I think these latter are the main focus of Jonathan's work.

I think that the two problems are related - and IMO in both cases the trail may lead to some 'metadata' but the basis on which an agent choses to believe or trust what it has found remain open and probably has to rely on stronger mechanisms than we have discussed so far (BTW: I am not saying that is necessarily an issue of web architecture - belief and trust is a piece of metadata obtained from the web is no different to belief and trust in any piece of information obtained from the web).


Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of David Orchard
Sent: 22 January 2009 22:34
To: Larry Masinter
Cc: Jonathan Rees; Eran Hammer-Lahav; www-tag@w3.org
Subject: Re: "Authority" of HTTP-based Resource Descriptor

I agree with Larry's position that I summarize as that link constructs could make assertions about locations of metadata.  I think that the discussion about authority and trust has grown a little too academic and we should focus on the real-world use cases.  I still fail to see how the web architecture prohibits the discovery and link constructs that Eran and Mark are working on, particularly why a retrieved representation cannot make assertions about the location of metadata on non http resources - such as mailto: URIs.

This reminds me of many of the discussions that Roy has led around representations should be consistent to ensure a consistent world-view across users, but there's nothing stopping the resource owner from serving wildly different representations for even the same URI.  It's just that if they do, they don't get the value of their users having a consistent world view.  If I see cnn.com<http://cnn.com> as always being about weather and you see cnn.com<http://cnn.com> as always being about the plant that's in your office, then cnn.com<http://cnn.com> hasn't gotten the benefit of a consistent world view.

The server gains benefit if all the metadata offered is consistent, and I don't see any reason to preclude them from making inconsistent assertions.


On Thu, Jan 22, 2009 at 2:12 PM, Larry Masinter <masinter@adobe.com<mailto:masinter@adobe.com>> wrote:
I think the problem is trying to use "authoritative" in some absolute sense, rather than being explicit that something is only "authoritative" according to some "authority".

I think it's easier if you talk about "belief" rather than "truth" when trying to design the architecture of metadata. If there's something that everyone believes, then you might be able call it "truth" (perhaps until you come across someone who isn't a true believer.) But being explicit about "belief" makes it easier to reason second-order.

"Trust" is a willingness to accept transitive belief: your trust in an authority is reflected in your willingness to believe statements made by the authority.

Link headers and Link elements are a way of an information service or information object to make assertions about the location of further assertions about that object. So if you trust the service or information object, then you might also be willing to trust its assertion that the location provided is a trustworthy source of metainformation (additional assertions).


(I'm not convinced that it's useful to try to solve these semantic problems to bring the web to its full potential, though.)

-----Original Message-----
From: www-tag-request@w3.org<mailto:www-tag-request@w3.org> [mailto:www-tag-request@w3.org<mailto:www-tag-request@w3.org>] On Behalf Of Jonathan Rees
Sent: Thursday, January 22, 2009 8:46 AM
To: Eran Hammer-Lahav
Cc: www-tag@w3.org<mailto:www-tag@w3.org>
Subject: "Authority" of HTTP-based Resource Descriptor

Thanks for doing this - it looks very good. I have a few other
comments which I'll send later.

I know you are staying away from discussion of whether the information
in a resource descriptor is "authoritative", or at least more
"authoritative" than information found through other means, and that's
probably a good thing, but I know the question will come up. Until we
have a consensus theory, I think we have to assume that the descriptor
is, in general, not authoritative, since authority is always relative
to what's being said - any particular agent can make only some
statements authoritatively. For example, a statement that a piece of
historic writing has a certain author is not up to me; my saying that
the author is so-and-so cannot be authoritative, because I can be
wrong. This is true even if I "own" a URI with which the work was
named and I make the statement naming the work using that URI. You can
choose to trust me when I say it, and you may be justified in doing
so; but that's a different phenomenon from an exercise of "authority".

The "in general" is important since particular applications, such as
OpenID, might choose to take certain bits of information found in the
descriptor to be authoritative, and that's OK. That's not the same as
saying *all* the information is authoritative.

I can't say I have a good theory of authority on the web, but in my
spare time I would like to work on one or hunt one down (if it already
exists).  BAN logic http://en.wikipedia.org/wiki/BAN_logic might be my
starting point. If anyone else has any insight let me know. For now I
wanted to make sure this caution was stated.


On Tue, Jan 13, 2009 at 1:18 PM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
> http://tools.ietf.org/html/draft-hammer-discovery-00
> I have recently published a draft for obtaining resource descriptors via HTTP using Link headers, Link elements (HTML, Atom), and Site-Meta [1]. The draft goal is to provide a unified view on how to use the three methods for obtaining information about resources (discovery). The draft invents very little (an extension to Site-Meta allowing it to describe individual resources and not just the overall site).
> Any feedback would be greatly appreciated and can be sent directly to me or discussed on the www-talk@w3.org<mailto:www-talk@w3.org> mailing list.
> Thanks,
> [1] http://tools.ietf.org/html/draft-nottingham-site-meta-00
Received on Friday, 23 January 2009 11:01:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:26 UTC