W3C home > Mailing lists > Public > www-tag@w3.org > June 2011

Re: Issue-57

From: David Booth <david@dbooth.org>
Date: Tue, 14 Jun 2011 22:39:06 -0400
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: Jonathan Rees <jar@creativecommons.org>, Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <1308105546.2165.43371.camel@dbooth-laptop>
On Wed, 2011-06-15 at 00:49 +0100, Alan Ruttenberg wrote:
> On Tue, Jun 14, 2011 at 9:41 PM, David Booth <david@dbooth.org> wrote:
> > On Tue, 2011-06-14 at 05:05 +0100, Alan Ruttenberg wrote:
> >> On Mon, Jun 13, 2011 at 9:50 PM, David Booth <david@dbooth.org> wrote:
> >> > I do not think that is a fair characterization.  Richard's example is
> >> > *not* opting out of machine inference.  It is merely opting out of
> >> > certain inferences that *some* applications need but others do *not*
> >> > need.  And that is as it *should* be, as it is not possible to cater to
> >> > *all* applications.
> >> >
> >> > The subtle mistake that is being made repeatedly here is in assuming
> >> > that someone's data is *wrong* (or socially irresponsible) if it
> >> > conflates two things that we humans find useful to distinguish, such as
> >> > people versus web pages -- *even* if the class of applications for which
> >> > that data is intended have no need to make such a distinction!
> >>
> >> Pat has it right:
> >>
> >> On Tue, Jun 14, 2011 at 4:33 AM, Pat Hayes <phayes@ihmc.us> wrote:
> >> > Bear in mind that the very first principle of the Web is that the
> >> > *publisher* of the data, who asserts these things about dogs or
> >> > pictures of dogs, cannot possibly know what 'context of use' is
> >> > going to be relevant to the *user* of the published content
> >>
> >> http://lists.w3.org/Archives/Public/public-lod/2011Jun/0199.html
> >
> > I agree with the above comment: data publishers cannot know how their
> > data will be used.  However, that is *not* the same as saying that their
> > data must be usable in all possible applications.  Any given dataset
> > supports a particular class of applications and will be unsuitable to
> > others.  For example, a dataset that models the world as flat may be
> > fine for computing driving directions but would be unsuitable for
> > aircraft applications.
> 
> David, each time a criticism is made, the response seems to switch to
> responding to something different and not pertinent to the criticism.

Apparently what you consider pertinent differs from what I consider
pertinent.  

> Above you say:
> 
> "the class of applications for which that data is intended" = data is
> published with an application in mind. Then you say you agree with Pat
> that: "the *publisher* data, who asserts these things about dogs or
> pictures of dogs, cannot possibly know what 'context of use' is going
> to be relevant to the *user* of the published content"
> 
> These two statements are inconsistent. Either the data is published
> with the intent that it be used in some applications and not others,
> or the data is published without the user knowing the applications.

No, they're not inconsistent.  To clarify: data is generally designed
with an intent in mind, even though the publisher ultimately cannot know
how the data will actually be used.  Furthermore, the data only
*supports* a particular class of applications -- regardless of the
publisher's intent.  Does that make more sense?

> 
> The shift in response is you talking about how it isn't the case that
> "data must be usable in all possible applications" instead staying
> with the point about your statements about users aiming their data at
> certain application.

I don't understand your point.  I was pointing out the inevitability of
users aiming their data at certain kinds of applications.  I.e., it is
not possible to design a dataset that is usable in all possible
applications.

> 
> Perhaps in you will respond that there is some essential ambiguity
> that allows what you say to be inconsistent for *my application* which
> uses logic to assess whether what someone is saying is coherent, but
> is fine for *your application* which has some other goal?

No, I don't think I'll try to do that.

> 
> But the bottom line is that I don't think your arguments hold
> together, with the above sort of thing being just one example of a
> pattern I see.

Well, I've clarified the example above.  Does that help?

> 
> I come to the same conclusion about your next response. I was talking
> about Richard's set of inconsistent assertions regarding documents and
> people. You supported Richard: "Richard's example is *not* opting out
> of machine inference.....".
> 
> But then you agree with me that Richard *isn't* free to change the
> rules as he goes. Certainly uri owner for "foaf:Document" did not
> intend that it be applied to a person.

Oh, I think I see what you're talking about.  I assumed from memory that
the FOAF ontology does not define foaf:Document to be owl:disjointWith
foaf:Person.  And in checking the FOAF ontology now at
http://xmlns.com/foaf/spec/index.rdf
AFAICT my memory was correct: they are *not* defined as disjoint
classes.  

However, you seem to be reading beyond what the FOAF ontology says to
further divine the *intent* of these classes from the comments in the
documentation, such as:
http://xmlns.com/foaf/spec/#term_Person
[[
The Person class represents people. Something is a Person if it is a
person. We don't nitpic about whether they're alive, dead, real, or
imaginary.
]]
and from those informal comments, you appear to be adding an implicit
*formal* disjointness assertion that the ontology definition did *not*
make.  

That certainly is a very reasonable assertion to add, and it is one that
I would expect any application needing to distinguish between
foaf:Documents and foaf:Persons to make.  I do not know whether the FOAF
designers *intentionally* omitted this assertion -- perhaps to
facilitate the use of FOAF by applications that do not need to
distinguish foaf:Documents from foaf:Persons -- or whether it was
omitted by accident.  But AFAICT, that disjointness assertion is *not*
expressed in the formal FOAF ontology.  So I do not think it is fair to
claim that *Richard's* data is contradictory or does not support
inference just because it fails to assume an additional assertion that
the FOAF ontology did *not* make, but *you* think it should have made or
meant to make.

There are two reasons why I do not think that such informal comments
should be used in assessing whether a dataset is formally consistent.

1. They cannot be machine processed, and thus any requirement that they
be considered would not scale well.

2. Different users will interpret them differently, and this would lead
to confusion and interoperability problems.

> 
> So again I see a contradiction. And the shift to a different topic.
> First your respond about schema.org, which wasn't relevant to the
> point, as they are not a data publisher. Second you write  "HOWEVER, a
> URI declaration or definition cannot remove all possible ambiguity,
> not matter how precise or well considered it is.". But *no one at all*
> has said that document and person are defined in ambiguous enough ways
> that they might be ambiguously used to mean the other.

AFAICT, that is *exactly* how the FOAF ontology is defined, as explained
above.  Indeed, ontology experts often warn against over constraining an
ontology, as it limits its potential applications.

> 
> This pattern of discourse makes it very difficult to engage you. The
> discussion is disjointed because of these contradiction/shift moves,
> but it's distracting to have to break stride in an otherwise reasoned
> conversation to analyze and document exactly what is wrong with the
> responses.
> 
> I'm sorry this isn't a happy message, but that's my experience here.

Sorry it's been difficult, and I hope the above explanation helps to
clarify things.  And hard as it is, I think we're covering some
important ground that needs to be discussed.


-- 
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 Wednesday, 15 June 2011 02:39:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:35 GMT