Lists Home |
Date Index |
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
> > 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
> 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
> > 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
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
XML class warfare - http://www.adtmag.com/article.asp?id=6965