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.

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?
 
* Lars Marius Garshol
|
| (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.)
 
* Uche Ogbuji
|
| 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.

I agree completely. (That's why I asked you to ignore that fact. :)

* Lars Marius Garshol
|
| 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.
 
* Uche Ogbuji
|
| Yes, but this is also the path to take in RDF.  

That's what I am trying to say.

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

| TM seems to have a hard-wired property for this relationship.

It does[1].

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

The identifier is the URI, the indicator the resource. It's no harder
than that.
 
| 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?

* Uche Ogbuji
|
| 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.

* Lars Marius Garshol
|
| 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.
 
* Uche Ogbuji
|
| What do you mean addresses?  I deliberately picked a non-URL URI
| above, so it doesn't address anything.  It is an identifier.

Fair enough. I did mean "identifies". Beyond that I think we agree.
 
* Lars Marius Garshol
|
| 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.
 
* 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).
 
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.

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.

* Lars Marius Garshol
|
| 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.
 
* Uche Ogbuji
|
| If not URIs, what are they?  Just arbitrary strings?

No, they are not strings at all. You could think of them as nodes in a
graph, or objects in a running program. They are just electronic
symbols with no simple string representation. (One string
representation is the <topic> element, but I don't think that's what
you were thinking of.)

One thing you may try looking at is this
<URL: http://www.ontopia.net/topicmaps/materials/proc-model.html#d1e273 >
 
| Why can't I make this distictioon between the 2 URIs in RDF, as
| well? 

You could, by making a blank node, a subject indicator property, and
then do something like:

  {blank, foo:subjectIndicator, "http://uche.ogbuji.net"}
  {"http://uche.ogbuji.net", is-written-in, "HTML"}

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

| I think that RDF, by not directly addressing the meanings of the
| things it indicates, is on safer footing.

What do you mean?
 
| 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.  

If that is the case it sounds as though we have a problem. The strange
thing is that I've been teaching topic maps for a long time now, to
people of many different backgrouns, and none of them have a hard time
getting it. Even my photographer aunt understands it.

Of course, not all of these have gone into the details of how to
represent topic maps, but still...

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

Actually, it sounds to me as if you've pretty much gotten this subject
indicator thing already, except for how they are represented in topic
maps. There really is no magic here.

[1] <URL: http://www.topicmaps.org/xtm/1.0/#elt-subjectIndicatorRef >

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >

Received on Monday, 15 April 2002 16:38:15 UTC