[
Lists Home |
Date Index |
Thread 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
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
|
