- From: <dave.lewis@cs.tcd.ie>
- Date: Mon, 10 Feb 2014 00:21:33 +0000
- To: Felix Sasaki <fsasaki@w3.org>, public-bpmlod@w3.org
- Message-ID: <52F81B8D.4040002@cs.tcd.ie>
Hi Felix, Couple of comment inline: On 07/02/2014 11:39, Felix Sasaki wrote: >> that makes sense - but do we need to have a special literal type to >> indicate that it should be parsed for 'inline' tags? > > See above - the HTML literal > http://www.w3.org/TR/rdf11-concepts/#section-html > should do the job. > But do we get issues when using this data type (or any non |http://www.w3.org/1999/02/22-rdf-syntax-ns#langStringdatatype) when also using language tags on the literal? : http://www.w3.org/TR/rdf11-concepts/#dfn-literal-value | >> Also in some cases, for example if the span had its-term--into-ref >> pointing to a term definitions elsewhere in the linked data cloud, >> best practice might be to reform (i.e. extract) the literal into a >> NIF subgraph, with the annotated sub-string as separate nif:string >> objects. > > Not sure if for generating an XLIFF file (see above) you would a NIF > subgraph. The main motivation for my BP proposal was: allow people > working with localization tools (= processing XLIFF files) to > translate labels in linke data. > > So all the below makes sense IMO for textual content, extracted from > HTML / XML etc. But processing the labels in linked data with NIF? Not > sure if that is needed and might even hinder XLIFF based using > localization workflows. > Agreed, getting the annotation to work with XLIFF/ITS in a way that can used used in exisitng tools should be the primary aim here. The use of NIF is more relevant if you wanted to make the content available to NLP tools that could understand NIF - which is a different use case. cheers, Dave > Disclaimer: really nothing against NIF ;) My point is only about the > right approach for label translation. > > Best, > > Felix
Received on Monday, 10 February 2014 00:21:59 UTC