RE: Using ontologies to compare resources (WAS: The range of the HTTP dereference function)

Jonathan Borden wrote,
> This is the (in)famous resource-representation bug.
> The resource is the central node to which various properties are 
> attached. One can think of the various resource representations as 
> such properties. Triples may add other properties. What you are 
> comparing above is not two resources, directly, rather the visual 
> appearance of two resources. Consider this a property named
> "visual-appearance" or "image/jpg" (either works). So,
> " looks-like " is (I
> presume) intended to mean:
> visual-appearance-of( looks-like
> visual-appearance-of( and it works.

This is a way of removing the appearance of ambiguity in the URI, I
grant you, but it's not the only one. Which is the "central node"
and which is the property? Couldn't we just as easily say that the
URIs identify the images and that Mark is the "attached property",
hence that, looks-like


  person-pictured( == Mark Baker

I find this approach unpersuasive. It rests on picking one out of 
several possibilities as the cannonical resource associated with a 
URI, and demotes all the others to a subsidiary role, without any 
obvious criteria for making that choice. Sometimes it helps to make an 
arbitrary choice when no better grounds are available, but here I 
don't think it helps at all.

Why can't we simply say that there is no "central node" and say
instead, qua person is Mark Baker qua image looks-like qua image

where 'qua P' is a disambiguating operator taking an ambiguous URI
(which, because ambiguious, doesn't identify any particular
resource) onto an unambiguous identifier, hence onto a specific
resource. Looked at this way we could treat Accept: or Marks
stipulations about what his URIs refer to as implict qua-terms.

FWIW this 'qua' construct can be formalized ... Kit Fine did some
work on it in the late 70s and Peter Simons more recently
(unfortunately I don't have any references handy).



Received on Thursday, 28 March 2002 05:31:58 UTC