Re: Again: Anonymous Resources

From: "Lee Jonas (by way of "Ralph R. Swick" <swick@w3.org>)"
<ljonas@acm.org>

> Although this can also be viewed at a superficial level as *naming*
> anonymous resources, it can more acurately be viewed as bootstrapping XML,
> N3, SemEnglish, etc. into more abstract RDF model constructs (e.g.
instances
> of Java classes) that are not associated with a particular URI-reference.
>
> Again IMHO, serialisation is only of interest to RDF parser developers,
not
> RDF application developers.  RDF applications can fully utilise anonymous
> resources as intended in the current RDF spec, and parsers are free to use
> far simpler identifier generation schemes, as these ids don't have to be
> reproducable by them (or any other parser) in a globally unique fashion.

I'm glad to hear implementors finally saying this ... imho it cannot be said
enough .. let me hang some of my own words and terms on that concept.  RDF
applications that store knowledge (triples/quadrapules) in internal memory
(db) need some internal identification for each node (set of statements with
the same subject) for the purposes of implementing vance (see below)... my
sem (semantic memory) application will just use serial numbers.  I doubt
that any implementors will find  URIs themselves to be practical for
internal identification of nodes.  So that the URIs that come from the
outside world via RDF will probably just be stored as a property like any
other property of the node ... for example:

12345678
    uri http://robustai.net/People/#Seth ;
    email mailto:seth@robustai.net ;
    label "Seth" ;
    (is developing) SEM;
    (is soliciting collaboraton on) SEM.
123454345
    label "SEM" ;
    acronymOf "SEmantic Memory".
94876469
    label "is developing".
5834732648
    label "is soliciting collaboraton on".
3873654
    label "vance";
    description "to follow a reference to that which is referenced - ie
dereference";
    a Method.

So that whether an internal node has a uri property on it or not, is fairly
unimportant.

Seth

Received on Monday, 12 March 2001 12:36:57 UTC