Re: silly question about rdf:about

> 
> * Uche Ogbuji
> | 
> | But I don't see why anyone thinks that RDF says
> | http://uche.ogbuji.net *is* the person.  I also don't see what is
> | special about a published subject identifier that makes it an
> | acceptable stand-in for the person.
> 
> You mean a published subject *indicator*. There is nothing special
> about the indicator, it's just that using it as an indicator does in
> fact solve this problem. The idea is dead simple, but it works.
> 
> Let's say that we'd like anyone to be able to make statements about
> the person "Steve Pepper" in such a way that their statements are
> mergeable, even without direct communication between them.
> 
> 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.

But what you just did is to create a URI that people can agree is a stand-in 
for SP.  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.


> There's an added benefit in that there is human-readable documentation
> of what they meant their topics to represent, but that's just a
> side-effect, really.
> 
> (Please ignore the fact that the document I referred to gives a
> different URI as the identifier. We're still figuring out how best to
> use this.)

Why should it give a different URI?  It would seem to me most useful for them 
to be the same.  This is sort of the XMLNS/RDDL approach.


> The key point here is that you use a network-retrievable resource to
> identify something that is not network-retrievable. You don't need to
> invent a new URI scheme or anything, you just make it clear that
> you're addressing not an existing resource, but something described
> *in* that resource.

Yes, but this is also the path to take in RDF.  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).  TM seems to have a 
hard-wired property for this relationship.  I won't venture to guess what it 
is, because your indicator versus identifier correction leaves me even less 
sure of what I think I understand of TM.

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.


> | If enough people agree that urn:folks:uche.ogbuji.net is an
> | acceptable published subject identifer for "Uche Ogbuji", then they
> | have already done all the work RDF needs to take advantage of this
> | in description of the person.
> 
> If you can make a URI that addresses you directly, and that everyone
> agrees addresses you, then you don't need a subject indicator, I
> agree. This is the same in RDF and topic maps.

What do you mean addresses?  I deliberately picked a non-URL URI above, so it 
doesn't address anything.  It is an identifier.


> The good thing about topic maps is that it lets us use 
> 
>   <URL: http://uche.ogbuji.net >
> 
> as a subject indicator for you, without anyone confusing the web site
> with the person. 

I still don't understand how TM performs this magic, which seems to me more a 
matter for psycology and sociology than computing.


> We know which topic represents you (the one that has this resource as
> its subject indicator), and which one that represents the web page
> (the one that has it as its subject constitutor). Note that a topic is
> not a URI, but that it can have URIs in its "subject indicator" or
> "subject constitutor" properties.

If not URIs, what are they?  Just arbitrary strings?

Why can't I make this distictioon between the 2 URIs in RDF, as well?  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.


> | I don't see that Topic Maps gains anything with this built-in
> | indirection, 
> 
> It gives us a model anyone can understand for creating global
> identifiers for things which are not network-retrievable. It avoids
> the "bad practice trap" that RDF seems to have fallen into. It makes
> it instantly clear which symbols represent network-retrievable things
> and which ones don't.

Examples of this bad practice would help my footing here.  But even if this 
bad practice turns out to be true, I think that RDF, by not directly 
addressing the meanings of the things it indicates, is on safer footing.


> | except one of the most complex data models I have ever seen for a
> | description language (puts CIM to shame, I must say).
> 
> Huh? What do you mean? What is the complexity?

I'll try to be better to avoid such comments, which might be frank and honest, 
but are probably not useful.

I have tried on 3 separate occasions now to understand TM.  I've been baffled 
each time.  The most recent was at KT, with the help of the nocturne you led, 
the XTM spec that was published at KT2001, and informal conversation.  
Discussions with Nikita brought me closest to a glimmer of understanding, but 
still only so close.  I don't know why, but this is my experience.

In contrast, I was very comfortable with my understanding of RDF within an 
hour of encountering it and reading Tim Bray's article.  My understanding of 
it has been much refined over time, of course, but the fundamental 
understanding I had in that first hour or so really hasn't changed.  I do have 
some reason to be biased towards RDF: I have co-written a lot of RDF software 
and articles.  That having been said, I think other examples prove to my own 
vanity that I'm capable of evaluating technologies on their merits rather than 
on my own interest in them.  In any case, I find TM needlessly complex, and I 
admit that this is a very unscientific finding.


-- 
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/
Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/
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 Monday, 15 April 2002 10:07:42 UTC