- 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>
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 UTC