Warning:
This wiki has been archived and is now read-only.
LC2 Responses/CMSM1
To: cmsmcq@blackmesatech.com
CC: public-owl-comments@w3.org
Subject: [LC response] To C. M. Sperberg-McQueen
Dear C. M.,
Thank you for your comment
<http://lists.w3.org/Archives/Public/public-owl-comments/2009Apr/0052.html>
on the OWL 2 Web Ontology Language last call drafts.
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:
http://www.w3.org/2007/OWL/wiki/index.php?title=InternationalizedStringSpec&diff=23650&oldid=23375
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
To: cmsmcq@blackmesatech.com
CC: public-owl-comments@w3.org
Subject: [LC response] To C. M. Sperberg-McQueen
Dear C. M.,
Thank you for your comment
<http://lists.w3.org/Archives/Public/public-owl-comments/2009Apr/0052.html>
on the OWL 2 Web Ontology Language last call drafts.
Point (1): # at the end of namespaces
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:
http://www.w3.org/2007/OWL/wiki/index.php?title=InternationalizedStringSpec&diff=22854&oldid=22534
Point (2): Should XSD 1.1 refer to rdf:text?
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 xs for http://www.w3.org/2001/XMLSchema# fn for http://www.w3.org/2005/xpath-functions# 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 http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ or, for XSD 1.1, by http://www.w3.org/TR/xmlschema11-1/ http://www.w3.org/TR/xmlschema11-2/ 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).
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |