[
Lists Home |
Date Index |
Thread Index
]
> Seairth Jacobs scripsit:
>
> > The Resource seems to me just a convenience for the server
> > implementer, since the client can't know any more about than what it knows
> > of URIs and Representations.
>
> That model works well when you are just fetching representations for human
> or machine consumption. When you want to make *assertions*, though, you
> have a problem. Consider http://www.heritage.org/images/shakespeare.jpg .
> Now does that refer to *Shakespeare*, the playwright who was born on
> or about 1564-04-23? Or does it refer to a *picture of Shakespeare*,
> which is in JPEG format and contains 176 by 190 pixels? And if it refers
> to one of them, how does one refer to the other?
>
> It matters, because the assertions you can make about Shakespeare are
> basically totally dissimilar to those you can make about a picture of
> Shakespeare. The picture has a (human) creator; Shakespeare doesn't.
> The electronic picture was made in the 20th or 21st century; Shakespeare
> was a 16th-17th century kind of event. Shakespeare wrote in English;
> Shakespeare's picture doesn't write at all. And so on. "The map is
> not the territory."
>
> Topic maps, for all their messiness, at least get this right: for each
> assertion, you can tell whether it's about Shakespeare (a "non-addressable
> resource") or about the JPEG of Shakespeare (an "addressable resource").
> Topic maps talk about addressable resources using their URIs and a
> resourceRef element, and about non-addressable resources using some
> suitable URI and a subjectIndicatorRef element. No chance of confusion.
>
> RDF people could do this too, by only referring to addressable resources
> with URIs, and using anonymous nodes for non-addressable resources
> (with predications linking them to suitable subject-indicating URIs).
> Unfortunately, the ideology of RDF doesn't work like that, although
> technically it's feasible. TimBL, e.g., is on record as saying
> that the URI "http://www.w3.org/Consortium"; *is* the W3C for RDF purposes,
> which leaves no URI for the text that describes the W3C.
None of this convinces me. It never has. I'm sorry, but I don't believe in
unoversal identifiers. I do believe in identifiers by explicit contract, or
by convenient assumption. That means that if you decide that you mean
http://www.heritage.org/images/shakespeare.jpg
to stand for Sir W Shakespeare himself, then fine. Just make sure those you
work with agree and go along with it. But even if soemone doesn't agree and
thinks you mean the picture retrieved, there is still a good chance they can
eke out something useful from your assertions.
You claim that with subject-matter identifiers, there is no possibility of
confusion. This is pure strong AI phooey. For one thing, even people do not
necessarily share the same definition of shakespeare. In some contexts, he is
a certain someone born at Stratford Upon Avon. For others, he is merely the
august playwright of "Hamlet" and such, so that if later on the lunatic fringe
is proven right and that it was really "glorius mundi" Sir Francis Bacon who
wrote those works, then the phenomonological division is just made a tad bit
more explicit than it is already.
I still think RDF gets it right. You treat URIs like exportable identifiers.
Treat them as consistently and unambiguously as works for you. If you expose
them to others, know that all your dreams about how those URIs correspond to
real world concepts are but a vanity and a striving after nothing.
As you say, one can somewhat simulate subject matter indicators (or
identifiers or whatever they really are) by using blank nodes with
owl:unambiguousProperty, but I have no time for that trick, because I think
it's as vain as PSIs.
Bottom line: I cannot compute the real William Shakespeare. I cannot compute
the real W3C. Why, then, is it important for me to have supposedly
unambiguous identifiers for such things in my *computer* apps? Web-based
metadata systems no more need universally ambiguous identifiers than any other
computer database system does. It's strong KR types who like to make
unambiguous assertions about abstractions, and they, ah, aren't really in the
business of creating practical software.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
The open office file format - http://www-106.ibm.com/developerworks/xml/librar
y/x-think15/
Python Generators + DOM - http://www.xml.com/pub/a/2003/01/08/py-xml.html
4Suite Repository Features - https://www6.software.ibm.com/reg/devworks/dw-x4su
ite5-i/
XML class warfare - http://www.adtmag.com/article.asp?id=6965
|
