W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2011

Re: Candidate message to TAG re httpRange-14 resolution

From: David Booth <david@dbooth.org>
Date: Mon, 31 Jan 2011 13:50:37 -0500
To: Harry Halpin <hhalpin@w3.org>
Cc: Jonathan Rees <jar@creativecommons.org>, Pat Hayes <phayes@ihmc.us>, AWWSW TF <public-awwsw@w3.org>
Message-ID: <1296499837.2070.6804.camel@dbooth-laptop>
On Mon, 2011-01-31 at 12:52 +0000, Harry Halpin wrote:
> > On Sun, Jan 30, 2011 at 10:46 PM, Pat Hayes <phayes@ihmc.us> wrote:
> >> Jonathan makes an important claim in the center of his case:
> >>
> >> "... Â because most useful
> >>>
> >>> predicates are either defined only on information resources or
> >>> undefined on information resources. Â "
> >>
> >> I wish (and once believed) that this were true, but unfortunately it is
> >> not. The most obvious example is simply a date of creation, which can
> >> apply both to a material thing (eg a date of birth) and to an
> >> information resource (eg a birth certificate.)
> >>
> >> OK, he does say 'most', but the point is that there are some important
> >> ones that this is not true of, and this is enough to rather damage the
> >> case for tolerating the ambiguity.
> >
> > Completely agree.  I was looking for a way to acknowledge the
> > existence of the argument without agreeing with it, and didn't do a
> > good job. Shall I just not mention it?
> I mean, if someone is going to make ambiguous statements, we can't stop
> them. The sensible thing to do here is to encourage people to use less
> ambiguous statements with clearer intentions, i.e. a "birthDate" vs
> "documentCreation" predicate.

I agree with this sentiment, but I also think we need to be even more
careful in how we discuss this, because ambiguity is relative: the exact
same statements may be ambiguous to one application and unambiguous to

Unless one is discussing a specific application context, I think it is
misleading to even talk about whether *statements* are ambiguous or
unambiguous, because doing so suggests that ambiguity (i.e., ambiguous
vs unambiguous) is a property of the statements themselves, and it is
not.  Ambiguity is a property of how the statements are *used*.

A creationDate property is a perfect example of this.  If the difference
between your great-great-great-great-grandfather's birth date and the
date when his birth certificate was signed is only a few days or weeks,
it may make no difference at all to an application that is merely
listing the year of his birth.  On the other hand, a different
application may show him as having multiple birth dates, and that would
be an equivalent situation to having his birth date reported twice from
independent sources: once correctly and once with a typo.

I think the best we can say is that *many* applications will find such
statements ambiguous, and encourage the use of techniques such as Harry

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Monday, 31 January 2011 18:51:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC