[MOBY-dev] xml:lang explored

Mark Wilkinson markw at illuminae.com
Mon May 26 22:58:53 UTC 2008


personally, I tend to think we *should* be using the multi-lingual  
capabilities of XML more than we are!  The idea is not to introduce a  
tower of Babel, but rather to embrace as many languages as possible in our  
infrastructure!  to be inclusive, rather than exclusive!

this does, however, require extensive re-tooling of the software.  I  
wonder if it is something that is best left for Moby 2.0 (and planned from  
the start) rather than hacked into Moby 1.0?

M




On Mon, 26 May 2008 15:41:34 -0700, Pieter Neerincx  
<pieter.neerincx at gmail.com> wrote:

> Hi all,
>
> On 26 May 2008, at 20:59, Paul Gordon wrote:
>
>> I think we are mostly polyglots on this list,
>
> I'm a polyglot when I'm on holiday or in a pub maybe, but when I'm  
> talking bioinformatics stuff I'm a strict monoglot! Before we open that  
> can of worms: do we actually need translations? Did anyone request  
> support for different languages? Mark mentioned someone did on the last  
> developer meeting, but I didn't see anyone chime in on this list with a  
> request for other languages. I only noticed a few objects and services  
> in the official public Central containing descriptions in Spanish (or is  
> it Portugese?), which renders them useless for the majority of users.
>
> BioMoby web services are all about creating interoperable resources.  
> Introducing the Tower of Babel effect isn't going to help. I hope I  
> don't sound arrogant, but unless there are scientists out there using  
> BioMoby for research into language itself, archeology or culture, I  
> really fail to see why we need anything but the "de facto" standard  
> language for research. (No, I'm not a native Englisch speaker...)
>
> Is there actually any major bioinformatics resource that supports  
> translations? I can't think of any, but maybe I should write an e-mail  
> to the NCBI, DDBJ, EBI et al. and request Dutch translations of Genbank,  
> PubMed, KEGG, Uniprot, Ensembl, etc. Might be fun to see if and how they  
> repsond :)...
>
>> but for the sake of technical simplicity, I'd stick with just tracking  
>> the language rather than having multiple values in the registry.
>
> For even more simplicity I'd opt for hardcoding the language to English.  
> Now let's hope the native English speakers are not going to fight over  
> whether international English means Australian, UK, American, Canadian,  
> or yet another English. If that happens I'm voting for Dinglish :).
>
> Just my € 0.02
>
> Cheers,
>
> Pi
>
>>  Multilingual descriptions could be offloaded to the LSID metadata  
>> perhaps if people really want it.
>>
>> Mes 0.02$ canadiens,
>>
>> Paul
>>
>> Mark Wilkinson wrote:
>>> Should we allow registration of objects, service-types and namespaces  
>>> in foreign languages also?  If so, then we need to re-think the entire  
>>> way we manage the ontology, and assign unique id numbers to each node,  
>>> where the rdf:label of the node can have multiple languages, rather  
>>> than having the node named by its label.
>>>
>>> ...can... worms... but it's probably the "right thing to do"...
>>>
>>> M
>>>
>>>
>>>
>>> On Mon, 26 May 2008 00:21:23 -0700, Jason Stewart  
>>> <jason.e.stewart at gmail.com> wrote:
>>>
>>>> Hey all,
>>>>
>>>> Here's what I have found out.
>>>>
>>>> I don't believe that changing the current parser for Central.pm is
>>>> going to help the situation. I have looked and besides special API's
>>>> like the one implemented by LibXML::Reader, the application is always
>>>> required to maintain the status of xml:lang using the standard SAX and
>>>> DOM API's - for Java or for Perl.
>>>>
>>>> We will have to preserve the information in the DB, so a decision
>>>> needs to be made on what level the xml:lang should be used - only for
>>>> descriptions?? or for the whole registration?? At the moment I don't
>>>> see any reason to use it for more than the description - how do people
>>>> feel about this? Changing this should require adding one column to the
>>>> DB.
>>>>
>>>> Finally, do we want registration with multiple descriptions? That will
>>>> probably require a significant change in the DB - a new table for
>>>> linking descriptions to registrations. Are people happy about that?
>>>>
>>>> Cheers, jas.
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev



-- 
Mark D Wilkinson, PI Bioinformatics
Assistant Professor, Medical Genetics
The James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
Providence Heart + Lung Institute
University of British Columbia - St. Paul's Hospital
Vancouver, BC, Canada



More information about the MOBY-dev mailing list