Re: Schema.org in RDF ...

On Tue, 2011-06-14 at 05:17 +0100, Alan Ruttenberg wrote:
> On Mon, Jun 13, 2011 at 7:50 AM, David Booth <david@dbooth.org> wrote:
[ . . . ]
> You are making a claim about the
> necessity of ambiguity *as a fundamental principle*.  While I think
> there were some interesting things that Pat had to say about this
> issue, I am claiming that raising that issue in this context is simply
> wrong and misleading.

Okay, well apparently some see the connection and others don't.

> 
> <snip more irrelevant commentary>
> 
> > You are missing the point.  Sure, any *specific* ambiguity can be
> > avoided.  For *any* particular ambiguity it is possible to define our
> > classes in a way to avoid that *particular* kind of ambiguity.  But if
> > you focus only on fixing each particular ambiguity you'll miss the
> > forest for the trees.
> 
> You will need to more than simply assert this in order for me to be
> convinced. For instance you would need to prove to me (and the other
> readers) that disambiguating some elements *introduces* ambiguity
> elsewhere. Please demonstrate this.

I'm not claiming that at all.  The downside of disambiguation is that it
adds *complexity* (and hence cost) -- not that it creates ambiguity
elsewhere.

I am claiming:

1. Ambiguity is *relative* to the application.  Data that is unambiguous
to one application may be ambiguous to another application that requires
finer distinctions.

2. The problem of ambiguity (in general) will *always* exist because it
is *always* possible to make finer distinctions -- distinctions that are
needed by some applications but not others.

3. Disambiguation adds complexity (and hence cost).  Therefore, there is
an inevitable tendency for data producers to disambiguate *only* to the
extent required by applications they wish to support.

> 
> > It is *fallacious* to think that the ambiguity problem in general can be
> > solved by getting people to "fix" their data to be unambiguous
> 
> Once again this is off the point. There is some specific ambiguity
> that is in question here. We have agreed that there is no principle
> that says *these* ambiguities can not be avoided.
> 
> It is an entirely different issue to discuss the cost of doing this. I
> have yet to comment on that in our discussion because I wish to get
> the fallacious arguments you make out of the picture first, since they
> confuse the issue.

But cost is the *reason* for the ambiguity.

> 
> I am *very* interested in the cost/benefit issues. Let's talk about
> that without this nonsense that the problem isn't possible to fix *in
> principle*.

Sorry, but the cost issue *cannot* be separated, because it is the key
reason for the ambiguity: disambiguation *costs*.  AFAICT, that is
precisely why schema.org chose to allow this ambiguity.  The class of
applications that they chose to support did not require further
disambiguation, and they wanted to keep their model as simple as
possible.

> 
> <snip irrelevant http-range14 issues>
> 
> > I do not think it is at all misleading to point out the larger issue
> > that underlies this specific case.  On the contrary, I think it would be
> > misleading to ignore it.
> 
> It is promulgating FUD.
> 
> -Alan
> 
> 
> 

-- 
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 Tuesday, 14 June 2011 17:05:42 UTC