W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2002

Re: refining closure text for rdfs-isDefinedBy-semantics

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 07 Jun 2002 19:15:35 +0300
To: ext Dan Brickley <danbri@w3.org>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B926B6D7.16564%patrick.stickler@nokia.com>

On 2002-06-07 16:56, "ext Dan Brickley" <danbri@w3.org> wrote:

I ask in advance for folks to forgive what might be percieved as
a strong tone to the following comments, but I have alot of
concerns and thoughts about this, as it touches upon several related
issues such as the significance/role of qnames and namespaces
in RDF. I hope my comments are at least clear.

> On Fri, 24 May 2002, Dan Brickley wrote:
>> I raised some minor concerns with this.
>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002May/0030.html
> ...and subsequent telecon discussion and some huge mailing list threads on
> www-rdf-interest and dc-architecture suggest there is further need for
> clarification.
> I fear this could drag on, and propose we stick with a solution based
> on the design from Model and Syntax REC and the RDF Schema CR.
> This would go as follows:
> First, background context and constraints on our options:
> http://www.w3.org/TR/REC-rdf-syntax/#usage
> C.2. Namespace URIs
> [[
> RDF uses the proposed XML namespace mechanism to implement globally
> unique identifiers for all properties.

OK so far.

> In addition, the namespace name
> serves as the identifier for the corresponding RDF schema.

I disagree. This presumes that

1. Namespaces are significant in the RDF model, which they
are not. Qnames are simply a way to shoehorn URIs into
element and attribute names, no more.

2. A given term is defined only by one RDF schema instance,
which is IMO contrary to the combinatoric nature of RDF,
as well as precludes common and expected practice of
making statements about resources by mulitple sources.

Practical example, language-specific RDF schemas defining
labels for resources, managed as separate individual
RDF/XML instances with their own URI identity that does
not equate to any namespace.

Furthermore, stating that a namespace URI denotes an RDF/XML
instance seems to contradict the RDF MT which imposes an N:1
relation between URIs and resources. If a namespace denotes
anything, it denotes the collection of terms grounded in
that namespace (an abstract resource) and thus, it should not
also denote a particular RDF/XML schema.

A namespace is a set of names, but not the full body of
knowledge about the resources denoted by those names.

An RDF schema provides statements about resources based
on their names, but need not only make statements about
names sharing a common (and irrelevant) namespace per
their RDF/XML qnames, nor must a single RDF schema provide
the complete body of knowledge about a given resource.

> The
> namespace name is resolved to absolute form as specified by the
> algorithm in Section 5.2., Resolving Relative References to Absolute
> Form, in [URI].  An RDF processor
> can expect to use the schema URI to access the schema content. This
> specification places no further requirements on the content that might be
> supplied at
> that URI, nor how (if at all) the URI might be modified to obtain
> alternate forms or a fragment of the schema.

This has always seemed a hack to me. Yes, that's what folks expected
to do, but that's not compatable with either the present web archtecture,
nor even with possible standardized solutions such as RDDL, etc.

There is no reliable way to obtain a namespace URI from a resource
URI, so there is no way for the application to know which URI it
might even try to use to obtain schema information.

If one uses rdfs:isDefinedBy to relate a term to a schema resource,
then fine, but then there is no requirement/benefit of that schema
being denoted by some namespace URI, or that the object of
rdfs:isDefinedBy is an RDF/XML instance.

> ]]
> http://www.w3.org/TR/REC-rdf-syntax/#basic
> [[
> 2.2.3. Schemas and Namespaces
> ...
> In RDF, each predicate used in a statement must be
> identified with exactly one namespace,

This is meaningless to me, since:

1. RDF throws away the qname structure and thus no namespace
exists in the resultant URI, and multiple qnames can map
to the same URI. I.e. (foo:bar#b)as and (foo:bar#)bas are
semantically equivalent insofar as RDF is concerned, since they
both map to the same URI "foo:bar#bas".

Thus, *no* predicate is related to *any* namespace. That is
an illusion of the RDF/XML which is not carried over to the
graph, which is what really matters.

2. Per above, the same predicate can be represented by
multiple qnames with differing namespaces yet all map
to the same URI.

> or schema.

A predicate can be defined by more than one schema, so
restricting it's definition to only one is counterproductive
and precludes modular management of knowledge, such as
language specific rdfs:label statements being stored
and managed in separate RDF/XML instances.

If you mean that a given predicate must belong to a single
functional vocabulary or ontology, and that it should have
consistent semantics, fine but let's please be clear what
is meant by "namespace" and "schema".

My definitions:

namespace     an abstract collection of terms
schema        an RDF/XML instance
vocabulary    a collection terms with specific semantics

Now, it may be the case that one can have a vocabulary
which is completely defined in a single schema and all
terms are represented by qnames using the same namespace
prefix, but that does *not* mean that these three
things are equivalent. They are not.

   namespace != schema != vocabulary

You could just as well have (as we do at Nokia) a vocabulary
which is defined by a large set of schemas, and employs
numerious namespaces in the qnames occurring in their
RDF/XML serialization.

A given term has definition in multiple schemas (as well as
in prose documentation) so how does knowing the irrelevant
namespace used for its RDF/XML serialization help to know
where those definitions are? It doesn't, because namespaces
are irrelevant in the RDF graph.

> ]]
> And reminding ourselves of the longer explaination of rdfs:isDefinedBy in
> the old Candidate Recommendation for RDF Schema, ie.
> http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.5
> [[
> The property rdfs:isDefinedBy is a subproperty of
> rdfs:seeAlso, and indicates the resource
> defining the subject resource. As with rdf:seeAlso, this
> property can be applied to any instance of rdfs:Resource and may have
> as its value any rdfs:Resource.
> The most common anticipated usage is to identify an RDF schema, given a
> name for one of the properties or classes defined by that schema.

I think the above is both correct, and also sufficient. The rest
of the definition can be ommitted.

> Although XML namespace declarations will typically provide the URI where
> vocabulary resources are defined,

I consider this to be an error in the original rec, per my
discussion above.

> there are cases where additional
> information is required.
> For example, constructs such as
> <rdfs:subPropertyOf
> rdf:resource="http://purl.org/dc/elements/1.0/Creator"/>
> do not
> indicate the URI of the schema that includes the vocabulary item
> Creator (i.e., http://purl.org/dc/elements/1.0/).
> In such cases, the rdfs:isDefinedBy property can be used to explicitly
> represent that
> information. This approach will also work when the URIs of the namespace
> and its components have no obvious relationship, as would be the case if
> they
> were identified using schemes such as GUIDs or MD-5 hashes.
> ]]
> We can note that:
> RDF provides a property rdfs:isDefinedBy that is a specialisation of the
> rdfs:seeAlso property. This property is used to relate an RDF vocabulary
> term (such a Class or Property) to the context within which it
> is defined.

What do you mean by "context"? RDF/XML instance? The denotation of
the functional vocabulary itself (which may be defined by numerous
schemas and other documentation)?

> For every RDF property there is exactly one correct value for the
> rdfs:isDefinedBy property.

No. This is a completely unreasonable restriction, and precludes
existing practice and any reasonable modular management of

> When RDF graphs are written in the RDF/XML 1.0 syntax, this value
> corresponds to the XML namespace URIref used in the serialized
> representation of the RDF properties.

No. See arguments above. It should remain an arbitrary instance
of rdf:Resource.

The nature of that resource can be clarified by further statements,
such as defining a class to which it belongs.

I would support the official definition of the class rdfs:Schema
which could be used for this purpose. We need not define all
possible classes, only those relevant to RDF needs.

> ....
> can we take this as a basis for progress?

Unfortunately, no. Not as far as I am concerned. Sorry.

> The main clarification is that we represent explicitly the M+S claim that
> there is just one schema for each property, and that rdfs:isDefinedBy
> can thus be used to represent (within the RDF graph) the relationship that
> holds between a property and the namespace within which it is defined.

I don't find that claim in M+S. And if I did, I would consider it
a mistake and something to be fixed.


My specific recommendations are:

1. Leave the definition of rdfs:isDefinedBy as is, though removing
the incorrect language about namespaces, allowing any instance
of rdf:Resource and multiple statements.

2. Qualify objects of rdfs:isDefinedBy by class, in the case of
RDF/XML instances, by the proposed rdfs:Schema class. This permits
those who want/need to, to be explicit about the nature of the
defining resource.

3. Clearly state that there is no functional relationship between
the URI of a term and the namespace URI used in its RDF/XML
serialization -- that the RDF model is based on URIs, not
qnames, and as such, namespaces have no significance whatsoever.



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 7 June 2002 12:11:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:58 UTC