Re: [LC response] To C. M. Sperberg-McQueen

Thank you for your responses to my last-call comments.

My responses are inline below.

On 6 May 2009, at 07:15 , Boris Motik wrote:

> 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
>
> ...
>
> 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.

Ah.  It finally becomes clearer to me what the CURIE specification
was trying to achieve.  If I think it's broken and introduces a
gratuitous incompatibility with existing W3C technologies (and I
believe I probably do), then my issue is with the CURIE spec and not
with yours.

The explanation is suitably involved (Talmudic, one might almost say,
or Jesuitical) to be satisfying to language lawyers; I am satisfied
with your response on this issue.

> ...
>
> 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:
>
> [2]
>

The link appears to be missing.  I would like to review the changes
you make, if only for my own instruction, so I would be grateful if
the gap could be made good.


>
> 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.

There is no *need* at all for a reference; I'm sorry if I gave
the impression that I thought there might be.  The wording of
my inquiry must have been sloppier than I realized.

I was imagining a reference to rdf:text as an example of how other
specifications could define datatypes to augment the set of primitive
datatypes defined in XSD 1.1.  Apart from providing a useful
illustration to the reader of a reasonably careful definition of
such an additional datatype, I thought that such a reference
might have the benefit of illustrating the way in which W3C
working groups cooperate in seeking to help each other and to
ensure that the technologies we define are well aligned and
recording an instance where that cooperation had actually been
attempted, with a happy result.  Success in inter-working-group
cooperation and alignment is not so common, in my experience, as
to lack all noteworthiness; perhaps others have had a different
of standardization work.  But perhaps our success in this case
is not as great, or the degree of cooperation not as high, as I
had at first thought; perhaps a reference would only mislead the
reader and give an inappropriately rosy reflection of reality.
Oh, well.  It was a nice idea to entertain for a little while.

While it would be misleading to say that I am content with, happy with,
or derive satisfaction from your response on this issue, I am
satisfied in the sense that I believe you have answered the question
I posed to you and I do not believe you need to do anything
further in the matter.

>
> 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.

Thank you; I am satisfied with your response on this question.

>
> 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.

You have greater faith than I in the intelligence and good
judgment of implementors.  But while I think your decision is
a mistake, I do not require that you report my dissent to the
director when you seek to advance your specification.  Your gun,
your bullet, your user's foot.



>
> 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.

I regret to say that I do not think this is a satisfactory response to
the issue I raised.

The fact of the matter is that while rdf:text appears to be aimed
at supporting the representation of natural-language utterances,
it is able to do so only for some writing systems, and has
at best very poor support for others.  That is, it has serious
internationalization issues and is not really adequate for the
general task of representing natural-language utterances.

There are three things you could do, or try to do, about this fact.

(1) You could fix it.

This would apparently involve you in problems because it would create
incompatibilities with existing RDF constructs. That is, the
internationalization problems visible in rdf:text are also present
in the existing constructs with which you need to be compatible.
I understand that under these circumstances you may regard fixing
the problem as an untenable approach.

(2) You could admit the problem, point it out to the reader, and explain
(as far as you know how) how best to work around it.

This would involve you in admitting that rdf:text is not really  
suitable,
in the general case, for representation of natural-language utterances
in arbitrary languages and writing systems, and that the existing
constructs with which it is intended to be compatible share those
shortcomings.  It would also involve you in recommending workarounds
for those shortcomings, or in advertising that the technology of RDF
is not, as currently constituted, really well suited for bidi
writing systems or for writing systems which use ruby characters.

(3) You could pass over the problem in silence.

This has the unfortunate side effect that it makes it appear either
that you are unaware of the problem (i.e. that the technology was
designed by clueless people) or that you are aware of it but wish to
sweep it under the rug.

I understand your response to indicate a preference for option
(3); option (3) does not satisfy this reader, and I urge you
to reconsider.  (And if you will not or cannot reconsider, then I
ask that my formal objection be registered and that it be reported
to the director when the working requests that the spec advance.)

I understand that approach (2) might be thought by some to risk
damaging your reputation, or might damage your self-esteem, but
I think the correct thing to do about known problems and shortcomings
in a technology is to document them.

You can resolve my objection on this point by adding a note to
the spec (1) pointing out that rdf:text is not suitable for, and not
intended for, the representation of natural-language text or
utterances, or (less strongly) that rdf:text cannot be used for
the adequate representation of natural-language text in writing
systems which require bidi markup or ruby markup, (2) explaining
what mechanisms should be used instead, when the text to be
represented requires markup, and optionally (3) explaining that
this state of affairs is forced upon you by the requirement of
compatibility with the existing plain literals of RDF.  The note
does not need to be long, or elaborate.  It just needs to point
out the problem and suggest ways of dealing with it.


>
> 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.

Thank you for the timely response to my comments.  Good work!


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Wednesday, 6 May 2009 16:19:24 UTC