W3C home > Mailing lists > Public > public-awwsw@w3.org > December 2008

RE: statements about resources vs. representations

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Mon, 1 Dec 2008 07:53:02 +0000
To: Jonathan Rees <jar@creativecommons.org>
CC: Pat Hayes <phayes@ihmc.us>, "public-awwsw@w3.org" <public-awwsw@w3.org>
Message-ID: <CD2B872281385A439B98164F5351E6DD39C4779255@GVW1144EXB.americas.hpqcorp.net>

Hi Jonathan,

> From: Jonathan Rees [mailto:jar@creativecommons.org]
>
> On Tue, Nov 25, 2008 at 10:44 PM, Booth, David (HP Software - Boston)
> <dbooth@hp.com> wrote:
>
> > Okay, well, let's assume that "accessible" means that a
> > representation is likely to be retrievable.
>
> You have violated the cardinal rule of this group - define your terms,
> either directly or by citation. You don't say what sense of
> representation, or representation of what.

Sorry, I meant a awww:Representation of an :InformationResource (defined more fully below).

>
> >... "if there exists an :InformationResource ir with a
> > representation that was retrieved less than 24 hours ago,
> > then ir is a :AccessibleIR".
>
> define "with"

I mean that ir has yielded an awww:Representation less than 24 hours ago, in response to a GET.

>
> If :InformationResource is a new term we're defining, it can be
> defined to be anything. But we already have a set of terms
> (Accessible, AWWIR, repsentation-qua-AWWW, etc), and I want to see if
> we can make reasonable stands or refinements regarding them and
> relating them, based on what we think would be most helpful for
> communication and for engineered artifacts.

By :InformationResource, I mean *roughly* IR as defined in AWWW, but more specifically I mean ftrr:IR as defined in
http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html
(i.e., a function from (Time x Requests) to awww:Representations), because the current definition in AWWW is flawed.

>
> >> httpRange-14 permits one to use http: URIs to name things
> >> that aren't
> >> allowed by RFC 2616, but says that any 2xx-responder ought to be an
> >> AWWWIR. However, incorrect use of the http: scheme so extended can
> >> result in non-AWWWIRs that are 2xx-responders (e.g. Dublin
> >> Core URIs).
> >
> > I don't think that's quite the right perspective.  I think
> > if a GET on a URI yields a 2xx response, that is conclusive
> > evidence that the URI *does* denote an IR, regardless of
> > anything else that the URI owner may state through other means.
>
> I know you have urged people to believe this, but I do not see
> evidence that any formal document licenses this statement.

Huh?  The httpRange-14 decision itself licenses that statement:
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
It doesn't say the resource *ought* to be an information resource, it says the resource *is* an information resource.

> I know
> others in the group, including me, expressly disagree, as IMO it
> contradicts the "URI owner" section of AWWW 2.2.2.1, so please let's
> just agree to disagree and try to move on.

I certainly don't mean to annoy, but I don't think we can get to the bottom of these issues by simply agreeing to disagree.  If there is a disagreement, I want to understand *why* we disagree.  But rather than further disrupt the flow of this message, I'll follow up on that in a separate message:
http://lists.w3.org/Archives/Public/public-awwsw/2008Dec/0000.html

>
> > If the URI owner also declares through other means that the
> > URI denotes Dan's car, then there is a URI collision:
> > http://www.w3.org/TR/webarch/#URI-collision
> > Another term for URI collision is "ambiguity", for example,
> > when a single URI http://markbaker.ca/ denotes both Mark
> > Baker the person and Mark Baker's web page.  As pointed out
> > on slides 19-20 of
> > http://dbooth.org/2008/irsw/slides.ppt
> > this is architecturally identical to the problem that
> > occurs when a URI for the protein AKT is minted, and AKT is
> > later discovered to be three distinct proteins: AKT1, AKT2
> > and AKT3.  And as Pat Hayes has pointed out many times, this
> > kind of ambiguity will never be eliminated.  Fortunately,
> > such ambiguity is not a show stopper, because: (a) the
> > ambiguity may not matter to many applications; and (b) when
> > the ambiguity does matter, the ambiguous URI can be related
> > to more specific URIs, using skos:narrower.
>
> It is URIs that are ambiguous, not resources.

Correct, well, mostly.  To be more precise, it is neither the URI nor the resource that is ambiguous, it is the *mapping* from the URI to the resource that is ambiguous. Calling the URI ambiguous is a shorthand.

> I can't say that one
> person is skos:narrower than another.

Exactly.   That is why I have repeatedly stressed the need to talk about URIs and URI declarations as distinct from resources, and why it is important to have a clear model in semantic web architecture of *how* a URI denotes a resource.  Last year I started writing up how one can indicate that one URI declaration is broader than another.  Your message prompted me to fill out the draft a bit more, though it still isn't finished.  Here it is:
"Splitting Identities in Semantic Web Architecture"
http://dbooth.org/2007/splitting/
Abstract:
[[
A URI declaration that is precise enough for some applications may be considered ambiguous for other applications.  Another way to say this is that the resource identity of a URI -- the resource denoted by that URI -- may be have multiple, conflicting interpretations.  This paper explains how an ambiguous URI declaration can be related to more specific URI declarations.
]]

