- From: Felix Sasaki <fsasaki@w3.org>
- Date: Mon, 26 Mar 2012 18:59:36 +0200
- To: David Lewis <delewis@cs.tcd.ie>
- Cc: public-multilingualweb-lt@w3.org
- Message-ID: <CAL58czqSvXuPQkqj86s1sbKE1rBB0kwoh+5reoj2yYe6Yq41Tw@mail.gmail.com>
Hi Dave, Am 24. März 2012 01:18 schrieb David Lewis <delewis@cs.tcd.ie>: > Guys, > A couple of points in relation to this discussion > > i) We've not yet included a requirement for maintaining a unique id for > the element in the host document to which some data category refers. Jirka, > you are right that this is a relevant requirement in localisation. A major > use is in supporting the XLIFF roundtrip where we may want to maintain > links between a source document elements and the translation units in XLIFF > (XLIFF handled this with ID in skeleton files currently). It came up in the > breakout discussion in Luxembourg on Friday also. in relation to fine > grained process state tracking. > > This was previously identified as an ITS1.0 requirements, see: > http://www.w3.org/TR/**itsreq/#uid <http://www.w3.org/TR/itsreq/#uid> and > is addressed by internationalsiation best practice doc: > http://www.w3.org/TR/xml-i18n-**bp/#AuthUniqueID<http://www.w3.org/TR/xml-i18n-bp/#AuthUniqueID>. > It was elaborated for further attention in > http://www.w3.org/**International/its/wiki/**IssuesAndProposedFeatures#** > Proposal:_idValue<http://www.w3.org/International/its/wiki/IssuesAndProposedFeatures#Proposal:_idValue> > Obviously the best practise suggested here (using xml:id) would need to be > adapted for non-XML host docs, e.g. using "about" with RDFa as Jirka > suggests. > > So should we include this as an explicit functional requirements or use > case in MLW-LT? > I think this is a good idea. > > ii) Should we separate such functional requirements, such as maintenance > of source document IDs, from the particular implementation mapping, e.g. > XML+ITS tags, vs. HTML5+RDFa, vs. HTML5+microdata? > > If, as we discussed at the last week's face to face, conformance can be > claimed for a single data category in a single implementation mapping, then > its likely that certain implementations of certain data categories may > indeed be verbose, but that may be something we can live with and therefore > may not be a good reason to avoid the whole implementation mapping, since > it may be useful for other data categories. > > For example, the localisation note data category could attract more > interest for a XML+ITS tag implementation mapping, which are likely more > common in the LSP-based translation scenarios, whereas other data > categories may be more attractive in CMS-based translation scenarios, e.g. > where RDFa or microdata parsing may already be undertaken for non-i18n/l10n > purposes (e.g. source doc editing, target doc indexing) and therefore is > the preferred implementation mapping. > > The broader implication is, should we aim to provide recommendations for > every cell on the data category/implementation mapping grid and then let > the market decide, or should we be excluding implementation mappings > classes at some point prior to feature freeze in November? > I would say the latter, and ask for feedback from outside. Also, our "data category" list will probably much smaller soon (I assume before June), just because if you look at our main implementations (LT-Web "speak" WP3-WP5), there is not so much covered from https://www.w3.org/International/multilingualweb/lt/wiki/Requirements Best, Felix > > cheers, > Dave > > > On 20/03/2012 19:57, Jirka Kosek wrote: > >> On 20.3.2012 17:19, Maxime Lefrançois wrote: >> >> Example of model 1: >>> its:translate is a a literal of datatype xsd:boolean and what is >>> described is an instance of the its:Term class / is of type its:Term >>> >>> RDFa 1.1 syntax: >>> <body prefix="xsd: http://www.w3.org/2001/**XMLSchema#<http://www.w3.org/2001/XMLSchema#>its: >>> http://www.w3.org/20XX/XX/its#**"> >>> <span typeof="its:Term" property="its:value"> >>> <meta property="its:translate" content="false" datatype="xsd:boolean" /> >>> <meta property="its:locNote" content="foo">bar</span> >>> </body> >>> >>> --> This will produce the following triples, expressed in Turtle syntax: >>> @prefix its:<http://www.w3.org/20XX/**XX/its#<http://www.w3.org/20XX/XX/its#>> >>> . >>> @prefix xsd:<http://www.w3.org/2001/**XMLSchema#<http://www.w3.org/2001/XMLSchema#>> >>> . >>> <> rdf:type its:Term ; >>> its:translate "false"^^xsd:boolean ; >>> its:locNote "foo" ; >>> its:value "bar" . >>> >> Which is of no use for ITS usage scenarios. ITS data categories are >> providing metadata about particular elements in XML and this relation is >> very important. In your example triplets are completely disconnected >> from the original HTML document. It's not possible to track back on >> which element respective its:* properties should be applied. >> >> You will have to assign unique URI to each element with ITS data >> categories applied and then use about="URI" to replace blank node in >> your RDF graph with subject representing. Of course resulting syntax and >> complexity of processing will be by magnitude more complex then just >> using normal attributes. >> >> Jirka >> >> > > > -- Felix Sasaki DFKI / W3C Fellow
Received on Monday, 26 March 2012 17:00:12 UTC