Re: silly question about rdf:about

> 
> * Lars Marius Garshol
> |
> | What we do (did, in fact) is to publish a resource that identifies
> | "Steve Pepper", say <URL: http://psi.ontopia.net/ontopia/#4 >. Now
> | anyone who creates topics and give them this resource as a subject
> | indicator will find that their topics *do* in fact merge correctly.
> 
> * Uche Ogbuji
> | 
> | But what you just did is to create a URI that people can agree is a
> | stand-in for SP. 
> 
> Agreed.
> 
> | I fail to see how, having done this work, which is needed under
> | either TM or RDF, that RDF has any problems using this URI just as
> | effectively.
> 
> What's needed in RDF is basically an agreement where people say: yes,
> we will use blank nodes with the foo:subjectIndicator property to
> represent resources that are not network-retrievable. So far that
> hasn't happened, and so there is chaos.

You may see chaos, I and many others use RDF productively every day.  Oh well. 
 I'm sure it's the same thing with TM.  I see nothing but thick fog, but I'm 
sure you and others use it productively every day.

De gustibus non est disputandem.


> To me your response seems to say almost "it doesn't do anything except
> solve our problem, so I don't see the point of it". Isn't the fact
> that it solves your problem good enough in itself?

I have no idea what you mean.

RDF allows you to make whatever relationships between things you like, 
including the ones that TM hard-codes (unfortunately, in my opinion).  I 
happen not to use such relationships because the RDF I produce and use refers 
to computable resources, not abstract entities.

Given that I don't need this distinction that TM makes, and that I don't think 
there is any sane way to hard-code such an arcane matter, I don't see TM's 
approach as a solution for any problem from my POV, or from a global one.


> | The only difference I see is that RDF leaves the user community to
> | establish its own mappings between these abstract entities and their
> | URI tags (to pick a word). 
> 
> That's true, but people haven't agreed to do this, or even on a common
> way to do it.

My precise argument is that such is unwise and unnecessary.  If I need such a 
device, I'd like something specialized for my use, rather than some universal 
signifier/signified relationship.


> | I personally prefer the RDF approach: leaving this relationship
> | open.  The reason is that I don't think that all relationships
> | between the abstract entity and its agreed-upon URI stand-in is the
> | same in all, or even most cases.
> 
> I'm not sure what you mean by this. Could you explain?

The relationship between me, the physical person, and an agreed-upon stand-in 
URI based on my employee number in some system is, to me, quite different from 
one based on, say, a URN of country code and social security number, and I 
would use different resources or even verbal explanations to establish these 
stand-ins.  I even think that the relationship between a completely abstract 
entity, such as "love" and its URI stand-in would be quite different from the 
relationship between me and such a stand-in, which is quite different, again, 
from that between a network printer and its stand-in.

All of these, to me, call for customization and flexibility rather than 
hard-wiring and central control.


> * Uche Ogbuji
> |
> | I still don't understand how TM performs this magic, which seems to
> | me more a matter for psycology and sociology than computing.
> 
> You would understand it if you tried. It really is simplicity itself,
> but you do have to stop thinking about topic maps as if they were RDF
> (if that is indeed your problem; I don't know if it is).

Trust me: I don't think of TM as if its RDF.  TM seems to me to be an odd mix 
of computer science, epistemology, and ontology of the philosophical sort.  
You seem to claim that I haven't tried to understand it.  That is very untrue, 
but not a claim that can be argued without taking the discussion in a useless 
direction.


> Here are two topics in XTM syntax:
> 
>   <topic id="uches-site">
>     <subjectIdentity>
>       <resourceRef xlink:href="http://uche.ogbuji.net"/>
>     </subjectIdentity>
> 
>     <baseName>
>       <baseNameString>Uche's web site</baseNameString>
>     </baseName>
>   </topic>
> 
>   <topic id="uche">
>     <subjectIdentity>
>       <subjectIndicatorRef xlink:href="http://uche.ogbuji.net"/>
>     </subjectIdentity>
> 
>     <baseName>
>       <baseNameString>Uche Ogbuji</baseNameString>
>     </baseName>
>   </topic>
> 
> Now I have two topics, both of which point to your site, but in
> different ways, and therefore they also represent two different
> things. The first has topic / subjectIdentity / resourceRef, so it
> represents the resource pointed to, your web site. The second has
> topic / subjectIdentity / subjectIndicatorRef, so it represents the
> thing described in the resource pointed to, you.

This is exactly the sort of hard-coding I find apalling.  I also do not see 
one iota of how just giving the two references different types (used in a 
general sense) solves the philosophical conundrum between entity and name that 
has raged for as long as humans could communicate.

It seems you and I are talking quite different languages.


> I think what may confuse you is that in RDF the notion of an RDF node
> (symbol representing thing) and URI (symbol representing thing) is
> conflated. In topic maps there are only topics (that is, the only
> symbols representing things are topics), and topics are *not* the same
> as any URI, though they have URIs. They may *have* URIs as subject
> identifiers, subject addresses, or as the locators of occurrences,
> however, which is something different.

All this is just quiddity, and the sort of hocus-pocus that keeps me at arm's 
length from TM.  All I care about is how I can conveniently refer to and 
process the sorts of things that computers are good at.  This abstract idea of 
a topic, which seems to be an abstraction outside of computers, is of no use 
to me in any practical work.


> | One way to do so is the unambiguousProperty approach others have
> | mooted.  In practice, I find this quite unnecessary, but it's still
> | an RDF solution that handles everything I understand the TM solution
> | to do.
> 
> It does get close. If you make a sub-property of unambiguousProperty
> that has the semantics of subject indication you are pretty much
> there. The only remaining step is to get people to use it.
> 
> (This is kind of like the "you could write readably in Perl"-argument.
> Of course people could, but they don't.) 

Again, you seem to be speaking a different language here.  My point is that I 
don't find this magic with unambiguous properties necessary, so it doesn't 
matter to me whether or not RDF makes it easy or not (and I haven't seen why 
it doesn't make it easy, anyway).  No, let me correct that.  I do not want RDF 
to ever have any such matter hard-wired.

Your analogy collapses because I do find readability important in programming 
languages, which is why I use Python rather than Perl.  I'm sure that even 
Perl users wish it were more readable.  The property with which you're 
disparaging RDF, on the other hand, is one which I like, and which I think a 
lot of other RDF users like.  I suspect that it's mostly TM folks who don't 
like it, and that is of course, perfectly natural, because that is why they 
are using TM rather than RDF.


> | I think that RDF, by not directly addressing the meanings of the
> | things it indicates, is on safer footing.
> 
> What do you mean?

I mean that computers are not the place to conduct philosophy.  Let people 
express the sorts of links between identifers that make sense for their 
computing applications, and don't force everyone to treat with matters that 
baffle even the word's greatest thinkers.

Oh well, I think we've reached the stage of agreeing to disagree.  You haven't 
said anything I recognize as new to me in all your postings, and I gather I 
probably haven't either.  Neither RDF nor TM should be ends on their own, so 
the important things is that we are using whatever mechanism works best for us.


-- 
Uche Ogbuji                   Principal Consultant     Fourthought, Inc.
uche.ogbuji@fourthought.com   http://Fourthought.com   +1 720 320 2046
XML strategy, XML tools (http://4Suite.org), knowledge management
Track chair, XML/Web Services One (San Jose, Boston): 
http://www.xmlconference.com/
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk10/index.html
WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
XML, The Model Driven Architecture, and RDF @ XML Europe - 
http://www.xmleurope.com/2002/kttrack.asp#themodel

Received on Tuesday, 16 April 2002 09:05:21 UTC