Cart
[Home] [By Thread] [By Date] [Recent Entries]
I won't persist too long on this thread. I think it boils down to philosophical rather than technical issues. I've used RDF *very* heavily for the past 3 year in a lot of production work, and experimentation. I have never seen the supposed problems that are to be solved by published subject0type thingies. I have seen how the effort towards unambiguous reference complicate Topic Maps. Then again, a lot of people I respect a great deal believe that the TM machinery is essential. *shrug* to each his own. > > But even if someone doesn't agree and > > thinks you mean the picture retrieved, there is still a good chance they can > > How? Muddling up Shakespeare with a picture of Shakespeare can't possibly > make any sense. Perhaps in this example it would be harder for a processor to get along. However, I have never seen a problem of interpretation stemming from the confusion of an abstract employee (whatever that "means" to a processor) and a Web page with an employee record. > > 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. > > Whoa. I know there are problems with extensional vs. intensional definitions; > I am *not* saying that subject indicators solve every problem! I merely > say that they solve the map-territory confusion by clearly labeling each > assertion as being about the map of Shakespeare or the territory Shakespeare, > that's all. "map/territory" is complete mumbo jumbo to me, and has been every time a TM proponent has tried to explain this "confusion". For purposes of computation, if the "map" has all the data the computer needs for a particular purpose, then it doesn't matter whether or not it is actually the "territory". Again, I've not run across any practical problem that would illuminate this distinction. > BTW, did you dereference the URL yet? I just did. It's a picture of some guy. If there's a point to it, I don't gather it. > > 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. > > But that *is* the ideology of RDF, that URIs refer to Real World > (non-addressable) things. Not to me, I assure you. To me RDF subjects always refer to computer records, and I design accordingly. Maybe that's why I've had such success with it. > It's that ideology I object to, not the RDF > mechanisms at all. > > > 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. > > Well, one is no vainer than the other, at least. They both complicate the models and harm scalability. I haven't found them necessary, and I'm grateful that magic is optional in RDF. > > Bottom line: I cannot compute the real William Shakespeare. I cannot compute > > the real W3C. > > I don't know what you mean by "compute" here. I can't *compute* a letter > to my doctor either, saying I will not pay his outrageous bill, but I > can and do use a computer to produce it and file it. When I file it, > I want to classify it as being *about* my doctor, so I must have a way > to represent him within the computer. When I take on such tasks, I am classifying things according to something that my computer can process. This merely has to be a record representing the doctor for all the computer operations I plan to undertake. I have no idea why I need to have some sort of magical referent to the actual person of the doctor in my computer in order to file and classify his bill. -- 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
|
