W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > October 2012

RE: [All] action item clean up and publication schedule

From: Fredrik Liden <fliden@enlaso.com>
Date: Wed, 17 Oct 2012 12:16:04 -0600
To: Tadej Štajner <tadej.stajner@ijs.si>, "public-multilingualweb-lt@w3.org" <public-multilingualweb-lt@w3.org>
Message-ID: <assp.06370afbe9.4236658BB877A542A66660614300B1858012383204@orion.helios.local>
Hi Tadej,

Thanks for the explanation, that’s what I figured about the classes as URIs. However, if I understand it correctly the disambigClassPointer points to a node with a freeform class text? Maybe an example of this would be useful.

I wasn’t going to bring it up (because I assumed it’s been discussed already and also a lot of these concepts are new to me) but I have to admit I was wondering why there is  disambigIdent and disambigIdentPointer but for class there is only the disambigClassPointer but no disambigClass. I’m assuming the class information is not something you’d want to store in the ITS rules (like locNote) but because of the disambigSource the identifier is something that can be?

Cheers,
Fredrik



From: Tadej Štajner [mailto:tadej.stajner@ijs.si]
Sent: Wednesday, October 17, 2012 4:39 AM
To: public-multilingualweb-lt@w3.org
Subject: Re: [All] action item clean up and publication schedule

Hi Fredrik,
I'll try to explain some of the rationale behind some decisions.

While there is a disambigIdent version, there is no disambigClass: the reason is that there already exist practices for representing classes as URI resources and they're generally used, this is not yet true for disambiguation identifiers: we still need to let people use non-URI identifiers, and introducing a new attribute (that is used in conjunction wtih disambigSource) made the most sense.

The rest of the comments I agree with - thanks for the thororugh read.
 -- Tadej

On 17. 10. 2012 01:11, Felix Sasaki wrote:
Hi Fredrik,

thanks a lot for the comments. I tried to implement these at

http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#Disambiguation


I think example 54
http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#EX-disambiguation-html5-rdfa

and 55 are not up to date - Tadej, coud you have a look?

Also, one question below.
2012/10/16 Fredrik Liden <fliden@enlaso.com<mailto:fliden@enlaso.com>>

Hi all,



after looking at the latest Disambiguation section here are a few comments and possibly nitpicking:



* "None of exactly one of the following:" should be "None or exactly one of the following:"

* Under 6.10.2 Implementation, in list, initial cap: a disambigIdentRefPointer attribute.

* I think in example 52 should the selector should be changed from



   selector="/text/body/p/[@id='dublin']"

   to

   selector="/text/body/p/span[@id='dublin']" or selector="/text/body/p/*[@id='dublin']"



*

   ◦A disambigIdentPointer attribute...

   ◦A disambigIdentRef attribute... Would it be better to list the following in this order to be consistent with Localization Note and Terminology (Or follow the order in the latest Translation Agent Provenance, consistent one way or the other)? I found the disambigClassPointer in between the two slightly confusing especially since there is no plain disambigClass:



   ◦A disambigClassPointer attribute...

   ◦A disambigClassRef attribute...

   ◦A disambigClassRefPointer attribute...



   And

   ◦A disambigIdent attribute...

   ◦a disambigIdentRefPointer attribute...

   1. Initial cap A (mentioned above).
   2. Replace "◦A XYX attribute. It contains" with "◦A XYX attribute that contains" to be consistent



* Perhaps clarify "When using a disambiguation rule, the user MUST use one of the use cases for disambiguation:"

Should it be "When using a disambiguation rule, the user MUST use at least one of the use cases for disambiguation:" to be clear. But it seems it's illustrated by the example that both can be used. Optionally, change the list format to the one used in some other data categories se bottom, that might clarify the options.



* Under LOCAL:
"The user MUST use only one of the two addressing modes for disambiguation:"
Should this perhaps say "The user MUST use only one of the two addressing modes for "target identity" disambiguation:" to not confuse it with the above sentence.



What is the below for?

Thanks,

Felix




•At least one of the following:

    •Exactly one of the following:

      ◦A disambigClassRef..

      ◦A disambigClassPointer..

      ◦A disambigClassRefPointer ..



    •One or more of the following:

       •Exactly one of the following:

                 ◦A disambigIdent attribute..

                 ◦A disambigIdentRef attribute..

                 ◦A disambigIdentPointer attribute..

                ◦A disambigIdentRefPointer attribute..



       •An optional disambigSource attribute..



•An optional disambigGranularity attribute..



Cheers,
__________________________________________________

Fredrik Liden
Localization Engineer
ENLASO Corporation
ISO 9001:2008 certified

t: 720.259.8537
e: fliden[at]enlaso[dot]com






-----Original Message-----
From: Yves Savourel
Sent: Tuesday, October 16, 2012 6:44 AM
To: public-multilingualweb-lt@w3.org<mailto:public-multilingualweb-lt@w3.org>
Subject: RE: [All] action item clean up and publication schedule



> while the text is up-to-date, the examples seem to be a couple of

> versions behind - in the last few iterations we were only circulating

> the .doc, so it may have got out of sync.

> I'm attaching the latest examples here - without disambigSourceRef, etc.



Thanks Tadej. I'll update the spec later today.





> Is HTML also case-insensitive for attribute values?

> For element and attribute names it is, not sure about literal values.

> If so, we could change the spec to use dashes (ontologyConcept ->

> ontology-concept).



I'm not sure for the values. Jirka or Felix would know for sure. Maybe it's not an issue.



-yves









--
Felix Sasaki
DFKI / W3C Fellow


Received on Wednesday, 17 October 2012 18:19:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:55 UTC