Re: "Authority" of HTTP-based Resource Descriptor

Yes, this is a good recap of what I was trying to say, and what BAN
logic is about.

The notion of "authority" comes up repeatedly in architecture
discussions. I don't think anyone confuses it with belief or truth, or
misses the idea that authority needs to be granted and recognized.
What I've noticed, though, is lack of clarity over the meaning and
bounds of authority. For example, it is easy to talk about authority
over a resource or a URI. But in BAN logic this way of speaking would
be a type error, as authority only relates to statements, not things.
I have the authority to designate a public key for myself (authority
over the statement "my public key is K"); I have the authority to give
someone access my bank account (authority to say "X can be given
access to my account"). The key is that there is a bound on the
authority, usually relating to the rights of a legal entity, and
sometimes we lose sight of what that bound is. Only "authorized"
statements can be "authoritative".

(IIRC BAN logic has as an axiom that if you believe Joe has authority
(jurisdiction) over a statement S, and Joe says S, then you should
believe S.)

I think "authoritative metadata" is potentially a dangerous and
confusing term.  You can't take a file full of metadata and say it is
"authoritative" (is said by someone who has authority over it) unless
you have reason to think that every statement in the file is indeed
something that X has authority over.

I think "authoritative metadata" has to be broken down into a few cases:

1. The metadata is written in a stylized language that only allows the
expression of statements that the source of the metadata has authority
over. HTTP headers might have that form (although Link: will become an
exception when it's deployed, and all of the others would have to be
checked). I have the TAG's "authoritative metadata" finding in mind
here.

2. The metadata is arbitrarily expressive, so each statement must be
analyzed ahead of time to see if the source has authority over it,
before distinguishing the 'authoritative' statements from the others.
(For a book, metadata said by the publisher may be authoritative for
the choice of title, but not the choice of author.) In this case it's
not that (all of) the metadata is authoritative, but that the metadata
speaks for someone and therefore those statements for which that
someone has authority are authoritative. I have RDF "follow your nose"
in mind here.

3. Instead of saying "the metadata is authoritative", which is very
likely to be wrong, we should have said, as you suggest, "the
statement 'description resource DR speaks for URI U's owner' is
authoritative" ("speaks for" is Lampsonese, from a followon report to
the BAN logic paper). If you believe that, then we go back to case 2,
and consider each statement, presumably made by or allowed by the URI
owner, to see if it is authoritative.

In cases 2 and 3 the important thing is not that the metadata is
authoritative, but that it is authenticated (believed to be speaking
for the right party) and therefore has the *potential* to carry
authoritative statements. Whether this is true or not is another
story, of course.

(Note that this analysis links description resources to URIs via the
URI owner, not directly to resources, and I think this is a more
accurate way to look at it. The URI gives a way (flawed perhaps) of
attributing the DR to a principal. Without the URI you would have to
find a different way to authenticate a DR - and you may have to do
this anyhow, if you have any doubts about the provenance of your
GETs.)

If you think this is a non-problem, the burden is on me to dredge up
examples of dubious usage, which I haven't done yet. I guess AWWW is
clear on exactly what statements "URI ownership" makes authoritative
(those that say the URI is associated with a resource, etc), but it's
easy for me to imagine confusion about whether other statements
written by the URI owner about the URI or what it names are
authoritative. I'm just saying what should be obvious: some are, some
aren't, and you have to be careful.

Jonathan

On Thu, Jan 22, 2009 at 5:12 PM, Larry Masinter <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).
>
> Larry
> --
> http://larry.masinter.net
>
> (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] On Behalf Of Jonathan Rees
> Sent: Thursday, January 22, 2009 8:46 AM
> To: Eran Hammer-Lahav
> Cc: 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.
>
> Best
> Jonathan
>
> On Tue, Jan 13, 2009 at 1:18 PM, Eran Hammer-Lahav <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 mailing list.
>>
>> Thanks,
>>
>> EHL
>>
>> [1] http://tools.ietf.org/html/draft-nottingham-site-meta-00
>>
>>
>
>

Received on Friday, 23 January 2009 17:06:08 UTC