So instead of saying that one person is skos:narrower than another, one could say that one URI declaration is narrower than another URI declaration, such as:

    "http://example#person1"^^xsd:anyURI s:isNarrowerThan
          "http://example#person2"^^xsd:anyURI .

Of course, I am assuming here that <http://example#person1> denotes one person and <http://example#person2> denotes another.

>
> If I read Pat and Harry correctly, ambiguity means that one
> well-meaning agent can take a URI to denote one thing, and another can
> take it to denote another, and this is, SOMETIMES, either unavoidable,
> benign, or both.  (Still other agents may be formalists, and not care
> what the name denotes at all, but only what inferences can be drawn
> about them.) We can argue about that, but the main conclusion I draw
> is that whenever binding of a URI to a thing (denotation) is in
> question, you have to talk about who believes what - you have to
> compare models.  Denotation is not objective.
>
> Note that in a properly constructed ontology AKT would have a
> definition as a class, and that definition would stick. If new
> information contradicted old, that would either be the result of a
> refutable statement about biology or a refutable statement about
> curation (failure to respect a definition). Such situations are
> unavoidable, but should motivate repair efforts (this is the doctrine
> of "fallabilism").

Okay, so maybe AKT isn't an ideal example, but the point is the same.

>
> >>
> >> But all that aside... one question I have is whether the classes
> >> Edition and Accessible intersect.
> >
> > Strictly speaking, no.  But that won't stop people from
> > using the same URI to denote both.  That's the ambiguity
> > mentioned above.
>
> OK, you and Tim and I now all agree that these classes - i.e. what RFC
> 2616 calls a "resource" (which we agreed seemed to be what Pat
> considered the things that can be "accessed") and what AWWW calls an
> "information resource" - are disjoint. That's HUGE progress!
>
> Just because we don't know what kind of thing a URI denotes doesn't
> mean that some future assertion (using the vocabulary we publish, say)
> about it might not clear up the matter. If the classes are disjoint,
> and someone uses the URI one day to mean a member of one class and one
> day to mean a member of another, that is inconsistent (in the OWL
> sense) and against AWWW (which says don't use one URI to name two
> different things). The only way for someone to use a single URI to
> make statements appropriate to both classes is if the classes
> intersect.
>
> The ambiguity idea just says there may be multiple models that are all
> OK. It doesn't mean it's OK to be inconsistent.

No, I don't think that's all of what the ambiguity idea says.  In particular, I think it says that in one interpretation a resource can be *both* a person and an ftrr:IR.  Such an interpretation makes no distinction between a person and an ftrr:IR -- they are *not* disjoint classes in that interpretation.  But in another interpretation, they may well be disjoint, and hence saying that a URI denotes both a person and an ftrr:IR represents a contradiction.  For your purposes, you may only like one of those interpretations, but both are permissible in semantic web architecture.  Claiming that one is wrong is pointless.   They both may be useful in different situations, just as set of RDF that models the earth as flat may be useful in applications that compute driving directions, even though it may be useless (or "wrong") to other applications.

>
> >  - an InformationResource is essentially a function from
> > (Time x Request) to Representation; and
>
> Not an objective statement. Do you mean "information resource" in the
> AWWW sense? I don't see how you'd support that. If it's a matter of
> definition, I wish you'd use a different term, like fftr:IR (which
> would make this a definition).
>
> >  - a URI denotes a resource through a two-step mapping from
> > URI, to a set of assertions, to the resource, as described in
> > http://dbooth.org/2008/irsw/slides.ppt
>
> A set of assertions can constrain an interpretation (set of URI ->
> resource bindings) to the extent that someone might say that they know
> what the URI denotes (based on assuming the truth of the assertions).
> But it cannot dictate it. Please don't use "denotes" as if it were an
> objective fact - unless you are trying to define the term in a new way
> - in which case it would be less confusing to say so, and define a new
> term.

I don't know a better term than "denotes" for this.  Given an RDF assertion like

    :s :v <http://example#dbooth> .

to understand the assertion, one generally needs to determine what resource <http://example#dbooth> denotes, and semantic web architecture should say how that should be determined.   That is the sense in which I mean "denotes".  I do not mean to imply that there cannot be competing views about what resource the URI denotes.

>
> I don't think we need to put words in the mouths of the authors of RFC
> 2616, AWWW, or the httpRange-14 resolution. I think it's OK to do a
> modest amount of "we agree that what they probably meant was" stuff -
> this should be limited consensus.

Those documents, though very good, have flaws.  Furthermore, they do not fully specify how semantic web architecture should work.  If we're going to understand and articulate how semantic web architecture should work then we may need to correct some flaws, and we certainly need to go beyond what those documents say.

> I think it's OK to disagree, but
> only if there is some grounds in bibliography or other parts of
> reality for disagreeing - so that we can find out who's right. I think
> it's OK to recycle terms used in they see documents as long as we're
> always careful to say which definition is being used. I think it's OK
> to make recommendations on how new terms are to be used, and maybe
> even give recommendations on new ways to use a protocol such as HTTP.
> But I'm going to cry foul if someone tries to commandeer the meaning
> of a term, language, or protocol that's already defined and in use.
>
> I'll continue to be a broken record for as long as you do. I hope we
> can work out a common manner of speaking so that we can make progress
> together.

I'm sure we can.  I hope I've clarified a few things.



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

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
Received on Monday, 1 December 2008 07:53:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 1 December 2008 07:53:53 GMT