RE: Proposed agenda

> From: Jonathan Rees [mailto:jar@creativecommons.org]
>
> With all due respect, regarding the memos you've directed us to, I
> don't think it will be helpful at this point to talk about the
> semantics of reference and binding in RDF.

But I think that is the heart of the IR definition problem.  I don't think the IR definition problem *can* be satisfactorily answered without looking at what we mean by reference and identity.

> . . .
> When I make say things more vaguely and generally then they ought to
> be said, I'm really trying to bait you all into fixing what I've said,

Some statements cannot be fixed without first having a slightly different way of looking at the problem.  "When did you stop beating your wife?" cannot be properly answered without first changing the question.

> . . .
> I was therefore disappointed that in talking about the 'conundrum' you
> didn't come up with your own classes - particular interpretations of
> the vague categories I listed - for comparison with a putative IR
> class. You did say we should "think about whether those entities have
> the characteristics of an IR" - that's a great idea, but then you
> didn't suggest any characteristics of an IR.

There's a good reason why I didn't: it wouldn't help.  The question is posed in a way that presumes a line of thinking that is . . . well . . . not exactly wrong in the sense of being incorrect, but wrong in the sense of going in a direction that won't shed light on the problem.  No amount of discussion of whether an IR has mass, has a dc:title, has a number of pages, has a license, has spelling errors, etc., will help.

>
> So I propose to take up your question: What are the characteristics of
> an IR?  Or more broadly, what *might* be, what *has to be*, what
> *cannot be* the characteristics of an IR?

If you believe what I've been saying about how resource identity works in semantic web architecture, then the answer is simple.  Assuming C is the set of core assertions for the definition of IR:

  Q: What *might* be an IR?
  A: Anything whose core assertions are logically consistent with C.

  Q: What *has to be* an IR?
  A: Anything whose core assertions subsume C.

  Q: What *cannot be* an IR?
  A: Anything whose core assertions are logically inconsistent with C.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

Received on Monday, 23 June 2008 13:53:16 UTC