From your response to our resonse, it seems to us that only point (5) had not been adequately addressed. We have now improved the document with comments along the lines of what you have suggested; below is a diff:

We hope that these and our earlier changes now address all your concerns.

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards,
Boris Motik
on behalf of the W3C OWL Working Group

CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL

Please note that neither OWL 2 nor rdt:text uses XML namespaces. The XML Namespaces specification uses QNames, which are pairs of the form (namespace,localName). Thus, when one writes <a:B>, one actually says that the element's name is a pair whose first element is the URI associated with a, and whose second element is B.

RDF (and consequently OWL as well), however, works only with URIs. That is, resources on the Web are not QNames (i.e., they are not pairs), but are URIs (i.e., strings of characters). Now RDF/XML says that, when you write <a:B>, you should generate the URI by concatenating the namespace associated with a with B. Thus, the RDF suggests that it is using the XML Namespaces specification for URI abbreviation; however, it is actually using its own mechanism based on concatenation. This mechanism has later been sanctioned in the CURIE specification.

Because of all that, we are not using the term "namespace" anywhere in either OWL 2 or rdf:text when we speak about datatype identifiers. Instead, we speak of prefix URIs, which seem like namespaces, and of prefix names, which seem like local names. Consequently, to obtain a proper URI after the prefix URI is concatenated with the prefix name, you need to terminate the prefix URI with #. After all this, you do get a proper URI that matches Section 3 of XML Schema Datatypes 1.1 (see [1]).

Your comment has, however, brought to our attention that XQuery functions are identified by QNames, rather than URIs. We have therefore changed the specification to reflect this. The link below summarizes the changes we have made:

We do not believe that XSD 1.1 needs to worry about rdf:text. The main motivation behind rdf:text was to provide adequate names for the corresponding sets of plain literals of RDF (we will elaborate more on this below). Thus, the rdf:text specification is RDF-centric and should not concern much the general XML datatype architecture. So, while we do not really have objections to you suggesting a reference from the XML Schema WG, we do not see any need to include or further tie rdf:text with XSD 1.1.

Point (3): Required export to plain literals

First of all, let us note that we lifted this restriction, by changing the MUST to a SHOULD. We decided that it id better if the equivalence between rdf:text and plain literals only is relevant for D-entailment, so RDF tools which only do simple entailment could ignore rdf:text. Still we recommend export to plain literals. The main goal of rdf:text is to provide names for the set of literals you already have, not to introduce new types of literals. As the document's introduction states, names for various sets of literals are often needed in OWL and RIF (and to some extent in RDFS as well) if you want, for example, to place appropriate range restrictions on data properties. Consequently, an OWL and RIF tool vendor will need to support rdf:text. We cannot see how the RDF export recommendation might dissuade the vendor from supporting rdf:text: with or without the export restriction, the tool vendor is not gaining any additional expressivity.

Point (4): rtfn:length function

The definition says "the number of characters", and we cannot see how this could be misunderstood. Note that we never talk about various UNICODE encodings, such as UTF-8, and doing so at this place might come a bit out of the blue.

Point (5): Internationalization issues

We agree that these might be important issues; however, they clearly exceed the scope of rdf:text. The main goal of this specification was to provide adequate names for the sets of plain literals in RDF, and not to solve all internationalization problems one might have.

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards,
Boris Motik
on behalf of the W3C OWL Working Group

CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL

[Speaking for myself and not for any organization or working group]

I've just read "rdf:text: A Datatype for Internationalized Text"
in the version of 21 April 2009. Nice work.

I do have a few questions or comments.

(1) Typo in two namespace names?

In section 2, you define conventional meanings for several
namespace prefixes, including

I realize that for reasons I think I once understood (but do not
now recall -- explain if you like, but I don't mind if you spare
yourself the effort) RDF users often create namespace names with
trailing hash marks. But I'm pretty sure that there is no
trailing hash mark in the XML Schema namespace defined by the XML
Schema spec at

If you are endeavoring to refer to that namespace, you have a
typo and should (I think) remove the hash mark. Simple-minded
readers who copy and paste the namespace name into (say) a schema
document will be disappointed, perhaps, to find that most XSD
validators don't recognize the form with the hash mark. And a
quick test reveals that some of them are fairly nasty about it.

If on the other hand you are endeavoring to refer not to that
namespace but to a different one, related conceptually to the
first (thus motivating the mnemonic of having a similar
spelling), it would probably be helpful to the reader to mention
that fact.

From uses of the xs: prefix later in the document (e.g. the

reference in 5.1.1 to xs:string), I think the former more likely.

It may be a mistake on the part of the XML Schema WG not to have
provided our namespace with a hash mark, but if so, it's a
mistake we've made (note the past tense here) and cannot now
unmake.

Similar remarks apply to the fn namespace.

(2) Should XSD 1.1 refer to rdf:text?

As you may know, XSD 1.1 differs from XSD 1.0 in allowing
conforming validators to accept primitives, and facets,
additional to those defined by the XSD 1.1 spec itself. It
occurs to me that it might be helpful to refer, from the XSD 1.1
spec, to the rdf:text spec as an example of a published
definition of such an additional primitive datatype, with
(voila!) a facet defined for it. Would the OWL and RIF working
groups have any objection to my suggesting this to the XML Schema
wg?

(3) Required export to plain literals

In section 4, you require that all RDF tools translate rdf:text
values into plain literals before exporting data to exchange with
another RDF tool. This seems likely to have the effect that some
toolmakers, at least, will argue that there is no need to support
rdf:text because no one is using it, they never see any instances
of it. (The rules in XML 1.1 which encourage users of XML 1.1 to
label their data as XML 1.0 whenever possible have led to similar
arguments that there is no XML 1.1 data anywhere, nor any XML 1.1
processors, both of which are falsehoods but apparently cannot be
rooted out.)

I wonder if it would be better just to encourage, or require,
that RDF tools which support rdf:text provide user control over
whether to export to plain literals or not. It's your decision,
of course: since rdf:text and plain literals are semantically
interchangeable, I suppose it may not matter as much as I
imagine.

(4) rtfn:length function

In section 5.3.1 you define an rtfn:length function. To avoid
confusion or error, it might be helpful to remind the reader and
implementor explicitly here that what are counted are characters,
not 16-bit code units or octets.

Otherwise, it seems inevitable that someone is just going to
implement the length function with a call to strlen(), oblivious
to the havoc that shortcut will wreak later on.

(5) Internationalization issues

From the fact that rdf:text values are pairs of UCS strings and

language tags, I infer that the type is intended to handle
natural-language text.

But if I understand correctly, some authorities strongly
recommend the use of explicit XML markup both for bidirectional
text (which, n.b., is not necessarily polyglot text) and for text
with ruby-style annotations.

I assume that one reason you don't allow internal XML markup is
that that would break compatibility with plain literals.

I think your document would be the stronger if you explained what
is to be done with Japanese text with ruby annotations, or with
Hebrew or Arabic text for which the Unicode bidi algorithm does
not suffice (and which therefore appears to need internal XML
markup to be handled reliably).