Re: ISSUE-191 reference filtering in RFC 4647 (was Re: Request for feedback on SKOS Last Call Working Draft)

Hi Addison,

Many thanks for your response. The WG wanted to move to CR as soon as
possible, so publication went ahead as soon as we received this
response, without incorporating any of your personal
observations. Given that they constitute relatively minor editorial
changes, I hope to do so for the PR.

Thanks again,

Alistair

On Sat, Mar 14, 2009 at 12:11:01PM -0700, Phillips, Addison wrote:
> 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

-- 
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 Thursday, 2 April 2009 08:20:18 UTC