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

That was part of the discussion we had at the beginnings of the community
group. In my opinion, it is difficult to state "Do XYZ/Don't do XYZ..." in
a general way because some times it will depend on the context and other
factors. That's why in this paper [1], we chose the term "patterns" to be
able to identify common practices and to offer some suggestions on which
contexts one approach may be better than other.

In the BPMLOD Wiki [2], we are creating a table identifying the main
practices (or patterns) and filling them with those kind of advice
(arguments in favour/arguments against). I think this exercise may be
interesting but it would be great if we could also offer a more detailed
study accompanied by real examples. In the last meeting we asked for
voluntary contributors who could help us filling the table.

Using pattern terminology, it is possible that some of the practices that
we are documenting in the table, could be called "bad smells". But anyway,
I think it is a good exercise to identify them and to see in which contexts
they can be safely applied.

Anyway, the statements that you mention are very good candidates to include
in the table and to document in which contexts they are better applied. I
think they were more or less covered in sections 4.6.2 (multilingual
vocabularies) and 4.6.3 (localize existing vocabularies) in [1] but we
haven't yet arrived to discuss those sections in the community group yet :)

Best regards, Jose Labra


[1] J. E. Labra-Gayo, D. Kontokostas, and S. Auer, "Multilingual linked
open data patterns", Semantic Web - Interoperability, Usability,
Applicability, 2013. Available:
http://www.semantic-web-journal.net/content/multilingual-linked-data-patterns

[2] BPMLOD Wiki. Best practices table.
http://www.w3.org/community/bpmlod/wiki/Best_practises_-_previous_notes



> 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:
>>
>> 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#langString datatype) 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
>
>
>


-- 
Saludos, Labra