OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] many-to-many

[ 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 

> > 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 
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
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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS