Re: the hash sign

The root problem is that it isn't clean to use the same URI for 2 different
things:

- assign a worldwide-unique-forever name to a Schema ;
- indicate a site where at one time the source of this Schema could have been
found (and maybe still now) .

The general problem problem of specifying a mechanism to link these different
things is an very general Web+XML issue; it is shure been worked on (maybe
XLink, or trusted sites offering queries from Schema URI to active URL having
the corresponding source of this Schema ).

For the present, I find Perry's compromise recommendation quite reasonable.

I will add an architectural argument to Perry's .

It is the processor's responsability to read, cache, and maintain somehow a
connection with the latest appropriate version of  a given schema.

I can imagine the following scenario:
1.  - the application reads RDF data at URL http://somesite.org/data.rdf , which
refers to RDF Schema at http://mysite.org/schema/ ;
2. - days later,  the application reads RDF data at URL
http://someOtherSite.org/data.rdf , which refers again to same RDF Schema; alas
this Schema is no more available (server down); the cached Schema is used
3. - days later,  the application reads RDF data at URL
http://yetSomeOtherSite.org/data.rdf , which refers again to same RDF Schema;
this Schema is still  unavailable at http://mysite.org/schema/ ; but this time
an alternate URL adress is provided by an RDF:Alt element. This allows to update
the link beetwen Schema name and Schema source, and to reconstruct the cache for
this Schema in case it had been cleared.

Hey, browser folks,  are you listening?


"Perry A. Caro" a écrit :

> The decision to use a URL for a namespace/schema needs to be made
> carefully.  There are essentially two schools of thought.
>
> One school believes that it is very useful for a namespace/schema ID to be a
> real URL, ...
>
> The other school believes that there are many practical problems to using
> URLs in this way, ...
> clients may not always be wired, or the server may be down, ...
>
> The recommendation I've been making is to use a URI that could be
> interpreted as a URL, but to make no promise that the resource at the other
> end will ever materialize. ...

> making it clear that no client should ever depend on a real resource being at
> the other end.

> Perry

--
<person>
  <first_name>Jean-Marc</first_name>
  <name>Vanel</name>
  <project>Worlwide Botanical Knowledge Base -
      making botany available on Internet
    <a href="http://wwbota.free.fr/" >site</a>
  </project>
  <a href="mailto:jmvanel@free.fr">mail</a>
</person>

Received on Sunday, 13 February 2000 13:19:50 UTC