> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format