Re: unqualified name option in GetData?

I thought that the values of properties like "label", "comment", etc.
were strictly literals, and NOT part of the namespace.

Is it more complicated than that?
============ 
Dick McCullough 
knowledge := man do identify od existent done
knowledge haspart proposition list

  ----- Original Message ----- 
  From: Rob McCool 
  To: Richard H. McCullough 
  Cc: public-rdf-tap@w3.org 
  Sent: Tuesday, January 07, 2003 5:20 PM
  Subject: Re: unqualified name option in GetData?


  > Does your GetData program have an option to display, e.g.,
  >     Person
  > instead of 
  >     http://tap.stanford.edu/data/Person

  You've discovered a bug that I haven't figured out a good way to fix. Guess
  now I'll have to.

  The problem is this. When the parser loads a KB, it discards the URLs in 
  front of resources like http://tap.stanford.edu/data/Person to save space.
  When returning data, the toolkit will put the URL back again if it decides
  that "Person" is a resource and not just some string.

  The problem comes when the resource name without the namespace prefix is
  the same as one of its properties. Like:
     <rdf:Description rdf:about="http://tap.stanford.edu/data/Person">
      <rdfs:label xml:lang="en">Person</rdfs:label>
     </rdf:Description>

  The toolkit looks at the target (the second Person), tries to decide if it's
  a resource (does it have properties? Yes, a property called "label") and then
  puts the namespace back on.

  So there's a hack in my programs right now that looks a lot like this in Perl:

  sub getLabel {
    my ($tap, $tapns, $node) = @_;
    my $label = $tap->GetValue($node, "label");
    $label =~ s%^$tapns%%;
    return $label;
  }

  You can imagine a similarly revolting hack in Java involving startsWith() and
  substring().

  Now that I've been caught in my laziness, I'll have to go fix the problem 
  for real...