Re: [Fwd: xmlns, uri+name pairs or just uris..? Clarification n eeded.]

Dan Connolly wrote:
> Huh? Which text from XML-NS says anything about how the namespace
> name is used, let alone that it can't be combined with
> some other piece of information via a function that's not
> invertable?

Although non normative, the annex A suggests to use a URI/name pair for extended qnames.
Anyway, XML namespaces are designed for XML vocabularies (element names and attribute names) rather than RDF vocabularies (URI refs), and their use in RDF (primarily the non-invertible cancatenation function) seems kind of twisted to me...

> >  (b) namespaces of RDF elements *must* be the URI of the schema defining those elements. This is a restriction of XML-NS.
> Again, which text in the RDF spec says that?

     2.2. Basic RDF Syntax

    The RDF data model provides an abstract, conceptual
    framework for defining and using metadata. A concrete syntax
    is also needed for the purposes of creating and exchanging
    this metadata. This specification of RDF uses the Extensible
    Markup Language [XML] encoding as its interchange syntax.
    RDF also requires the XML namespace facility to precisely
    associate each property with the schema that defines the
    property; see Section 2.2.3., Schemas and Namespaces.

     2.2.3. Schemas and Namespaces

    A schema is the place where definitions and restrictions of usage for 
    properties are documented. In order to avoid confusion between
    independent -- and possibly conflicting -- definitions of the same 
    term, RDF uses the XML namespace facility. Namespaces are simply a way 
    to tie a specific use of a word in context to the dictionary (schema) 
    where the intended definition is to be found. In RDF, each predicate
    used in a statement must be identified with exactly one namespace, or
    schema. 

> You should be able to get some RDF statements about any
> RDF property by dereferencing its URI ()... But this is a *should*,

the problem is :

- the namespace is used to indicate the schema defining the property, which is great
- the URI of the property is constructed by concatenating its namespace URI with the element name.

This is not a 'should', by construction ("each predicate must be identified with exactly one namespace"), property URIs contain the URI of their schema.

> > What I wanted to say is:
> > although reasonable, that asumption is too strong. URIs (identifers) differ from URLs (locators) in that: they do not *always* allow to retrieve the correpsonding resource.
> 
> Huh? The following are all URLs *and* URIs:
> 
>         http://www.w3.org/2000/01/rdf-schema#
>         mid:23o49u23oi@example.org
>         uuid:23o4u2o3i4ju2o3i4ju
>         file:/etc/hosts
> 
> None of them is guaranteed to "*always* allow to retrieve
> the corresponding resource".

A URL "tells" you how to get the resource (a protocol + a server + a path) which other URIs do not. But I agree that there can always be some service to retrieve any kind of URI -- and that none guarantees the availability of the resource.


> There is no such restriction.
>         uuid:32lj4k2l3k4j23lkj23l4j
> is a perfectly good RDF property identifier.

I to-tal-ly agree, and that is the way I deeply understand RDF.
But the spec does not say so : it requires the property to have a namespace, and the namespace to be the URI of the schema. Where is the URI of the schema in uuid:32lj4k2l3k4j23lkj23l4j ? It sure is not ant prefix of the property's URI. 

The specs does not say that
 (a) a property URI dereferences to the property description,
it says that 
 (b) the namspace must dereference to the schema containing the property description, AND the property URI is constructed by concatenating the namespace with the name.

Although I first understood (a), as many RDF people I think, (b) is actually written (or at least implied). I'm not sure what the authors really meant, but I guess it needs clarification.

  Pierre-Antoine

--- Quid quid Latine dictum sit, altum viditur
    Whatever is said in Latin sounds important.

Received on Friday, 11 August 2000 04:21:39 UTC