Re: Workflows for localizing RDF (Fwd: Fwd: "Organization Ontology" Japanese translation available)

Hi Jose,

sorry for the late reply, currently under water.

The topic would probably fit in every place you mention. But I have a 
question: will we provide best practices in the form of

"Do XYZ because ..."
"Don't do XYZ because"

The question is really about how the BP will be presented. For the topic 
in this thread various statements could come to my mind:

"Clearly identify translatable content in your RDF ontology + data in a 
standard manner"

"Carefully decide whether you do translation inside the RDF file or 
whether you extract the content"
(Here discuss the pros + cons of extraction, the contextualization issue)

- Felix

Am 11.02.14 21:22, schrieb Jose Emilio Labra Gayo:
>
>     About "But do we get issues when using this data type  (or any non
>     http://www.w3.org/1999/02/22-rdf-syntax-ns#langString datatype)
>     when also using language tags on the literal? :": Dave is right,
>     the HTML data type would not allow for using the language tag. You
>     only could use it in the HTML content, that is no query with SPARQL.
>
>     Your feedback was quite useful - my main point is: do we want to
>     write all this down in easy to understand best practices? Dave had
>     asked a similar question, I think.
>
>
> In my opinion, yes. It is a very interesting topic that has appeared 
> in a real scenario. Looking at the Topics that we had proposed here:
>
> https://www.w3.org/community/bpmlod/wiki/Topic_classification
>
> I think this discussion could fit in:
>
> 2.3 - Longer descriptions, where we could talk about the use of HTML 
> and even XML literals.
> 2.4 - Lexicalizations and linguistic information
> 2.5 - Localization information
>
> 4.2 - Localization of existing vocabularies
>
> Do you think we need to add a different topic or is it ok as is?
>
> Best regards, Jose Labra
>
>
> -
>
>
>     Felix
>
>     Am 10.02.14 01:21, schrieb dave.lewis@cs.tcd.ie
>     <mailto:dave.lewis@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
>>
>
>
>
>
> -- 
> Saludos, Labra