Re: Additional i18n RDF last call comments

NB:  In case people get this twice, the following is a resend;  I've 
been having some email problems

Martin Duerst wrote:

> Hello Frank,
> 
> Many thanks for getting back to me (and the I18N WG) so quickly.
> Some more details below.


You're welcome.  Additional comments on the changes I hadn't agreed to
make in my previous message appear below:


> 
> At 21:06 03/11/14 -0500, Frank Manola wrote:
> 
> 
> 
> 
>> 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: 
>>
snip
> 
>> >
>> > 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.
> 
> 
> Sorry for not being clear enough. My primary concern was that
> if you use something related to language, use the most well-known
> http://purl.org/dc/elements/1.1/language, not something else.


Thanks for clarifying.  OK, I see your point now and, in spite of the
number of places changes will be needed to fix this, I think this is
important enough to make the changes you suggest.


> 
> If the general point that existing vocabularies should be used
> isn't yet made in the primer, then I think it would be a very
> good thing to make it. I'm sure you know the best place for that.
>


I think this point is already made, but perhaps could use some
additional emphasis;  I'll see.

 
>

snip


> 
>> > 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).
> 
> 
> I'm sure that it's not too much work to create examples than are both
> illustrative and usable out of the box. In every single case of a spec
> W3C has created so far, the experience is that people do more of cut-and-
> paste than we would like them to do. A document like the Primer has an
> enormous potential for spreading good (or bad) practice very widely.
> Examples from there easily get into all kinds of teaching material,
> books,... apart from being copied directly.
> 


Sorry;  I still don't feel the need to make this change (particularly
given the corresponding need to change Concepts).


> 

snip


> 
>> > 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.
> 
> 
> I'm somewhat confused. Are you saying that you changed the prefix
> used in the Primer, but can't change their use of the prefix?
> Or are you saying that you can't change the 'unicode' prefix
> in the Primer? The former would be nice, the later would be
> difficult for me to understand.
> 


The XPackage documentation defines what it calls the "Unicode ontology"
with the namespace http://xpackage.org/namespaces/2003/unicode#,
using the namespace prefix "unicode:", and lists properties as
"unicode:script" and " unicode:codePoints".  So what I'm saying is that
I've carried this usage into the Primer (since, after all, I'm
describing their specs), without changing the prefix "unicode:" they use
to refer to terms from that namespace.  Of course I could have used
another prefix, but then I'd have to define it, and explain what I did,
to explain the difference between what readers see in the Primer, and
what they might see if they looked at the XPackage documentation.  I
think getting into this latter kind of explanation would divert
attention from the example.

Perhaps a way to deal with both our concerns would be to change the text
in question to indicate that these are the XPackage prefixes, e.g.:

"Besides the main packaging vocabulary, XPackage itself specifies
several supplemental vocabularies:  a vocabulary (using prefix file:)
for describing files (with properties such as file:size), a vocabulary
(using prefix mime:) for providing MIME information (with properties
such as mime:contentType), a vocabulary (using prefix unicode:) for
providing character usage information (with properties such as
unicode:script), and a vocabulary (using prefix x:) for describing
XML-based resources (with properties such as x:namespace and x:style)."

Thanks again,

Frank

Received on Wednesday, 19 November 2003 08:59:35 UTC