W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2002

Re: Re[2]: Resume schema in RDF

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 07 Jun 2002 11:05:25 +0300
To: Uldis Bojars <uldis.bojars@gmx.net>, RDF Interest <www-rdf-interest@w3.org>
Message-ID: <B92643F5.164B8%patrick.stickler@nokia.com>

On 2002-06-07 0:18, "ext Uldis Bojars" <uldis.bojars@gmx.net> wrote:

> PS> 1. Define the range of the property to be a particular class. E.g.
> PS> <rdf:Property rdf:about="&ns;job_type">
> PS>     <rdfs:range "&ns;JobType"/>
> PS> </rdf:Property>
> PS> 2. Define a set of typed resources of that class.
> PS> <ns:JobType rdf:about="&ns;JobType/Contractor"/>
> PS> <ns:JobType rdf:about="&ns;JobType/Employee"/>
> PS> <ns:JobType rdf:about="&ns;JobType/Intern"/>
> And you have to define <rdf:Class rdf:about="&ns;JobType">, right?


> What is the difference between using rdf:about in defining typed
> resources in #2 and using rdf:ID as in:
> <rdfs:Class rdf:ID="MaritalStatus" rdfs:label="Marital Status"/>
> <MaritalStatus rdf:ID="Married"/>
> <MaritalStatus rdf:ID="Divorced"/>
> <MaritalStatus rdf:ID="Single"/>
> <MaritalStatus rdf:ID="Widowed"/>
> Which way is better?

Well, that's a tough question IMO as it comes down to opinions
about URIs versus URIRefs.

I personally try to avoid URIRefs with fragids in all my RDF
URIs. They are very problematic and their consistent interpretation
is still being worked out.

The use of IDs and xml:base subscribes to the single schema,
cum vocabulary, cum namespace model which I feel is overly
simplistic and is unscalable to large, modular ontologies
(borne out by real implementation experience).

Also, the use of IDs and xml:base is yet another mechanism for
getting URIs into the RDF graph which actually is not the same
as the qname concatenation method, in that, if you have a
namespace "foo:bar#" that works with qnames, you would have
to have an xml:base of "foo:bar" (sans '#') to get the URIs
to sync up -- and further, the use of IDs and xml:base precludes
the use of any namespace not ending in '#'. Thus, vocabularies
such as Dublin Core, which have namespaces ending in '/', cannot
use IDs and xml:base. Thus:

URIRef:  "foo:bar#bas"


  <!ENTITY ns "foo:bar#"> + "&ns;bas"

  -> "foo:bar#bas"


  xmlns:foo="foo:bar#" + foo:bas

  -> "foo:bar#bas"


  xml:base="foo:bar" + rdf:ID="bas"

  -> "foo:bar#bas"

But, if we have a URI rather than a URIref:

URI:  "foo:bar/bas"


  <!ENTITY ns "foo:bar/"> + "&ns;bas"

  -> "foo:bar/bas"


  xmlns:foo="foo:bar/" + foo:bas

  -> "foo:bar/bas"


  xml:base="foo:bar" + rdf:ID="bas"

  -> "foo:bar#bas"  OOPS!


  xml:base="foo:bar/" + rdf:ID="bas"

  -> "foo:bar/#bas"  OOPS Again!

So in short, the whole XML naming model -> RDF naming model
issue is a great big whopping mess, and the safest practice
IMO is

1. Use URIs as much as you possibly can, employing ENTITYs
   for editorial convenience.

2. Avoid the use of IDs and xml:base completely.

3. When you must use qnames (and you must), then

   (a) first decide on your URIs
   (b) define whatever namespaces are needed to serialize
       the URIs as qnames, ideally choosing a namespace
       that ends in a non-name character (I always use '/')
   (c) don't otherwise put any value on those namespaces or
       treat them as anything more than punctuation in the
       XML serialization; what counts is the URI, not the qname

That's my advice. Others may advise differently.

> My intuition tells me that IDs are more "carved in the rock", which
> would be good for defining typed resources. But I do not experience to
> judge it.

Well, for XML, yes. But it's important to keep in mind that
RDF is not XML, even if RDF uses XML for its serialization,
and that the underlying RDF naming model is different from
the naming model employed by XML. Thinking about resource
names in terms of qnames or IDs will cause you grief. Always
think in terms of complete (and opaque) URIs and you will
find things much easier and less troublesome.

While the RDF Core WG has made solid progress in proposing
more consistent and reasonable interpretations of URIrefs
with fragment identifiers, I personally will still avoid them.

But that's a personal choice, and others don't necessarily
share my views ;-)



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 04:01:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:41 UTC