Re: silly question about rdf:about

From: "Dave Beckett" <dave.beckett@bristol.ac.uk>

> >>>Seth Russell said:
> > And while were at that, why not invent another useful property ...
> > something to mean 'preferred human friendly name' ... this would be
> > like a cyc constant, a kif term, or a rdf:label.  The thing that is
> > different between it and rdf:about (aside from the fact that it would
> > be human user friendly) is that it can change (be renamed) from time
> > to time and from system to system.  But in any given system at any
> > given time  it would be unique.  For a moment let's just call this new
> > term ':named'.   Nodes so named internally would be tied to
>>  URI like this:
> >     [:uri <http://foo/#Dog>;
> >       :named  "Doggie"].

> However, rdfs:label already exists, so why not just use that?

Because rdfs:label is not guaranteed to be a unique name for a node within
one system (or application memory storage) .. as specified above [1] ... yet
it can come from the outside world and cannot be ignored.  This is not too
unusual of a concept, CycL does it.  Such an internal name property is
useful, because then you can just scribble something to your system without
haveing to remember namespaces, URI or even include all those annoying
colons.  For example:

{Seth likes Chocolate}.

Then that can be communicated to the outside world in valid RDF\XML just
fine because it matches with the nodes inside your system where the info
below is stored:

{Seth uri "http://robustai.net/~seth#ThePerson".
  likes uri "http://robustai.net/verbs/#likes" .
  Chocolate uri "http://robustai.net/EnglishNouns#Chocolate" .}

 ...  just translate the ':named' to the URI  and output it with a
'rdf:about' .. not exactly rocket science. The obvious advantage is that we
have eliminated the kind of pedantic problems which you have warned me about
above ... disadvantages ... well I can't think of any ... can you?

Now obviously this is a API or application choice, it doesn't even need to
be a standard in RDF.


Seth Russell

Received on Sunday, 7 April 2002 15:10:30 UTC