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

Re: rdfms-uri-substructure: some clarifying advice [was: A collection of issue resolutions]

From: Dan Connolly <connolly@w3.org>
Date: 13 Feb 2002 11:06:40 -0600
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: RDF Core <w3c-rdfcore-wg@w3.org>
Message-Id: <1013620000.18790.2.camel@dirk>
On Wed, 2002-02-13 at 10:28, Brian McBride wrote:
> Dan,
> Your proposal looks like a good idea.  Can we combine the two.  The strict 
> answer to the issue is that no, we are not going to change from URI's to 
> pairs.  And then add the guidance.


> A small nit type question:  Jena does store URI's internally as pairs and 
> allows a client app to specify the namespace and the local name:
>     Property p = m.createProperty(namespace, localname);
> When it comes to serializing such a property the serializer has been told 
> where to split by the application.  Are you suggesting that this should 
> still throw an exception when the namespace does not end in an appropriate 
> character?


The exception comes when a serializer is trying to take
a URI (i.e. the full name of a property or class)
and break it into a namespace name and a local name.
If the last character of the URI is a non-name character,
there's no way to do it.

I can imagine some exceptions that a
  createProperty(namespace, localname)
method should raise:
	the local name isn't an XML name (e.g. "012")
	the namespace name isn't an absolute URI reference
		("abc" or "foo:##bar")

and if you have some capacity for warnings, I'd suggest
a warning if the namespace name *does* end with an
XML name character, e.g.
	createProperty("http://example/vocab", "myterm")
since we're advising folks to serialize the resulting URI
	<vocabmyterm xmlns="http://example/">...</>
which will not XPath-match the serialization that I expect
Jena produces:
	<myterm xmlns="http://example/vocab">...</>

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 13 February 2002 12:07:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:10 UTC