- From: Phillips, Addison <addison@amazon.com>
- Date: Sat, 14 Mar 2009 12:11:01 -0700
- To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>
- CC: Antoine Isaac <aisaac@few.vu.nl>, "Ralph R. Swick" <swick@w3.org>, Richard Ishida <ishida@w3.org>, "public-swd-wg@w3.org" <public-swd-wg@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "'Felix Sasaki'" <fsasaki@w3.org>
Hello Alistair, Except as noted, this response is on behalf of the I18N Core WG (see [1]). This change looks good and will meet the Internationalization working group's concerns. Thank you for your help on this. We also support Richard Ishida's comments to you and I will reply to your email on that topic under separate cover. === personal observations === The proposed text works pretty well. I would suggest only a couple of minor changes. """ It is suggested that applications match requests for labels in a given language to labels with related language tags that are provided by a SKOS concept scheme, AP> I would suggest not using the term "related" here, since BCP 47 points out that tags that share a prefix may not actually be mutually intelligible. Perhaps: ...(of which there could be many), and are compatible with SKOS concept schemes that provide only those labels whose lexical forms are distinct for a given language or collection of languages. """ AP> This last bit might be a little too "tight around the collar"? It suggests that only a few SKOS schemes will limit their array of tags, whereas, in truth, most will provide limited coverage, even within a language family. Furthermore, BCP 47 has long recommended using the simplest language tag possible. Perhaps: "... (of which there could be many), since, in keeping with best practices, most SKOS concept schemes will provide the simplest language tag for a given label and only supply those additional labels whose lexical forms are distinct for a given language variation." === end personal observations === My foregoing observations are certainly optional. I18N looks forward to seeing your WG announce advancement of SKOS Reference to CR. Best Regards, Addison (for I18N) [1] http://www.w3.org/2009/03/11-core-minutes.html#item06 Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: Alistair Miles [mailto:alistair.miles@zoo.ox.ac.uk] > Sent: Saturday, March 14, 2009 11:44 AM > To: Phillips, Addison > Cc: Antoine Isaac; Ralph R. Swick; Richard Ishida; public-swd- > wg@w3.org; public-i18n-core@w3.org; 'Felix Sasaki' > Subject: Re: ISSUE-191 reference filtering in RFC 4647 (was Re: > Request for feedback on SKOS Last Call Working Draft) > > Hi Addison, > > I have published a new revision of the SKOS Reference Editors' > draft: > > http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/ (revision > 1.86) > > In this draft in section 5.6.5 (Labeling and Language Tags) I have > added the following paragraph: > > """ It is suggested that applications match requests for labels in > a > given language to labels with related language tags that are > provided > by a SKOS concept scheme, e.g. by implementing the "lookup" > algorithm > defined by [BCP 47]. Applications that perform matching in this way > do > not require labels to be provided in all possible language > variations > (of which there could be many), and are compatible with SKOS > concept > schemes that provide only those labels whose lexical forms are > distinct for a given language or collection of languages. """ > > I basically followed your suggested prose, with a few tweaks to fit > with the language of the document. > > I'm going to offer this revision to the working group for > progression > to candidate recommendation, if you have any further comments or > suggestions then please let me know as soon as possible. > > Note that there are also some other editorial changes in section 5 > in > response to suggestions by Richard, which I will describe in a > separate email. > > Kind regards, > > Alistair > > > > On Tue, Mar 10, 2009 at 12:51:54PM +0000, Alistair Miles wrote: > > Hi Addison, > > > > I've raised an issue in the SWDWG tracker to ensure that this > > discussion is recorded in the WG's audit trail: > > > > http://www.w3.org/2006/07/SWD/track/issues/191 > > > > With respect to the SKOS Reference, would you be minimally > satisfied > > if section 5.6.5 [1] were to include the following sentence: > > > > """ It is suggested that applications match requests for a label > in a > > given language to related language tags that exist in the SKOS > > document, e.g. by implementing the "lookup" algorithm from [BCP > > 47]. This practice is compatible with SKOS concept schemes that > > provide only those labels whose lexical forms are distinct for a > given > > language or collection of languages. """ > > > > My initial reaction was to view this as an aspect of best > practice > > that is out of scope for the SKOS Reference and would be better > dealt > > with in a separate document, but I don't have a strong feeling > about > > this and am happy to include a note in the SKOS Reference. > > > > Kind regards, > > > > Alistair > > > > [1] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#L1629 > > > > On Mon, Mar 09, 2009 at 11:51:42AM -0700, Phillips, Addison wrote: > > > Hi, (personal comment follows) > > > > > > I don't agree that SKOS should ignore this issue in its > documents. My concern is that the text and examples in SKOS may go > too far by concentrating on the fact that different language tags > are separate. I don't think that SKOS has to promote a particular > matching scheme or implementation of language tags, but it needs to > balance separation of tags for RDF purposes from an acknowledgement > of how language tags are typically expected/supposed to work. The > fact that this thread is tied up in knots on the issue should be an > indicator that users of the Reference and Primer might need a hint > of how to proceed. > > > > > > I think, in fact, that this text in the Primer is misleading: > > > > > > -- > > > Note that the notion of preferred label implies that a resource > can only have one such label per language, as it is mentioned in > Section 5 of the SKOS Reference [SKOS-REFERENCE]. > > > > > > Following common practice in KOS design, the preferred label of > a concept may be also used to unambiguously represent this concept > within one KOS and its applications. Although SKOS semantics do not > formally enforce it, it is therefore recommended that no two > concepts in the same KOS be given the same preferred lexical label > in any two given languages. > > > -- > > > > > > No mention is made of the overlapping nature of tags. This > suggests that you would only label the "differences" in a SKOS > document between two related languages: > > > > > > skos:prefLabel "red"@en > > > ... > > > skos:prefLabel "green"@en > > > ... > > > skos:prefLabel "color"@en <!-- cultural bias here --> > > > skos:prefLabel "colour"@en-GB > > > > > > Again, this suggests a resource tree rather than a dictionary. > Also: your recommendation will be problematic when there are cross- > language homonyms. For example, both English and French have the > word "chat" (but it means something different in each); while the > word "machine" exists in both and means (roughly) the same thing. > > > > > > So I might say the following instead of the above text: > > > > > > -- > > > Note that the notion of preferred label means that a resource > can only have one such label per language tag, as is mentioned in > Section 5 of the SKOS Reference [SKOS-REFERENCE]. > > > > > > Following common practice in KOS design, the preferred label of > a concept may be also used to unambiguously represent this concept > within one KOS and its applications. Although SKOS semantics do not > formally enforce it, it is therefore recommended that no two > concepts in the same KOS be given the same preferred lexical label > using the same language tag. > > > > > > Two languages might sometimes apply the same label to different > concepts in different contexts: this should be avoided to the > extent possible. In addition, it may sometimes be desirable to use > the same label with different language tags, even if the languages > are related. > > > > > > Because there are many more language tags that can be generated > than there are distinct labels needed in any particular KOS, it is > recommended that implementations match requests for a label in a > given language to related language tags that exist in the SKOS > document, perhaps by implementing the "lookup" algorithm from IETF > BCP 47. This allows the SKOS document to carry only those labels > that are distinct for a given language or collection of languages. > > > -- > > > > > > Something like that. Otherwise I think you'll run afoul of > implementers making all manner of (problematic) assumptions about > what language tag presence or absence means in SKOS labels. > > > > > > Regards, > > > > > > Addison > > > > > > Addison Phillips > > > Globalization Architect -- Lab126 > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: Antoine Isaac [mailto:aisaac@few.vu.nl] > > > > Sent: Saturday, March 07, 2009 6:12 AM > > > > To: Phillips, Addison > > > > Cc: Alistair Miles; Ralph R. Swick; Richard Ishida; public- > swd- > > > > wg@w3.org; public-i18n-core@w3.org; 'Felix Sasaki' > > > > Subject: Re: Request for feedback on SKOS Last Call Working > Draft > > > > > > > > Hi Addison, > > > > > > > > To clarify my previous mail. Your point makes much sense to > me, but > > > > I don't think we should add this in the SKOS documents > (that's true > > > > for the Reference, and even more true for the Primer). > > > > These matters are indeed quite complex, especially for > "normal" RDF > > > > users who are not aware of these things. Furthermore, they > are not > > > > really specific to SKOS, but to every data representation > means > > > > which use language tags. And they are more related to the way > one > > > > consumes data than to the way it is represented and exchanged, > > > > which I feel is the core business of SKOS. > > > > > > > > Note that this position is just my own, I'm not speaking for > the > > > > SWD WG here. > > > > > > > > Best > > > > > > > > Antoine > > > > > > > > > Hi Addison, > > > > > > > > > > It makes sense! > > > > > > > > > > Antoine > > > > > > > > > >> Hi Antoine, > > > > >> > > > > >> Yes, as I said the SKOS model is technically correct, > accurate, > > > > and > > > > >> complete. The issue is what users and implementations do > with it. > > > > I > > > > >> think the main concern I have is that SKOS Reference makes > quite > > > > clear > > > > >> that you can have multiple labels with related-but-not- > identical > > > > >> language tags. It is just that, having gone out of its way > to > > > > say that > > > > >> 'en' != 'en-US', it doesn't further clarify that the > presence of > > > > an > > > > >> 'en' tag is allowed imply a match with e.g. 'en-AU' or > 'en-NZ', > > > > if the > > > > >> latter are not provided as distinct labels. > > > > >> > > > > >> Does that make sense? > > > > >> > > > > >> Addison > > > > >> > > > > >> Addison Phillips > > > > >> Globalization Architect -- Lab126 > > > > >> > > > > >> Internationalization is not a feature. > > > > >> It is an architecture. > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Antoine Isaac [mailto:aisaac@few.vu.nl] > > > > >>> Sent: Wednesday, March 04, 2009 10:00 AM > > > > >>> To: Phillips, Addison > > > > >>> Cc: Alistair Miles; Ralph R. Swick; Richard Ishida; > public-swd- > > > > >>> wg@w3.org; public-i18n-core@w3.org; 'Felix Sasaki' > > > > >>> Subject: Re: Request for feedback on SKOS Last Call > Working > > > > Draft > > > > >>> > > > > >>> Hi Addison, > > > > >>> > > > > >>> Thanks for the explanation, which makes a bit clear what > I had > > > > >>> understood from [1]: > > > > >>> "Matching different language tags is important for a > number of > > > > >>> applications. According to BCP 47 'en' can be said to > match > > > > 'en- > > > > >>> GB'." > > > > >>> > > > > >>> If I understand well, there are applications that could > do this > > > > >>> filtering, and if they use data which was not intended > for > > > > >>> filtering (that is, data including language tag variation, > > > > because > > > > >>> their original context of application was concerned with > that), > > > > >>> then there could be trouble. > > > > >>> > > > > >>> But maybe this is not so much trouble in fact: that kind > of > > > > >>> matching does not amount to producing new RDF data (in > your > > > > example, > > > > >>> a new triple ex:walkingPath skos:prefLabel > "sidewalk"@en. ), > > > > does > > > > >>> it? > > > > >>> If the data stays the same, and if as you say it is > technically > > > > >>> valid, then there is no possible inconsistency with what > the > > > > SKOS > > > > >>> model specifies. > > > > >>> > > > > >>> Best, > > > > >>> > > > > >>> Antoine > > > > >>> > > > > >>> [1] http://www.w3.org/International/articles/language- > tags/ > > > > >>> > > > > >>> > > > > >>>> Hello Alistair, > > > > >>>> > > > > >>>> Thanks for the note back. > > > > >>>> > > > > >>>> I'm aware of the SPARQL function: I helped the WG craft > the > > > > text > > > > >>> about it. The query function might turn out to be a > problem and > > > > I > > > > >>> may not have given the right feedback in my last email. > Let me > > > > >>> explain. > > > > >>>> My concern is that, if you have a triple like: > > > > >>>> > > > > >>>> ex:walkingPath rdf:type skos:Concept; > > > > >>>> skos:prefLabel "sidewalk"@en-US; > > > > >>>> skos:prefLabel "pavement"@en > > > > >>>> > > > > >>>> ... then SKOS rightly asserts that "en" and "en-US" are > > > > different > > > > >>> languages exclusive of one another. This implies that one > must > > > > >>> include a separate prefLabel for every possible language > tag > > > > >>> variation one wishes to support. This is not generally > the > > > > >>> intention when applying language tags. > > > > >>>> So my example doesn't say whether the label for "en" > covers a > > > > >>> user who speaks "en-GB" or "en-AU" or "en-NZ" (for > example). > > > > Those > > > > >>> are all different languages not specified. Typically, a > request > > > > for > > > > >>> the label from the SKOS description of an ontology will > contain > > > > the > > > > >>> user's fully qualified language preference--that is, they > are > > > > >>> specifying the MOST information that they care to provide > about > > > > >>> their language. The matching scheme in RFC 4647 for that > is > > > > called > > > > >>> "lookup" and it falls back (a request for "en-GB" in my > example > > > > >>> would find "pavement", labeled as "en"). That is, a SKOS > file > > > > >>> contains what we I18N folks would call a "resource > bundle" or > > > > >>> "message catalog". > > > > >>>> In any case, SKOS is technically correct, but I think my > > > > advice > > > > >>> would be to add some note clarifying that a natural > language > > > > label > > > > >>> defined in SKOS should be considered to apply to any > request > > > > not > > > > >>> masked by some other label. It is possible but very > difficult > > > > to > > > > >>> construct using SPARQL langMatches, whose purpose is > actually > > > > >>> different. > > > > >>>> So I guess I'd request notes in the Reference and Primer > > > > >>> clarifying that, although (for example) "en" and "en-US" > are > > > > >>> considered to be different, one may consider a shorter > language > > > > tag > > > > >>> that is a "prefix" (by language tag standards) to match a > > > > longer > > > > >>> "language range" in a request. That is, you don't need to > > > > supply > > > > >>> "en-AU" if it is not different from "en". > > > > >>>> Regards, > > > > >>>> > > > > >>>> Addison > > > > >>>> > > > > >>>> Addison Phillips > > > > >>>> Globalization Architect -- Lab126 > > > > >>>> > > > > >>>> Internationalization is not a feature. > > > > >>>> It is an architecture. > > > > >>>> > > > > -- > > Alistair Miles > > Senior Computing Officer > > Image Bioinformatics Research Group > > Department of Zoology > > The Tinbergen Building > > University of Oxford > > South Parks Road > > Oxford > > OX1 3PS > > United Kingdom > > Web: http://purl.org/net/aliman > > Email: alistair.miles@zoo.ox.ac.uk > > Tel: +44 (0)1865 281993 > > > > -- > Alistair Miles > Senior Computing Officer > Image Bioinformatics Research Group > Department of Zoology > The Tinbergen Building > University of Oxford > South Parks Road > Oxford > OX1 3PS > United Kingdom > Web: http://purl.org/net/aliman > Email: alistair.miles@zoo.ox.ac.uk > Tel: +44 (0)1865 281993
Received on Saturday, 14 March 2009 19:11:45 UTC