Re: Additional i18n RDF last call comments

Martin Duerst wrote:

> 
> Dear RDF WG,
> 
> These are additional internationalization-related comments that
> haven't been discussed by the I18N WG yet. Please accept them as
> personal comments. They may be confirmed as WG comments next week.
> 


Martin--

Thanks again for your comments on the RDF drafts.  Regarding your second 
message, 
http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0121.html:

 >
 > primer, 2.1, first para: It may help translation to change
 > 'state this in English' to 'state this in a natural language
 > such as English'.
 >

I'll make the change you suggest.

 >
 > primer, fig. 3 and all related examples/discussion: Instead of
 > http://www.example.org/terms/language,
 > http://purl.org/dc/elements/1.1/language should be used. There
 > is no reason to use a made-up property when there is a well-
 > defined property from a well-known vocabulary that is used
 > in the same example.
 >

If you're concerned about making the point that existing vocabularies 
should be used where possible, it seems to me a better plan would be to 
explicitly say this later in the section, where the value of using 
shared vocabularies is discussed.  At that point, it could also be 
pointed out, as an example, that 
http://purl.org/dc/elements/1.1/language could be used instead of 
http://www.example.org/terms/language.  I don't see much point in making 
an extensive change to "all related examples/discussion" to make this 
point. There is a good reason to use a made-up property in this case: 
to illustrate that people can make up their own vocabularies (and mix 
them with others).  At that point in the Primer, only three properties 
have been used in total (not counting the example in Section 1).  The 
Dublin Core vocabulary is already used for one of the properties (in 
fact, for the first property introduced).  The Primer later notes that 
people can use vocabularies that already exist, and emphasizes the value 
of doing so.  And it seems to me that "later" is the place to get into 
where vocabularies come from;  not in the initial examples that are 
simply trying to illustrate the use of multiple properties to describe a 
resource.  BTW, no doubt an existing term could be found for every 
made-up property used in the Primer;  and many (most?) readers of the 
Primer will not consider the Dublin Core vocabulary to be "well-known".

 >
 >
 > primer, section 2.3, fig 5 and related: The address example is on the
 > boundary of a generic internationalized address. 'postalCode' is
 > very generic, whereas 'street' and 'state' may not be generic enough.
 > Also, the address misses the country information. At least this should
 > be added; the fields can then be understood as country-specific.
 >

This affects a number of places in the Primer (including an example in 
Section 4.4), and also the Concepts spec (which copies Figure 6).  I 
think people will get the idea (and not be terribly misled) without 
these changes (which, after all, involve what are intended to be simple 
illustrations).

 >
 > primer, example 22: The explanation mentions 'the escaping of reserved
 > characters such as ...'. This may be highly misleading. "<" (as a literal
 > character) already has to be escaped, and ">" already is escaped in
 > the example. Probably changing to "the uniform escaping or unescaping
 > of characters" should do the job. On average, there may be more
 > unescaping of NCRs when canonicalizing than escaping.
 >

I'll make the change you suggest.

 >
 > primer, general: a few examples in section 6 use xml:lang. It should be
 > used much more.
 >

The examples in section 6 are taken from the indicated sources (not made 
up by me).  It seems to me that there is enough use in section 6 to make 
it clear that its use is an option (and the main purpose of section 6 is 
to illustrate a range of applications of RDF in the field, not 
necessarily the use of all RDF/XML facilities).

 >
 > In section 6.5, the use of xml:lang for rdfs:label but not for
 > rdfs:comment is confusing. Does this suggest that rdfs:label
 > can be in multiple languages, but rdfs:comment can only be
 > in English?
 >

I don't believe there will be any particular confusion to most readers 
of the Primer (these examples have been in the Primer for at least a 
year;  no one has mentioned this yet).  Anyway, it seems to me that if 
people are going to read intent into examples like this, *uniformly* 
using xml:lang could cause equal confusion, by suggesting that its use 
was required rather than optional.  At any rate, these examples are 
taken from CIM/XML material, and illustrate a valid use of xml:lang.


 >
 > primer, section 6.2: Greece in French is written with grave accent,
 > in HTML as Gr&egrave;ce.
 >

I'll make this change.

 >
 > primer, section 6.3: "Unicode information (such as unicode:script)":
 > It is probably better to change this to "Character usage information
 > (with properties such as unicode:script)". But the use of an 'Unicode'
 > namespace prefix may suggest to some reader that this is some official
 > vocabulary defined by the Unicode consortium.
 >

I'll make the change you suggest to Section 6.3 (and, for parallelism, 
similar changes to the other examples mentioned here, like 
"mime:contentType").

Regarding the use of the "unicode" namespace prefix, I can't do much 
about that, since this is the name the XPackage folks have chosen for 
this "ontology" (their term).  The same problem exists for any namespace 
prefix that might be used (here or elsewhere), since anyone can locally 
choose to use a given prefix (it's only the full URIs that are subject 
to some form of control).  If a warning to this effect is needed, I'd 
prefer to make a general warning in Section 2.2, rather than scattering 
them all over the Primer.

Thanks again.

--Frank

Received on Friday, 14 November 2003 10:59:25 UTC