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
another.  

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
suggested.


-- 
David Booth, Ph.D.
http://dbooth.org/

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 January 2011 18:51:08 GMT