From mdoering at gbif.org Thu Sep 16 05:34:28 2010 From: mdoering at gbif.org (=?iso-8859-1?Q?=22Markus_D=F6ring_=28GBIF=29=22?=) Date: Thu, 16 Sep 2010 14:34:28 +0200 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 References: Message-ID: <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> Hi, Ive been validating various eml documents with multiple, multilingual titles to the eml 2.1.0 schemas recently. With Xerces (java5/6 on mac), some unknown php processor and your own validation service at http://knb.ecoinformatics.org/emlparser/ I am getting the following validation errors: cvc-type.3.1.1: [attributes] of element 'title' must be empty, excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocation. Im using the sample document here: http://rs.gbif.org/schema/eml/sample.xml I always thought one can use the xml:lang attribute (actually any of the 4 xml namespace attributes) on any xml element. But looking at the latest xml namespace schema from 2009 it seems this is wrong and any schema that allows the use of xml:lang must properly declare the attribute: http://www.w3.org/2001/xml.xsd#ann_3 I took the liberty to copy your schemas to our servers and modified the eml-resource.xsd, adding an xml namespace import and the lang attribute to the title element: http://rs.gbif.org/schema/eml/eml-2.1.0/eml-resource.xsd With this modified schema set the document validates. Have anyone of you used multilingual titles in eml before? I am assuming multiple titles with an xml:lang attribute should be supported in eml, at least it says so in the docs: http://knb.ecoinformatics.org/software/eml/eml-2.1.0/eml-resource.html#title If its a true bug, is there a chance to release an official new version or better a patch for the 2.1.0 namespace? Best wishes, Markus -- Markus D?ring Senior Developer ECAT GBIF Secretariat mdoering at gbif.org From leinfelder at nceas.ucsb.edu Thu Sep 16 09:56:05 2010 From: leinfelder at nceas.ucsb.edu (ben leinfelder) Date: Thu, 16 Sep 2010 09:56:05 -0700 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> References: <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> Message-ID: Hi Markus, I'm afraid your findings are accurate with respect to the xml:lang attribute in the element (or any "NonEmptyStringType" element). In the course of my experimentation with allowing backwards-compatible internationalization with a new EML version (2.1.1) I did have to include the "http://www.w3.org/XML/1998/namespace" namespace just as you did and also declare the xml:lang attribute in elements where I wanted to employ it. While certain EML elements are repeatable, it's not always clear what the presence of multiple elements represent (are they translations in different languages or are they alternate titles?). In order to clarify this confusion and also allow multiple translations for non-repeatable elements I proposed a solution for allowing mixed element content for fields that should be internationalized. There's a fairly comprehensive discussion of this approach in our eml-dev archives: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html I didn't get a lot of decisive feedback and so have not moved forward with releasing an updated EML version. Hopefully this thread will again set the ball rolling. -ben On Sep 16, 2010, at 5:34 AM, Markus D?ring (GBIF) wrote: > Hi, > Ive been validating various eml documents with multiple, multilingual titles to the eml 2.1.0 schemas recently. > With Xerces (java5/6 on mac), some unknown php processor and your own validation service at http://knb.ecoinformatics.org/emlparser/ I am getting the following validation errors: > > cvc-type.3.1.1: [attributes] of element 'title' must be empty, excepting those whose [namespace name] is identical to http://www.w3.org/2001/XMLSchema-instance and whose [local name] is one of type, nil, schemaLocation or noNamespaceSchemaLocation. > > Im using the sample document here: > http://rs.gbif.org/schema/eml/sample.xml > > > I always thought one can use the xml:lang attribute (actually any of the 4 xml namespace attributes) on any xml element. But looking at the latest xml namespace schema from 2009 it seems this is wrong and any schema that allows the use of xml:lang must properly declare the attribute: > http://www.w3.org/2001/xml.xsd#ann_3 > > > I took the liberty to copy your schemas to our servers and modified the eml-resource.xsd, adding an xml namespace import and the lang attribute to the title element: > http://rs.gbif.org/schema/eml/eml-2.1.0/eml-resource.xsd > With this modified schema set the document validates. > > Have anyone of you used multilingual titles in eml before? > I am assuming multiple titles with an xml:lang attribute should be supported in eml, at least it says so in the docs: > http://knb.ecoinformatics.org/software/eml/eml-2.1.0/eml-resource.html#title > > If its a true bug, is there a chance to release an official new version or better a patch for the 2.1.0 namespace? > > > Best wishes, > Markus > > > > -- > Markus D?ring > Senior Developer ECAT > GBIF Secretariat > mdoering at gbif.org > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev From isangil at canyon.lternet.edu Thu Sep 16 12:35:02 2010 From: isangil at canyon.lternet.edu (Inigo San Gil) Date: Thu, 16 Sep 2010 13:35:02 -0600 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> Message-ID: <4C927166.2050001@canyon.lternet.edu> We'll keep our eyes on the ball, then. Meanwhile others have adopted their own solution. Here are two examples: 1) a site from Spain reports this implementation <title>[Language:En]Snow cover data provided by MODIS satellite imagery [Language:Sp]Datos de innivación según imágenes MODIS We thought that the use of the XML attribute "lang=en | sp" was interesting -but, among other problems, we would have gotten screwed by eml-dev eventual internationalization implementation. Call it luck, but you can bet the "eventual eml-dev decision" would force us to re-code the EML generation. 2) From Taiwan, it is also a mix and match. I had the internationalization conversation years ago, when we set harvesting into the NBII clearinghouse. at the TFRI, we found EML documents that have a hybrid of english and chinese, with no sign or whatsoever of the language used. We had to devise a mechanism to detect language. We simply did not harvest those docs whose critical content was not translated in English. ILTER discussed (two years ago?) some guidelines on how the different countries were going to deal with the tower of Babel problem. May be you can look into those if you feel curious, but if I recall correctly, it went along the lines of encoding the metadata in the native language, and produce some discovery-level EML in English. This strategy would create two EMLs per EML.. Sparks or not, I still have to recommend the EML users to implement some solution. Im inclined to suggest that such solution 1) does not break the current EML rules. 2) The solution should allow for easy language detection. Spain's case fits here, for example. Cheers, inigo On 9/16/2010 10:56 AM, ben leinfelder wrote: > Hi Markus, > I'm afraid your findings are accurate with respect to the xml:lang attribute in the element (or any "NonEmptyStringType" element). > In the course of my experimentation with allowing backwards-compatible internationalization with a new EML version (2.1.1) I did have to include the "http://www.w3.org/XML/1998/namespace" namespace just as you did and also declare the xml:lang attribute in elements where I wanted to employ it. > While certain EML elements are repeatable, it's not always clear what the presence of multiple elements represent (are they translations in different languages or are they alternate titles?). In order to clarify this confusion and also allow multiple translations for non-repeatable elements I proposed a solution for allowing mixed element content for fields that should be internationalized. There's a fairly comprehensive discussion of this approach in our eml-dev archives: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html > I didn't get a lot of decisive feedback and so have not moved forward with releasing an updated EML version. Hopefully this thread will again set the ball rolling. > -ben > .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev From jones at nceas.ucsb.edu Thu Sep 16 12:56:43 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Thu, 16 Sep 2010 11:56:43 -0800 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <4C927166.2050001@canyon.lternet.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> Message-ID: <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> The solution that Ben proposed is meant to address the requirements that arose from the iLTER Lake Taihu meeting for providing core metadata in multiple languages. These recommendations then were also at the core of the recommendations made to GBIF about which fields should contain English translations, but the set of fields differs slightly in the two recommendations. Because many of these fields are not currently repeatable according to the EML 2.1 schema, we would need to, at a minumum, change cardinality rules to allow for each field to be included multiple times if the xml:lang tag were used to differentiate them (or for the approach Inigo points to). As Ben points out, it would still be ambiguous as to whether the repeating fields represent different information, or the same information translated. So his proposal is meant to explicitly flag translations as such within mixed content string fields, with the goal of doing so without breaking existing EML 2.1 compatibility and without having to change existing cardinality rules. Ben's prior discussion on this highlighted the conflict with the NonEmptyString type that was introduced in EML 2.1, in that mixed content elements would not be validated and so the rules for NonEmptyString would not be enforced. I think this would only be a small issue, and that the advantages in compatibility provided by using a mixed content model for language translations outweigh the loss of validation within our string types. Either way, we would need to add the xml:lang attribute so that it can be used throughout EML, including in the translation elements that Ben proposed. Are there any objections to moving forward with the schema changes to use a mixed content models for translations that Ben proposed in his earlier emails? Matt On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu>wrote: > > We'll keep our eyes on the ball, then. > > Meanwhile others have adopted their own solution. > Here are two examples: > 1) a site from Spain reports this implementation > > <title>[Language:En]Snow cover data provided by MODIS satellite > imagery > [Language:Sp]Datos de innivación según imágenes > MODIS > > We thought that the use of the XML attribute "lang=en | sp" > was interesting -but, among other problems, we would have > gotten screwed by eml-dev eventual internationalization > implementation. Call it luck, but you can bet the "eventual > eml-dev decision" would force us to re-code the EML > generation. > > 2) From Taiwan, it is also a mix and match. I had the > internationalization conversation years ago, when we set > harvesting into the NBII clearinghouse. at the TFRI, we > found EML documents that have a hybrid of english and > chinese, with no sign or whatsoever of the language used. > We had to devise a mechanism to detect language. We > simply did not harvest those docs whose critical content > was not translated in English. > > ILTER discussed (two years ago?) some guidelines on > how the different countries were going to deal with the > tower of Babel problem. May be you can look into those > if you feel curious, but if I recall correctly, it went along > the lines of encoding the metadata in the native language, > and produce some discovery-level EML in English. This > strategy would create two EMLs per EML.. > > Sparks or not, I still have to recommend the EML users > to implement some solution. Im inclined to suggest that > such solution 1) does not break the current EML rules. > 2) The solution should allow for easy language detection. > Spain's case fits here, for example. > > Cheers, inigo > > > > > > On 9/16/2010 10:56 AM, ben leinfelder wrote: > >> Hi Markus, >> I'm afraid your findings are accurate with respect to the xml:lang >> attribute in the element (or any "NonEmptyStringType" element). >> In the course of my experimentation with allowing backwards-compatible >> internationalization with a new EML version (2.1.1) I did have to include >> the "http://www.w3.org/XML/1998/namespace" namespace just as you did and >> also declare the xml:lang attribute in elements where I wanted to employ it. >> While certain EML elements are repeatable, it's not always clear what the >> presence of multiple elements represent (are they translations in different >> languages or are they alternate titles?). In order to clarify this confusion >> and also allow multiple translations for non-repeatable elements I proposed >> a solution for allowing mixed element content for fields that should be >> internationalized. There's a fairly comprehensive discussion of this >> approach in our eml-dev archives: >> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >> I didn't get a lot of decisive feedback and so have not moved forward with >> releasing an updated EML version. Hopefully this thread will again set the >> ball rolling. >> -ben >> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100916/b8969294/attachment.html> From dblankman1 at gmail.com Thu Sep 16 13:19:23 2010 From: dblankman1 at gmail.com (David Blankman) Date: Thu, 16 Sep 2010 22:19:23 +0200 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> Message-ID: <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> Matt and EML-Dev, I think that Ben's solution should be pushed forward. At the ILTER level we are starting to push strongly for EML documents from ILTER member networks. Having a solution that allows for multiple languages in a single document is certainly preferable to two EML documents for the same dataset. By the way, at the ILTER meeting earlier this month, I got elected to be the new Chair of the ILTER IM Committee. Kristin has been made co-chair of the US-ILTER committee. One of her tasks will be to encourage US LTER researchers to start pursuing global synthetic research. Having a clear approach to handling EML will help to move this forward. David ??????????????????? Everything is possible with a chocolate cookie! - Rabbi Herbie of Jerusalem If I am not for myself, then who will be for me? If I am for myself alone, then who am I? If not now, when? - Rabbi Hillel On Thu, Sep 16, 2010 at 9:56 PM, Matt Jones <jones at nceas.ucsb.edu> wrote: > The solution that Ben proposed is meant to address the requirements that > arose from the iLTER Lake Taihu meeting for providing core metadata in > multiple languages. These recommendations then were also at the core of the > recommendations made to GBIF about which fields should contain English > translations, but the set of fields differs slightly in the two > recommendations. Because many of these fields are not currently repeatable > according to the EML 2.1 schema, we would need to, at a minumum, change > cardinality rules to allow for each field to be included multiple times if > the xml:lang tag were used to differentiate them (or for the approach Inigo > points to). As Ben points out, it would still be ambiguous as to whether > the repeating fields represent different information, or the same > information translated. So his proposal is meant to explicitly flag > translations as such within mixed content string fields, with the goal of > doing so without breaking existing EML 2.1 compatibility and without having > to change existing cardinality rules. > > Ben's prior discussion on this highlighted the conflict with the > NonEmptyString type that was introduced in EML 2.1, in that mixed content > elements would not be validated and so the rules for NonEmptyString would > not be enforced. I think this would only be a small issue, and that the > advantages in compatibility provided by using a mixed content model for > language translations outweigh the loss of validation within our string > types. Either way, we would need to add the xml:lang attribute so that it > can be used throughout EML, including in the translation elements that Ben > proposed. > > Are there any objections to moving forward with the schema changes to use a > mixed content models for translations that Ben proposed in his earlier > emails? > > Matt > > On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil < > isangil at canyon.lternet.edu> wrote: > >> >> We'll keep our eyes on the ball, then. >> >> Meanwhile others have adopted their own solution. >> Here are two examples: >> 1) a site from Spain reports this implementation >> >> <title>[Language:En]Snow cover data provided by MODIS satellite >> imagery >> [Language:Sp]Datos de innivación según imágenes >> MODIS >> >> We thought that the use of the XML attribute "lang=en | sp" >> was interesting -but, among other problems, we would have >> gotten screwed by eml-dev eventual internationalization >> implementation. Call it luck, but you can bet the "eventual >> eml-dev decision" would force us to re-code the EML >> generation. >> >> 2) From Taiwan, it is also a mix and match. I had the >> internationalization conversation years ago, when we set >> harvesting into the NBII clearinghouse. at the TFRI, we >> found EML documents that have a hybrid of english and >> chinese, with no sign or whatsoever of the language used. >> We had to devise a mechanism to detect language. We >> simply did not harvest those docs whose critical content >> was not translated in English. >> >> ILTER discussed (two years ago?) some guidelines on >> how the different countries were going to deal with the >> tower of Babel problem. May be you can look into those >> if you feel curious, but if I recall correctly, it went along >> the lines of encoding the metadata in the native language, >> and produce some discovery-level EML in English. This >> strategy would create two EMLs per EML.. >> >> Sparks or not, I still have to recommend the EML users >> to implement some solution. Im inclined to suggest that >> such solution 1) does not break the current EML rules. >> 2) The solution should allow for easy language detection. >> Spain's case fits here, for example. >> >> Cheers, inigo >> >> >> >> >> >> On 9/16/2010 10:56 AM, ben leinfelder wrote: >> >>> Hi Markus, >>> I'm afraid your findings are accurate with respect to the xml:lang >>> attribute in the element (or any "NonEmptyStringType" element). >>> In the course of my experimentation with allowing backwards-compatible >>> internationalization with a new EML version (2.1.1) I did have to include >>> the "http://www.w3.org/XML/1998/namespace" namespace just as you did and >>> also declare the xml:lang attribute in elements where I wanted to employ it. >>> While certain EML elements are repeatable, it's not always clear what the >>> presence of multiple elements represent (are they translations in different >>> languages or are they alternate titles?). In order to clarify this confusion >>> and also allow multiple translations for non-repeatable elements I proposed >>> a solution for allowing mixed element content for fields that should be >>> internationalized. There's a fairly comprehensive discussion of this >>> approach in our eml-dev archives: >>> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >>> I didn't get a lot of decisive feedback and so have not moved forward >>> with releasing an updated EML version. Hopefully this thread will again set >>> the ball rolling. >>> -ben >>> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100916/dc73e450/attachment-0001.html> From isangil at canyon.lternet.edu Thu Sep 16 13:46:16 2010 From: isangil at canyon.lternet.edu (Inigo San Gil) Date: Thu, 16 Sep 2010 14:46:16 -0600 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> Message-ID: <4C928218.1000906@canyon.lternet.edu> David, Congrats on the ILTER election - you bring quality experience there. As for objections, I just wouldnt know what to object to :) .. I dont see specifics. The quoted text below is the language I see closest to a specific solution to this issue. [...] I proposed a solution for allowing mixed element content for fields that should be internationalized. [...] -EML 2.1.1 would be a more relaxed schema than the current EML 2.1.0 -we could augment existing EML-specific parsers to perform additional checks on the mixed content after schema-based validation was performed. -Metacat already includes [...] -The EML project has a utility parser that [...] It sounds good to me, more details welcomed. Inigo On 9/16/2010 2:19 PM, David Blankman wrote: > Matt and EML-Dev, > > I think that Ben's solution should be pushed forward. At the ILTER > level we are starting to push strongly for EML documents from ILTER > member networks. Having a solution that allows for multiple languages > in a single document is certainly preferable to two EML documents for > the same dataset. > > By the way, at the ILTER meeting earlier this month, I got elected to > be the new Chair of the ILTER IM Committee. Kristin has been made > co-chair of the US-ILTER committee. One of her tasks will be to > encourage US LTER researchers to start pursuing global synthetic > research. Having a clear approach to handling EML will help to move > this forward. > > David > ??????????????????? > Everything is possible with a chocolate cookie! > - Rabbi Herbie of Jerusalem > > If I am not for myself, then who will be for me? If I am for myself > alone, then who am I? If not now, when? > - Rabbi Hillel > > > On Thu, Sep 16, 2010 at 9:56 PM, Matt Jones <jones at nceas.ucsb.edu > <mailto:jones at nceas.ucsb.edu>> wrote: > > The solution that Ben proposed is meant to address the > requirements that arose from the iLTER Lake Taihu meeting for > providing core metadata in multiple languages. These > recommendations then were also at the core of the recommendations > made to GBIF about which fields should contain English > translations, but the set of fields differs slightly in the two > recommendations. Because many of these fields are not currently > repeatable according to the EML 2.1 schema, we would need to, at a > minumum, change cardinality rules to allow for each field to be > included multiple times if the xml:lang tag were used to > differentiate them (or for the approach Inigo points to). As Ben > points out, it would still be ambiguous as to whether the > repeating fields represent different information, or the same > information translated. So his proposal is meant to explicitly > flag translations as such within mixed content string fields, with > the goal of doing so without breaking existing EML 2.1 > compatibility and without having to change existing cardinality > rules. > > Ben's prior discussion on this highlighted the conflict with the > NonEmptyString type that was introduced in EML 2.1, in that mixed > content elements would not be validated and so the rules for > NonEmptyString would not be enforced. I think this would only be > a small issue, and that the advantages in compatibility provided > by using a mixed content model for language translations outweigh > the loss of validation within our string types. Either way, we > would need to add the xml:lang attribute so that it can be used > throughout EML, including in the translation elements that Ben > proposed. > > Are there any objections to moving forward with the schema changes > to use a mixed content models for translations that Ben proposed > in his earlier emails? > > Matt > > On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil > <isangil at canyon.lternet.edu <mailto:isangil at canyon.lternet.edu>> > wrote: > > > We'll keep our eyes on the ball, then. > > Meanwhile others have adopted their own solution. > Here are two examples: > 1) a site from Spain reports this implementation > > <title>[Language:En]Snow cover data provided by MODIS > satellite imagery > [Language:Sp]Datos de innivación según > imágenes MODIS > > We thought that the use of the XML attribute "lang=en | sp" > was interesting -but, among other problems, we would have > gotten screwed by eml-dev eventual internationalization > implementation. Call it luck, but you can bet the "eventual > eml-dev decision" would force us to re-code the EML > generation. > > 2) From Taiwan, it is also a mix and match. I had the > internationalization conversation years ago, when we set > harvesting into the NBII clearinghouse. at the TFRI, we > found EML documents that have a hybrid of english and > chinese, with no sign or whatsoever of the language used. > We had to devise a mechanism to detect language. We > simply did not harvest those docs whose critical content > was not translated in English. > > ILTER discussed (two years ago?) some guidelines on > how the different countries were going to deal with the > tower of Babel problem. May be you can look into those > if you feel curious, but if I recall correctly, it went along > the lines of encoding the metadata in the native language, > and produce some discovery-level EML in English. This > strategy would create two EMLs per EML.. > > Sparks or not, I still have to recommend the EML users > to implement some solution. Im inclined to suggest that > such solution 1) does not break the current EML rules. > 2) The solution should allow for easy language detection. > Spain's case fits here, for example. > > Cheers, inigo > > > > > > On 9/16/2010 10:56 AM, ben leinfelder wrote: > > Hi Markus, > I'm afraid your findings are accurate with respect to the > xml:lang attribute in the element (or any > "NonEmptyStringType" element). > In the course of my experimentation with allowing > backwards-compatible internationalization with a new EML > version (2.1.1) I did have to include the > "http://www.w3.org/XML/1998/namespace" namespace just as > you did and also declare the xml:lang attribute in > elements where I wanted to employ it. > While certain EML elements are repeatable, it's not always > clear what the presence of multiple elements represent > (are they translations in different languages or are they > alternate titles?). In order to clarify this confusion and > also allow multiple translations for non-repeatable > elements I proposed a solution for allowing mixed element > content for fields that should be internationalized. > There's a fairly comprehensive discussion of this approach > in our eml-dev archives: > http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html > I didn't get a lot of decisive feedback and so have not > moved forward with releasing an updated EML version. > Hopefully this thread will again set the ball rolling. > -ben > .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100916/b3963b1e/attachment.html> From jones at nceas.ucsb.edu Thu Sep 16 17:04:54 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Thu, 16 Sep 2010 16:04:54 -0800 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <4C928218.1000906@canyon.lternet.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> <4C928218.1000906@canyon.lternet.edu> Message-ID: <AANLkTimXUL-HeOETMd5N-f=zAai7xpiDSkvsJdnhPX-r@mail.gmail.com> Inigo -- If you look a little deeper into that thread that Ben cited, you'll see a link to the summary of the changes, which is in Bugzilla here: *http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585#c5* The details are of course in the changed XSD files for EML in the svn repository, but that summary and the comments in the email thread that Ben cited about downsides of this approach should be enough to evaluate things. Matt On Thu, Sep 16, 2010 at 12:46 PM, Inigo San Gil <isangil at canyon.lternet.edu>wrote: > > > David, Congrats on the ILTER election - you bring quality experience there. > > As for objections, I just wouldnt know what to object to :) .. I dont > see specifics. The quoted text below is the language I see closest > to a specific solution to this issue. > > [...] > I proposed a solution for allowing mixed element content for fields that should be internationalized. > > [...] > -EML 2.1.1 would be a more relaxed schema than the current EML 2.1.0 > -we could augment existing EML-specific parsers to perform additional checks on the mixed content after schema-based validation was performed. > -Metacat already includes [...] > -The EML project has a utility parser that [...] > > > It sounds good to me, more details welcomed. > > Inigo > > > On 9/16/2010 2:19 PM, David Blankman wrote: > > Matt and EML-Dev, > > I think that Ben's solution should be pushed forward. At the ILTER level > we are starting to push strongly for EML documents from ILTER member > networks. Having a solution that allows for multiple languages in a single > document is certainly preferable to two EML documents for the same dataset. > > By the way, at the ILTER meeting earlier this month, I got elected to be > the new Chair of the ILTER IM Committee. Kristin has been made co-chair of > the US-ILTER committee. One of her tasks will be to encourage US LTER > researchers to start pursuing global synthetic research. Having a clear > approach to handling EML will help to move this forward. > > David > ??????????????????? > Everything is possible with a chocolate cookie! > - Rabbi Herbie of Jerusalem > > If I am not for myself, then who will be for me? If I am for myself alone, > then who am I? If not now, when? > - Rabbi Hillel > > > On Thu, Sep 16, 2010 at 9:56 PM, Matt Jones <jones at nceas.ucsb.edu> wrote: > >> The solution that Ben proposed is meant to address the requirements that >> arose from the iLTER Lake Taihu meeting for providing core metadata in >> multiple languages. These recommendations then were also at the core of the >> recommendations made to GBIF about which fields should contain English >> translations, but the set of fields differs slightly in the two >> recommendations. Because many of these fields are not currently repeatable >> according to the EML 2.1 schema, we would need to, at a minumum, change >> cardinality rules to allow for each field to be included multiple times if >> the xml:lang tag were used to differentiate them (or for the approach Inigo >> points to). As Ben points out, it would still be ambiguous as to whether >> the repeating fields represent different information, or the same >> information translated. So his proposal is meant to explicitly flag >> translations as such within mixed content string fields, with the goal of >> doing so without breaking existing EML 2.1 compatibility and without having >> to change existing cardinality rules. >> >> Ben's prior discussion on this highlighted the conflict with the >> NonEmptyString type that was introduced in EML 2.1, in that mixed content >> elements would not be validated and so the rules for NonEmptyString would >> not be enforced. I think this would only be a small issue, and that the >> advantages in compatibility provided by using a mixed content model for >> language translations outweigh the loss of validation within our string >> types. Either way, we would need to add the xml:lang attribute so that it >> can be used throughout EML, including in the translation elements that Ben >> proposed. >> >> Are there any objections to moving forward with the schema changes to >> use a mixed content models for translations that Ben proposed in his earlier >> emails? >> >> Matt >> >> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil < >> isangil at canyon.lternet.edu> wrote: >> >>> >>> We'll keep our eyes on the ball, then. >>> >>> Meanwhile others have adopted their own solution. >>> Here are two examples: >>> 1) a site from Spain reports this implementation >>> >>> <title>[Language:En]Snow cover data provided by MODIS satellite >>> imagery >>> [Language:Sp]Datos de innivación según imágenes >>> MODIS >>> >>> We thought that the use of the XML attribute "lang=en | sp" >>> was interesting -but, among other problems, we would have >>> gotten screwed by eml-dev eventual internationalization >>> implementation. Call it luck, but you can bet the "eventual >>> eml-dev decision" would force us to re-code the EML >>> generation. >>> >>> 2) From Taiwan, it is also a mix and match. I had the >>> internationalization conversation years ago, when we set >>> harvesting into the NBII clearinghouse. at the TFRI, we >>> found EML documents that have a hybrid of english and >>> chinese, with no sign or whatsoever of the language used. >>> We had to devise a mechanism to detect language. We >>> simply did not harvest those docs whose critical content >>> was not translated in English. >>> >>> ILTER discussed (two years ago?) some guidelines on >>> how the different countries were going to deal with the >>> tower of Babel problem. May be you can look into those >>> if you feel curious, but if I recall correctly, it went along >>> the lines of encoding the metadata in the native language, >>> and produce some discovery-level EML in English. This >>> strategy would create two EMLs per EML.. >>> >>> Sparks or not, I still have to recommend the EML users >>> to implement some solution. Im inclined to suggest that >>> such solution 1) does not break the current EML rules. >>> 2) The solution should allow for easy language detection. >>> Spain's case fits here, for example. >>> >>> Cheers, inigo >>> >>> >>> >>> >>> >>> On 9/16/2010 10:56 AM, ben leinfelder wrote: >>> >>>> Hi Markus, >>>> I'm afraid your findings are accurate with respect to the xml:lang >>>> attribute in the element (or any "NonEmptyStringType" element). >>>> In the course of my experimentation with allowing backwards-compatible >>>> internationalization with a new EML version (2.1.1) I did have to include >>>> the "http://www.w3.org/XML/1998/namespace" namespace just as you did >>>> and also declare the xml:lang attribute in elements where I wanted to employ >>>> it. >>>> While certain EML elements are repeatable, it's not always clear what >>>> the presence of multiple elements represent (are they translations in >>>> different languages or are they alternate titles?). In order to clarify this >>>> confusion and also allow multiple translations for non-repeatable elements I >>>> proposed a solution for allowing mixed element content for fields that >>>> should be internationalized. There's a fairly comprehensive discussion of >>>> this approach in our eml-dev archives: >>>> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >>>> I didn't get a lot of decisive feedback and so have not moved forward >>>> with releasing an updated EML version. Hopefully this thread will again set >>>> the ball rolling. >>>> -ben >>>> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>> >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> > > _______________________________________________ > Eml-dev mailing listEml-dev at ecoinformatics.orghttp://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100916/c9df4c52/attachment-0001.html> From leinfelder at nceas.ucsb.edu Thu Sep 16 19:14:20 2010 From: leinfelder at nceas.ucsb.edu (ben leinfelder) Date: Thu, 16 Sep 2010 19:14:20 -0700 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTimXUL-HeOETMd5N-f=zAai7xpiDSkvsJdnhPX-r@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> <4C928218.1000906@canyon.lternet.edu> <AANLkTimXUL-HeOETMd5N-f=zAai7xpiDSkvsJdnhPX-r@mail.gmail.com> Message-ID: <8B3F8D72-2362-4350-875F-FBBED8D41A2C@nceas.ucsb.edu> All - I've gone ahead and committed EML schema changes that allow internationalization of 'title' and 'keyword' elements: https://code.ecoinformatics.org/code/eml/trunk/eml-resource.xsd and also 'abstract' elements (as well as any DocBook-based elements in EML): https://code.ecoinformatics.org/code/eml/trunk/eml-text.xsd In terms of 'basic metadata', the marked items remain: -Identifier -Title -Abstract -Keywords **-Creator **-Contact **-Metadata Publisher I believe the Identifier need not be internationalized as this is a special string. The other fields describe a person's name or an organization's name, address, phone, email and other contact details - should these allow for multiple translations? If you would like to see other EML elements internationalized please let me know. Thanks, -ben On Sep 16, 2010, at 5:04 PM, Matt Jones wrote: > Inigo -- > > If you look a little deeper into that thread that Ben cited, you'll see a link to the summary of the changes, which is in Bugzilla here: > http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585#c5 > The details are of course in the changed XSD files for EML in the svn repository, but that summary and the comments in the email thread that Ben cited about downsides of this approach should be enough to evaluate things. > > Matt > > On Thu, Sep 16, 2010 at 12:46 PM, Inigo San Gil <isangil at canyon.lternet.edu> wrote: > > > David, Congrats on the ILTER election - you bring quality experience there. > > As for objections, I just wouldnt know what to object to :) .. I dont > see specifics. The quoted text below is the language I see closest > to a specific solution to this issue. > [...] > I proposed a solution for allowing mixed element content for fields that should be internationalized. > > [...] > -EML 2.1.1 would be a more relaxed schema than the current EML 2.1.0 > -we could augment existing EML-specific parsers to perform additional checks on the mixed content after schema-based validation was performed. > -Metacat already includes [...] > -The EML project has a utility parser that [...] > > > It sounds good to me, more details welcomed. > > Inigo > > > On 9/16/2010 2:19 PM, David Blankman wrote: >> Matt and EML-Dev, >> >> I think that Ben's solution should be pushed forward. At the ILTER level we are starting to push strongly for EML documents from ILTER member networks. Having a solution that allows for multiple languages in a single document is certainly preferable to two EML documents for the same dataset. >> >> By the way, at the ILTER meeting earlier this month, I got elected to be the new Chair of the ILTER IM Committee. Kristin has been made co-chair of the US-ILTER committee. One of her tasks will be to encourage US LTER researchers to start pursuing global synthetic research. Having a clear approach to handling EML will help to move this forward. >> >> David >> ??????????????????? >> Everything is possible with a chocolate cookie! >> - Rabbi Herbie of Jerusalem >> >> If I am not for myself, then who will be for me? If I am for myself alone, then who am I? If not now, when? >> - Rabbi Hillel >> >> >> On Thu, Sep 16, 2010 at 9:56 PM, Matt Jones <jones at nceas.ucsb.edu> wrote: >> The solution that Ben proposed is meant to address the requirements that arose from the iLTER Lake Taihu meeting for providing core metadata in multiple languages. These recommendations then were also at the core of the recommendations made to GBIF about which fields should contain English translations, but the set of fields differs slightly in the two recommendations. Because many of these fields are not currently repeatable according to the EML 2.1 schema, we would need to, at a minumum, change cardinality rules to allow for each field to be included multiple times if the xml:lang tag were used to differentiate them (or for the approach Inigo points to). As Ben points out, it would still be ambiguous as to whether the repeating fields represent different information, or the same information translated. So his proposal is meant to explicitly flag translations as such within mixed content string fields, with the goal of doing so without breaking existing EML 2.1 compatibility and without having to change existing cardinality rules. >> >> Ben's prior discussion on this highlighted the conflict with the NonEmptyString type that was introduced in EML 2.1, in that mixed content elements would not be validated and so the rules for NonEmptyString would not be enforced. I think this would only be a small issue, and that the advantages in compatibility provided by using a mixed content model for language translations outweigh the loss of validation within our string types. Either way, we would need to add the xml:lang attribute so that it can be used throughout EML, including in the translation elements that Ben proposed. >> >> Are there any objections to moving forward with the schema changes to use a mixed content models for translations that Ben proposed in his earlier emails? >> >> Matt >> >> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu> wrote: >> >> We'll keep our eyes on the ball, then. >> >> Meanwhile others have adopted their own solution. >> Here are two examples: >> 1) a site from Spain reports this implementation >> >> <title>[Language:En]Snow cover data provided by MODIS satellite imagery >> [Language:Sp]Datos de innivación según imágenes MODIS >> >> We thought that the use of the XML attribute "lang=en | sp" >> was interesting -but, among other problems, we would have >> gotten screwed by eml-dev eventual internationalization >> implementation. Call it luck, but you can bet the "eventual >> eml-dev decision" would force us to re-code the EML >> generation. >> >> 2) From Taiwan, it is also a mix and match. I had the >> internationalization conversation years ago, when we set >> harvesting into the NBII clearinghouse. at the TFRI, we >> found EML documents that have a hybrid of english and >> chinese, with no sign or whatsoever of the language used. >> We had to devise a mechanism to detect language. We >> simply did not harvest those docs whose critical content >> was not translated in English. >> >> ILTER discussed (two years ago?) some guidelines on >> how the different countries were going to deal with the >> tower of Babel problem. May be you can look into those >> if you feel curious, but if I recall correctly, it went along >> the lines of encoding the metadata in the native language, >> and produce some discovery-level EML in English. This >> strategy would create two EMLs per EML.. >> >> Sparks or not, I still have to recommend the EML users >> to implement some solution. Im inclined to suggest that >> such solution 1) does not break the current EML rules. >> 2) The solution should allow for easy language detection. >> Spain's case fits here, for example. >> >> Cheers, inigo >> >> >> >> >> >> On 9/16/2010 10:56 AM, ben leinfelder wrote: >> Hi Markus, >> I'm afraid your findings are accurate with respect to the xml:lang attribute in the element (or any "NonEmptyStringType" element). >> In the course of my experimentation with allowing backwards-compatible internationalization with a new EML version (2.1.1) I did have to include the "http://www.w3.org/XML/1998/namespace" namespace just as you did and also declare the xml:lang attribute in elements where I wanted to employ it. >> While certain EML elements are repeatable, it's not always clear what the presence of multiple elements represent (are they translations in different languages or are they alternate titles?). In order to clarify this confusion and also allow multiple translations for non-repeatable elements I proposed a solution for allowing mixed element content for fields that should be internationalized. There's a fairly comprehensive discussion of this approach in our eml-dev archives: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >> I didn't get a lot of decisive feedback and so have not moved forward with releasing an updated EML version. Hopefully this thread will again set the ball rolling. >> -ben >> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> >> >> _______________________________________________ >> Eml-dev mailing list >> >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev From isangil at lternet.edu Thu Sep 16 19:14:41 2010 From: isangil at lternet.edu (inigo san gil) Date: Thu, 16 Sep 2010 20:14:41 -0600 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTimXUL-HeOETMd5N-f=zAai7xpiDSkvsJdnhPX-r@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <AANLkTikHa_3PVPxoxzohD==VVSBD5rVNRV-KfotS=Qjm@mail.gmail.com> <4C928218.1000906@canyon.lternet.edu> <AANLkTimXUL-HeOETMd5N-f=zAai7xpiDSkvsJdnhPX-r@mail.gmail.com> Message-ID: <4C92CF11.8030901@lternet.edu> Ok, are you guys proposing comment 5 change in that URL ? <xs:complexType name="i18nNonEmptyStringType" mixed="true"> <xs:sequence> <xs:element name="value" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="NonEmptyStringType"> <xs:attribute ref="xml:lang" /> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> This seems to embed the <value> tag, whcih can carry the touted "lang" attribute. That seems a fine solution, quite easy to account for and parse. The new option flags well mixed or bilingual (trilingual or more for some regions!) content. The solution forces embedding content in an extra tag if the metadata provider wants to underscore different languages. Not too bad, since EML needs some sort of solution before we all do what we think it is a plausible bilingualism! he backward compatibility is a big plus - since the new tag is optional (minOccurs=0), it would seem that monolingual documents may default to the native language, and the editors/parser/repositories would not have to do anything about it - all business as usual. In sum, I dont see a problem with this, and I think we may make compliant existing mixed content (bilingual) documents with not a whole lot of effort. Look, there is no perfect solution, this seems fine for now. Some overhead work (parsers, editors, repositories) is OK, EML gains on internationalization! Inigo Matt Jones wrote: > Inigo -- > > If you look a little deeper into that thread that Ben cited, you'll > see a link to the summary of the changes, which is in Bugzilla here: > /http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585#c5/ > The details are of course in the changed XSD files for EML in the svn > repository, but that summary and the comments in the email thread that > Ben cited about downsides of this approach should be enough to > evaluate things. > > Matt > > On Thu, Sep 16, 2010 at 12:46 PM, Inigo San Gil > <isangil at canyon.lternet.edu <mailto:isangil at canyon.lternet.edu>> wrote: > > > > David, Congrats on the ILTER election - you bring quality > experience there. > > As for objections, I just wouldnt know what to object to :) .. > I dont > see specifics. The quoted text below is the language I see closest > to a specific solution to this issue. > > [...] > I proposed a solution for allowing mixed element content for fields that should be internationalized. > > [...] > -EML 2.1.1 would be a more relaxed schema than the current EML 2.1.0 > -we could augment existing EML-specific parsers to perform additional checks on the mixed content after schema-based validation was performed. > -Metacat already includes [...] > -The EML project has a utility parser that [...] > > > > It sounds good to me, more details welcomed. > > Inigo > > > On 9/16/2010 2:19 PM, David Blankman wrote: >> Matt and EML-Dev, >> >> I think that Ben's solution should be pushed forward. At the >> ILTER level we are starting to push strongly for EML documents >> from ILTER member networks. Having a solution that allows for >> multiple languages in a single document is certainly preferable >> to two EML documents for the same dataset. >> >> By the way, at the ILTER meeting earlier this month, I got >> elected to be the new Chair of the ILTER IM Committee. Kristin >> has been made co-chair of the US-ILTER committee. One of her >> tasks will be to encourage US LTER researchers to start pursuing >> global synthetic research. Having a clear approach to handling >> EML will help to move this forward. >> >> David >> ??????????????????? >> Everything is possible with a chocolate cookie! >> - Rabbi Herbie of Jerusalem >> >> If I am not for myself, then who will be for me? If I am for >> myself alone, then who am I? If not now, when? >> - Rabbi Hillel >> >> >> On Thu, Sep 16, 2010 at 9:56 PM, Matt Jones <jones at nceas.ucsb.edu >> <mailto:jones at nceas.ucsb.edu>> wrote: >> >> The solution that Ben proposed is meant to address the >> requirements that arose from the iLTER Lake Taihu meeting for >> providing core metadata in multiple languages. These >> recommendations then were also at the core of the >> recommendations made to GBIF about which fields should >> contain English translations, but the set of fields differs >> slightly in the two recommendations. Because many of these >> fields are not currently repeatable according to the EML 2.1 >> schema, we would need to, at a minumum, change cardinality >> rules to allow for each field to be included multiple times >> if the xml:lang tag were used to differentiate them (or for >> the approach Inigo points to). As Ben points out, it would >> still be ambiguous as to whether the repeating fields >> represent different information, or the same information >> translated. So his proposal is meant to explicitly flag >> translations as such within mixed content string fields, with >> the goal of doing so without breaking existing EML 2.1 >> compatibility and without having to change existing >> cardinality rules. >> >> Ben's prior discussion on this highlighted the conflict with >> the NonEmptyString type that was introduced in EML 2.1, in >> that mixed content elements would not be validated and so the >> rules for NonEmptyString would not be enforced. I think this >> would only be a small issue, and that the advantages in >> compatibility provided by using a mixed content model for >> language translations outweigh the loss of validation within >> our string types. Either way, we would need to add the >> xml:lang attribute so that it can be used throughout EML, >> including in the translation elements that Ben proposed. >> >> Are there any objections to moving forward with the schema >> changes to use a mixed content models for translations that >> Ben proposed in his earlier emails? >> >> Matt >> >> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil >> <isangil at canyon.lternet.edu >> <mailto:isangil at canyon.lternet.edu>> wrote: >> >> >> We'll keep our eyes on the ball, then. >> >> Meanwhile others have adopted their own solution. >> Here are two examples: >> 1) a site from Spain reports this implementation >> >> <title>[Language:En]Snow cover data provided by MODIS >> satellite imagery >> [Language:Sp]Datos de innivación según >> imágenes MODIS >> >> We thought that the use of the XML attribute "lang=en | sp" >> was interesting -but, among other problems, we would have >> gotten screwed by eml-dev eventual internationalization >> implementation. Call it luck, but you can bet the "eventual >> eml-dev decision" would force us to re-code the EML >> generation. >> >> 2) From Taiwan, it is also a mix and match. I had the >> internationalization conversation years ago, when we set >> harvesting into the NBII clearinghouse. at the TFRI, we >> found EML documents that have a hybrid of english and >> chinese, with no sign or whatsoever of the language used. >> We had to devise a mechanism to detect language. We >> simply did not harvest those docs whose critical content >> was not translated in English. >> >> ILTER discussed (two years ago?) some guidelines on >> how the different countries were going to deal with the >> tower of Babel problem. May be you can look into those >> if you feel curious, but if I recall correctly, it went along >> the lines of encoding the metadata in the native language, >> and produce some discovery-level EML in English. This >> strategy would create two EMLs per EML.. >> >> Sparks or not, I still have to recommend the EML users >> to implement some solution. Im inclined to suggest that >> such solution 1) does not break the current EML rules. >> 2) The solution should allow for easy language detection. >> Spain's case fits here, for example. >> >> Cheers, inigo >> >> >> >> >> >> On 9/16/2010 10:56 AM, ben leinfelder wrote: >> >> Hi Markus, >> I'm afraid your findings are accurate with respect to >> the xml:lang attribute in the element (or any >> "NonEmptyStringType" element). >> In the course of my experimentation with allowing >> backwards-compatible internationalization with a new >> EML version (2.1.1) I did have to include the >> "http://www.w3.org/XML/1998/namespace" namespace just >> as you did and also declare the xml:lang attribute in >> elements where I wanted to employ it. >> While certain EML elements are repeatable, it's not >> always clear what the presence of multiple elements >> represent (are they translations in different >> languages or are they alternate titles?). In order to >> clarify this confusion and also allow multiple >> translations for non-repeatable elements I proposed a >> solution for allowing mixed element content for >> fields that should be internationalized. There's a >> fairly comprehensive discussion of this approach in >> our eml-dev archives: >> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >> I didn't get a lot of decisive feedback and so have >> not moved forward with releasing an updated EML >> version. Hopefully this thread will again set the >> ball rolling. >> -ben >> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> <mailto:Eml-dev at ecoinformatics.org> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > From servilla at lternet.edu Thu Sep 16 19:18:38 2010 From: servilla at lternet.edu (Mark Servilla) Date: Thu, 16 Sep 2010 20:18:38 -0600 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> Message-ID: <4C92CFFE.6060909@lternet.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email - that is, the "mixed content" approach. It is not entirely clear what the long-term implications of the changes will be for parsing and validation, but the short-term approach seems manageable (albeit, with effort from some warm body). Internationalization of EML is a necessary step as we move research and its associated data/metadata to a global level. I personally do not see the alternatives as being viable long-term solutions. Multiple documents of differing languages will ultimately be too cumbersome and, likely, not kept synchronized. Introducing another inline content attribute (i.e., <title>[Language:En]Snow cover...) only adds yet more syntactical parsing issues. The use of the xml:lang attribute is, at least, a recognized and standard approach in many systems. I appreciate and thank Ben and others for their efforts in this matter. Sincerely, Mark On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: > The solution that Ben proposed is meant to address the requirements that arose > from the iLTER Lake Taihu meeting for providing core metadata in multiple > languages. These recommendations then were also at the core of the > recommendations made to GBIF about which fields should contain English > translations, but the set of fields differs slightly in the two recommendations. > Because many of these fields are not currently repeatable according to the EML > 2.1 schema, we would need to, at a minumum, change cardinality rules to allow > for each field to be included multiple times if the xml:lang tag were used to > differentiate them (or for the approach Inigo points to). As Ben points out, it > would still be ambiguous as to whether the repeating fields represent different > information, or the same information translated. So his proposal is meant to > explicitly flag translations as such within mixed content string fields, with > the goal of doing so without breaking existing EML 2.1 compatibility and without > having to change existing cardinality rules. > > Ben's prior discussion on this highlighted the conflict with the NonEmptyString > type that was introduced in EML 2.1, in that mixed content elements would not be > validated and so the rules for NonEmptyString would not be enforced. I think > this would only be a small issue, and that the advantages in compatibility > provided by using a mixed content model for language translations outweigh the > loss of validation within our string types. Either way, we would need to add > the xml:lang attribute so that it can be used throughout EML, including in the > translation elements that Ben proposed. > > Are there any objections to moving forward with the schema changes to use a > mixed content models for translations that Ben proposed in his earlier emails? > > Matt > > On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu > <mailto:isangil at canyon.lternet.edu>> wrote: > > > We'll keep our eyes on the ball, then. > > Meanwhile others have adopted their own solution. > Here are two examples: > 1) a site from Spain reports this implementation > > <title>[Language:En]Snow cover data provided by MODIS satellite imagery > [Language:Sp]Datos de innivación según imágenes > MODIS > > We thought that the use of the XML attribute "lang=en | sp" > was interesting -but, among other problems, we would have > gotten screwed by eml-dev eventual internationalization > implementation. Call it luck, but you can bet the "eventual > eml-dev decision" would force us to re-code the EML > generation. > > 2) From Taiwan, it is also a mix and match. I had the > internationalization conversation years ago, when we set > harvesting into the NBII clearinghouse. at the TFRI, we > found EML documents that have a hybrid of english and > chinese, with no sign or whatsoever of the language used. > We had to devise a mechanism to detect language. We > simply did not harvest those docs whose critical content > was not translated in English. > > ILTER discussed (two years ago?) some guidelines on > how the different countries were going to deal with the > tower of Babel problem. May be you can look into those > if you feel curious, but if I recall correctly, it went along > the lines of encoding the metadata in the native language, > and produce some discovery-level EML in English. This > strategy would create two EMLs per EML.. > > Sparks or not, I still have to recommend the EML users > to implement some solution. Im inclined to suggest that > such solution 1) does not break the current EML rules. > 2) The solution should allow for easy language detection. > Spain's case fits here, for example. > > Cheers, inigo > > > > > > On 9/16/2010 10:56 AM, ben leinfelder wrote: > > Hi Markus, > I'm afraid your findings are accurate with respect to the xml:lang > attribute in the element (or any "NonEmptyStringType" element). > In the course of my experimentation with allowing backwards-compatible > internationalization with a new EML version (2.1.1) I did have to > include the "http://www.w3.org/XML/1998/namespace" namespace just as you > did and also declare the xml:lang attribute in elements where I wanted > to employ it. > While certain EML elements are repeatable, it's not always clear what > the presence of multiple elements represent (are they translations in > different languages or are they alternate titles?). In order to clarify > this confusion and also allow multiple translations for non-repeatable > elements I proposed a solution for allowing mixed element content for > fields that should be internationalized. There's a fairly comprehensive > discussion of this approach in our eml-dev archives: > http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html > I didn't get a lot of decisive feedback and so have not moved forward > with releasing an updated EML version. Hopefully this thread will again > set the ball rolling. > -ben > .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev - -- Mark Servilla, Ph.D. LTER Network Office Department of Biology MSC 03 2020 1 University of New Mexico Albuquerque, NM 87131-0001 servilla at LTERnet.edu Office (505) 277-2619 Cell (505) 453-8593 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH z0YAn1HQNykMFDCt8zIm02bwMv5iecng =z21i -----END PGP SIGNATURE----- From jones at nceas.ucsb.edu Thu Sep 16 20:55:03 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Thu, 16 Sep 2010 19:55:03 -0800 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <4C92CFFE.6060909@lternet.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <4C92CFFE.6060909@lternet.edu> Message-ID: <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> Ben, I agree with you on the identifier and creator, contact, etc fields as not strictly needing translation. However, even some of those fields may benefit, such as the use of a name in Mandarin and its Romanized translation. Also, I think all of the fields that might allow for general text should be included, such as methods, etc. Certainly anything that accepts TextType might need to be translated in addition to the fields you listed. Does that sound reasonable? Matt On Thu, Sep 16, 2010 at 6:18 PM, Mark Servilla <servilla at lternet.edu> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email > - > that is, the "mixed content" approach. It is not entirely clear what the > long-term implications of the changes will be for parsing and validation, > but > the short-term approach seems manageable (albeit, with effort from some > warm > body). Internationalization of EML is a necessary step as we move research > and > its associated data/metadata to a global level. > > I personally do not see the alternatives as being viable long-term > solutions. > Multiple documents of differing languages will ultimately be too cumbersome > and, > likely, not kept synchronized. Introducing another inline content > attribute > (i.e., <title>[Language:En]Snow cover...) only adds yet more syntactical > parsing > issues. The use of the xml:lang attribute is, at least, a recognized and > standard approach in many systems. > > I appreciate and thank Ben and others for their efforts in this matter. > > Sincerely, > Mark > > On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: > > The solution that Ben proposed is meant to address the requirements that > arose > > from the iLTER Lake Taihu meeting for providing core metadata in multiple > > languages. These recommendations then were also at the core of the > > recommendations made to GBIF about which fields should contain English > > translations, but the set of fields differs slightly in the two > recommendations. > > Because many of these fields are not currently repeatable according to > the EML > > 2.1 schema, we would need to, at a minumum, change cardinality rules to > allow > > for each field to be included multiple times if the xml:lang tag were > used to > > differentiate them (or for the approach Inigo points to). As Ben points > out, it > > would still be ambiguous as to whether the repeating fields represent > different > > information, or the same information translated. So his proposal is > meant to > > explicitly flag translations as such within mixed content string fields, > with > > the goal of doing so without breaking existing EML 2.1 compatibility and > without > > having to change existing cardinality rules. > > > > Ben's prior discussion on this highlighted the conflict with the > NonEmptyString > > type that was introduced in EML 2.1, in that mixed content elements would > not be > > validated and so the rules for NonEmptyString would not be enforced. I > think > > this would only be a small issue, and that the advantages in > compatibility > > provided by using a mixed content model for language translations > outweigh the > > loss of validation within our string types. Either way, we would need to > add > > the xml:lang attribute so that it can be used throughout EML, including > in the > > translation elements that Ben proposed. > > > > Are there any objections to moving forward with the schema changes to use > a > > mixed content models for translations that Ben proposed in his earlier > emails? > > > > Matt > > > > On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil < > isangil at canyon.lternet.edu > > <mailto:isangil at canyon.lternet.edu>> wrote: > > > > > > We'll keep our eyes on the ball, then. > > > > Meanwhile others have adopted their own solution. > > Here are two examples: > > 1) a site from Spain reports this implementation > > > > <title>[Language:En]Snow cover data provided by MODIS satellite > imagery > > [Language:Sp]Datos de innivación según imágenes > > MODIS > > > > We thought that the use of the XML attribute "lang=en | sp" > > was interesting -but, among other problems, we would have > > gotten screwed by eml-dev eventual internationalization > > implementation. Call it luck, but you can bet the "eventual > > eml-dev decision" would force us to re-code the EML > > generation. > > > > 2) From Taiwan, it is also a mix and match. I had the > > internationalization conversation years ago, when we set > > harvesting into the NBII clearinghouse. at the TFRI, we > > found EML documents that have a hybrid of english and > > chinese, with no sign or whatsoever of the language used. > > We had to devise a mechanism to detect language. We > > simply did not harvest those docs whose critical content > > was not translated in English. > > > > ILTER discussed (two years ago?) some guidelines on > > how the different countries were going to deal with the > > tower of Babel problem. May be you can look into those > > if you feel curious, but if I recall correctly, it went along > > the lines of encoding the metadata in the native language, > > and produce some discovery-level EML in English. This > > strategy would create two EMLs per EML.. > > > > Sparks or not, I still have to recommend the EML users > > to implement some solution. Im inclined to suggest that > > such solution 1) does not break the current EML rules. > > 2) The solution should allow for easy language detection. > > Spain's case fits here, for example. > > > > Cheers, inigo > > > > > > > > > > > > On 9/16/2010 10:56 AM, ben leinfelder wrote: > > > > Hi Markus, > > I'm afraid your findings are accurate with respect to the > xml:lang > > attribute in the element (or any "NonEmptyStringType" > element). > > In the course of my experimentation with allowing > backwards-compatible > > internationalization with a new EML version (2.1.1) I did have to > > include the "http://www.w3.org/XML/1998/namespace" namespace > just as you > > did and also declare the xml:lang attribute in elements where I > wanted > > to employ it. > > While certain EML elements are repeatable, it's not always clear > what > > the presence of multiple elements represent (are they > translations in > > different languages or are they alternate titles?). In order to > clarify > > this confusion and also allow multiple translations for > non-repeatable > > elements I proposed a solution for allowing mixed element content > for > > fields that should be internationalized. There's a fairly > comprehensive > > discussion of this approach in our eml-dev archives: > > > http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html > > I didn't get a lot of decisive feedback and so have not moved > forward > > with releasing an updated EML version. Hopefully this thread will > again > > set the ball rolling. > > -ben > > .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> > > > > > > _______________________________________________ > > Eml-dev mailing list > > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > > > > > > > _______________________________________________ > > Eml-dev mailing list > > Eml-dev at ecoinformatics.org > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > - -- > Mark Servilla, Ph.D. > > LTER Network Office > Department of Biology > MSC 03 2020 > 1 University of New Mexico > Albuquerque, NM 87131-0001 > > servilla at LTERnet.edu > Office (505) 277-2619 > Cell (505) 453-8593 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH > z0YAn1HQNykMFDCt8zIm02bwMv5iecng > =z21i > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100916/19ed6fbc/attachment.html> From leinfelder at nceas.ucsb.edu Thu Sep 16 23:12:11 2010 From: leinfelder at nceas.ucsb.edu (ben leinfelder) Date: Thu, 16 Sep 2010 23:12:11 -0700 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <4C92CFFE.6060909@lternet.edu> <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> Message-ID: <7E74F0CF-9E37-4922-A769-D36318A39D0B@nceas.ucsb.edu> Matt, Looking over some TFRI business cards I have, I can certainly see a utility in allowing translations for contact information... I've augmented the eml-party schema to allow for internationalized values. Method steps are TextType (a la DocBook) and now support internationalization because of the changes I made to TextType for the 'abstract' element. The next step will be to update the EML namespace in the schema modules to reflect this minor update. I am targeting "eml://ecoinformatics.org/eml-2.1.1" unless anyone objects. Thanks, -ben On Sep 16, 2010, at 8:55 PM, Matt Jones wrote: > Ben, > > I agree with you on the identifier and creator, contact, etc fields as not strictly needing translation. However, even some of those fields may benefit, such as the use of a name in Mandarin and its Romanized translation. Also, I think all of the fields that might allow for general text should be included, such as methods, etc. Certainly anything that accepts TextType might need to be translated in addition to the fields you listed. Does that sound reasonable? > > Matt > > On Thu, Sep 16, 2010 at 6:18 PM, Mark Servilla <servilla at lternet.edu> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email - > that is, the "mixed content" approach. It is not entirely clear what the > long-term implications of the changes will be for parsing and validation, but > the short-term approach seems manageable (albeit, with effort from some warm > body). Internationalization of EML is a necessary step as we move research and > its associated data/metadata to a global level. > > I personally do not see the alternatives as being viable long-term solutions. > Multiple documents of differing languages will ultimately be too cumbersome and, > likely, not kept synchronized. Introducing another inline content attribute > (i.e., <title>[Language:En]Snow cover...) only adds yet more syntactical parsing > issues. The use of the xml:lang attribute is, at least, a recognized and > standard approach in many systems. > > I appreciate and thank Ben and others for their efforts in this matter. > > Sincerely, > Mark > > On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: > > The solution that Ben proposed is meant to address the requirements that arose > > from the iLTER Lake Taihu meeting for providing core metadata in multiple > > languages. These recommendations then were also at the core of the > > recommendations made to GBIF about which fields should contain English > > translations, but the set of fields differs slightly in the two recommendations. > > Because many of these fields are not currently repeatable according to the EML > > 2.1 schema, we would need to, at a minumum, change cardinality rules to allow > > for each field to be included multiple times if the xml:lang tag were used to > > differentiate them (or for the approach Inigo points to). As Ben points out, it > > would still be ambiguous as to whether the repeating fields represent different > > information, or the same information translated. So his proposal is meant to > > explicitly flag translations as such within mixed content string fields, with > > the goal of doing so without breaking existing EML 2.1 compatibility and without > > having to change existing cardinality rules. > > > > Ben's prior discussion on this highlighted the conflict with the NonEmptyString > > type that was introduced in EML 2.1, in that mixed content elements would not be > > validated and so the rules for NonEmptyString would not be enforced. I think > > this would only be a small issue, and that the advantages in compatibility > > provided by using a mixed content model for language translations outweigh the > > loss of validation within our string types. Either way, we would need to add > > the xml:lang attribute so that it can be used throughout EML, including in the > > translation elements that Ben proposed. > > > > Are there any objections to moving forward with the schema changes to use a > > mixed content models for translations that Ben proposed in his earlier emails? > > > > Matt > > > > On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu > > <mailto:isangil at canyon.lternet.edu>> wrote: > > > > > > We'll keep our eyes on the ball, then. > > > > Meanwhile others have adopted their own solution. > > Here are two examples: > > 1) a site from Spain reports this implementation > > > > <title>[Language:En]Snow cover data provided by MODIS satellite imagery > > [Language:Sp]Datos de innivación según imágenes > > MODIS > > > > We thought that the use of the XML attribute "lang=en | sp" > > was interesting -but, among other problems, we would have > > gotten screwed by eml-dev eventual internationalization > > implementation. Call it luck, but you can bet the "eventual > > eml-dev decision" would force us to re-code the EML > > generation. > > > > 2) From Taiwan, it is also a mix and match. I had the > > internationalization conversation years ago, when we set > > harvesting into the NBII clearinghouse. at the TFRI, we > > found EML documents that have a hybrid of english and > > chinese, with no sign or whatsoever of the language used. > > We had to devise a mechanism to detect language. We > > simply did not harvest those docs whose critical content > > was not translated in English. > > > > ILTER discussed (two years ago?) some guidelines on > > how the different countries were going to deal with the > > tower of Babel problem. May be you can look into those > > if you feel curious, but if I recall correctly, it went along > > the lines of encoding the metadata in the native language, > > and produce some discovery-level EML in English. This > > strategy would create two EMLs per EML.. > > > > Sparks or not, I still have to recommend the EML users > > to implement some solution. Im inclined to suggest that > > such solution 1) does not break the current EML rules. > > 2) The solution should allow for easy language detection. > > Spain's case fits here, for example. > > > > Cheers, inigo > > > > > > > > > > > > On 9/16/2010 10:56 AM, ben leinfelder wrote: > > > > Hi Markus, > > I'm afraid your findings are accurate with respect to the xml:lang > > attribute in the element (or any "NonEmptyStringType" element). > > In the course of my experimentation with allowing backwards-compatible > > internationalization with a new EML version (2.1.1) I did have to > > include the "http://www.w3.org/XML/1998/namespace" namespace just as you > > did and also declare the xml:lang attribute in elements where I wanted > > to employ it. > > While certain EML elements are repeatable, it's not always clear what > > the presence of multiple elements represent (are they translations in > > different languages or are they alternate titles?). In order to clarify > > this confusion and also allow multiple translations for non-repeatable > > elements I proposed a solution for allowing mixed element content for > > fields that should be internationalized. There's a fairly comprehensive > > discussion of this approach in our eml-dev archives: > > http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html > > I didn't get a lot of decisive feedback and so have not moved forward > > with releasing an updated EML version. Hopefully this thread will again > > set the ball rolling. > > -ben > > .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> > > > > > > _______________________________________________ > > Eml-dev mailing list > > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > > > > > > > _______________________________________________ > > Eml-dev mailing list > > Eml-dev at ecoinformatics.org > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > - -- > Mark Servilla, Ph.D. > > LTER Network Office > Department of Biology > MSC 03 2020 > 1 University of New Mexico > Albuquerque, NM 87131-0001 > > servilla at LTERnet.edu > Office (505) 277-2619 > Cell (505) 453-8593 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH > z0YAn1HQNykMFDCt8zIm02bwMv5iecng > =z21i > -----END PGP SIGNATURE----- > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev From mdoering at gbif.org Fri Sep 17 00:14:25 2010 From: mdoering at gbif.org (=?iso-8859-1?Q?=22Markus_D=F6ring_=28GBIF=29=22?=) Date: Fri, 17 Sep 2010 09:14:25 +0200 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <7E74F0CF-9E37-4922-A769-D36318A39D0B@nceas.ucsb.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <4C92CFFE.6060909@lternet.edu> <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> <7E74F0CF-9E37-4922-A769-D36318A39D0B@nceas.ucsb.edu> Message-ID: <D9845ED2-3BAB-4D51-BC1C-7C7434524BEE@gbif.org> Impressive. just woke up and all seems to be settled already. Im happy to see all those changes and the new namespace version. I will adapt the gbif recommended subset of eml to work with this 2.1.1 solution right now. Thanks so much, Markus On Sep 17, 2010, at 8:12, ben leinfelder wrote: > Matt, > Looking over some TFRI business cards I have, I can certainly see a utility in allowing translations for contact information... > I've augmented the eml-party schema to allow for internationalized values. > Method steps are TextType (a la DocBook) and now support internationalization because of the changes I made to TextType for the 'abstract' element. > > The next step will be to update the EML namespace in the schema modules to reflect this minor update. I am targeting "eml://ecoinformatics.org/eml-2.1.1" unless anyone objects. > Thanks, > -ben > > > On Sep 16, 2010, at 8:55 PM, Matt Jones wrote: > >> Ben, >> >> I agree with you on the identifier and creator, contact, etc fields as not strictly needing translation. However, even some of those fields may benefit, such as the use of a name in Mandarin and its Romanized translation. Also, I think all of the fields that might allow for general text should be included, such as methods, etc. Certainly anything that accepts TextType might need to be translated in addition to the fields you listed. Does that sound reasonable? >> >> Matt >> >> On Thu, Sep 16, 2010 at 6:18 PM, Mark Servilla <servilla at lternet.edu> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email - >> that is, the "mixed content" approach. It is not entirely clear what the >> long-term implications of the changes will be for parsing and validation, but >> the short-term approach seems manageable (albeit, with effort from some warm >> body). Internationalization of EML is a necessary step as we move research and >> its associated data/metadata to a global level. >> >> I personally do not see the alternatives as being viable long-term solutions. >> Multiple documents of differing languages will ultimately be too cumbersome and, >> likely, not kept synchronized. Introducing another inline content attribute >> (i.e., <title>[Language:En]Snow cover...) only adds yet more syntactical parsing >> issues. The use of the xml:lang attribute is, at least, a recognized and >> standard approach in many systems. >> >> I appreciate and thank Ben and others for their efforts in this matter. >> >> Sincerely, >> Mark >> >> On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: >>> The solution that Ben proposed is meant to address the requirements that arose >>> from the iLTER Lake Taihu meeting for providing core metadata in multiple >>> languages. These recommendations then were also at the core of the >>> recommendations made to GBIF about which fields should contain English >>> translations, but the set of fields differs slightly in the two recommendations. >>> Because many of these fields are not currently repeatable according to the EML >>> 2.1 schema, we would need to, at a minumum, change cardinality rules to allow >>> for each field to be included multiple times if the xml:lang tag were used to >>> differentiate them (or for the approach Inigo points to). As Ben points out, it >>> would still be ambiguous as to whether the repeating fields represent different >>> information, or the same information translated. So his proposal is meant to >>> explicitly flag translations as such within mixed content string fields, with >>> the goal of doing so without breaking existing EML 2.1 compatibility and without >>> having to change existing cardinality rules. >>> >>> Ben's prior discussion on this highlighted the conflict with the NonEmptyString >>> type that was introduced in EML 2.1, in that mixed content elements would not be >>> validated and so the rules for NonEmptyString would not be enforced. I think >>> this would only be a small issue, and that the advantages in compatibility >>> provided by using a mixed content model for language translations outweigh the >>> loss of validation within our string types. Either way, we would need to add >>> the xml:lang attribute so that it can be used throughout EML, including in the >>> translation elements that Ben proposed. >>> >>> Are there any objections to moving forward with the schema changes to use a >>> mixed content models for translations that Ben proposed in his earlier emails? >>> >>> Matt >>> >>> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu >>> <mailto:isangil at canyon.lternet.edu>> wrote: >>> >>> >>> We'll keep our eyes on the ball, then. >>> >>> Meanwhile others have adopted their own solution. >>> Here are two examples: >>> 1) a site from Spain reports this implementation >>> >>> <title>[Language:En]Snow cover data provided by MODIS satellite imagery >>> [Language:Sp]Datos de innivación según imágenes >>> MODIS >>> >>> We thought that the use of the XML attribute "lang=en | sp" >>> was interesting -but, among other problems, we would have >>> gotten screwed by eml-dev eventual internationalization >>> implementation. Call it luck, but you can bet the "eventual >>> eml-dev decision" would force us to re-code the EML >>> generation. >>> >>> 2) From Taiwan, it is also a mix and match. I had the >>> internationalization conversation years ago, when we set >>> harvesting into the NBII clearinghouse. at the TFRI, we >>> found EML documents that have a hybrid of english and >>> chinese, with no sign or whatsoever of the language used. >>> We had to devise a mechanism to detect language. We >>> simply did not harvest those docs whose critical content >>> was not translated in English. >>> >>> ILTER discussed (two years ago?) some guidelines on >>> how the different countries were going to deal with the >>> tower of Babel problem. May be you can look into those >>> if you feel curious, but if I recall correctly, it went along >>> the lines of encoding the metadata in the native language, >>> and produce some discovery-level EML in English. This >>> strategy would create two EMLs per EML.. >>> >>> Sparks or not, I still have to recommend the EML users >>> to implement some solution. Im inclined to suggest that >>> such solution 1) does not break the current EML rules. >>> 2) The solution should allow for easy language detection. >>> Spain's case fits here, for example. >>> >>> Cheers, inigo >>> >>> >>> >>> >>> >>> On 9/16/2010 10:56 AM, ben leinfelder wrote: >>> >>> Hi Markus, >>> I'm afraid your findings are accurate with respect to the xml:lang >>> attribute in the element (or any "NonEmptyStringType" element). >>> In the course of my experimentation with allowing backwards-compatible >>> internationalization with a new EML version (2.1.1) I did have to >>> include the "http://www.w3.org/XML/1998/namespace" namespace just as you >>> did and also declare the xml:lang attribute in elements where I wanted >>> to employ it. >>> While certain EML elements are repeatable, it's not always clear what >>> the presence of multiple elements represent (are they translations in >>> different languages or are they alternate titles?). In order to clarify >>> this confusion and also allow multiple translations for non-repeatable >>> elements I proposed a solution for allowing mixed element content for >>> fields that should be internationalized. There's a fairly comprehensive >>> discussion of this approach in our eml-dev archives: >>> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >>> I didn't get a lot of decisive feedback and so have not moved forward >>> with releasing an updated EML version. Hopefully this thread will again >>> set the ball rolling. >>> -ben >>> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> >>> >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >>> >>> >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> - -- >> Mark Servilla, Ph.D. >> >> LTER Network Office >> Department of Biology >> MSC 03 2020 >> 1 University of New Mexico >> Albuquerque, NM 87131-0001 >> >> servilla at LTERnet.edu >> Office (505) 277-2619 >> Cell (505) 453-8593 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH >> z0YAn1HQNykMFDCt8zIm02bwMv5iecng >> =z21i >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > From leinfelder at nceas.ucsb.edu Mon Sep 20 14:59:19 2010 From: leinfelder at nceas.ucsb.edu (ben leinfelder) Date: Mon, 20 Sep 2010 14:59:19 -0700 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <D9845ED2-3BAB-4D51-BC1C-7C7434524BEE@gbif.org> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <4C92CFFE.6060909@lternet.edu> <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> <7E74F0CF-9E37-4922-A769-D36318A39D0B@nceas.ucsb.edu> <D9845ED2-3BAB-4D51-BC1C-7C7434524BEE@gbif.org> Message-ID: <AE241711-7AF1-4E40-B97D-F7AE7C4561B0@nceas.ucsb.edu> Folks interested in i18n progress - I've added a section to the EML documentation that describes the internationalization features implemented so far for EML 2.1.1. Please look over what I've got - hopefully your comments will help make the documentation clearer, or discussion will ensue over best-practices for generating multi-lingual EML documents. Thanks, -ben -------------------------------------------------------------------------------------------------- 2.8. Internationalization - Metadata in multiple languages EML supports internationalization using the i18nNonEmptyStringType. Fields defined as this type include: ? Title ? Keyword ? Contact information (e.g. names, organizations, addresses) TextType fields also support language translations. These fields include: ? Abstract ? Methods ? Protocol Example 2.1. Internationalization techniques Core metadata should be provided in English. The core elements can be augmented with translations in a native language. Detailed metadata can be provided in the native language as declared using the xml:lang attribute. Authors can opt to include English translations of this detailed metadata as they see fit. The following example metadata document is provided primarily in Portuguese but includes English translations of core metadata fields. The xml:lang="pt_BR" attribute at the root of the EML document indicates that, unless otherwise specified, the content of the document is supplied in Portuguese (Brazil). The xml:lang="en_US" attributes on child elements denote that the content of that element is provided in English. Core metadata (i.e. title) is provided in English, supplemented with a Portuguese translation using the value tag with an xml:lang attribute. Note that child elements can override the root language declaration of the document as well as the language declaration of their containing elements. The abstract element is primarily given in Portuguese (as inherited from the root language declaration), with an English translation. Many EML fields are repeatable (i.e. keyword) so that multiple values can be provided for the same concept. Translations for these fields should be included as nested value tags to indicate that they are equivalent concepts expressed in different languages rather than entirely different concepts. <?xml version="1.0"?> <eml:eml packageId="eml.1.1" system="knb" xml:lang="pt_BR" xmlns:eml="eml://ecoinformatics.org/eml-2.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="eml://ecoinformatics.org/eml-2.1.1 eml.xsd"> <dataset id="ds.1"> <!-- English title with Portuguese translation --> <title xml:lang=""en_US" > Sample Dataset Description <value xml:lang="pt_BR" >Exemplo Descri??o Dataset</value> ... Neste exemplo, a tradu??o em Ingl?s ? secund?rio In this example, the English translation is secondary ... ?rvore tree ?gua water ... ------------------------------------------------- On Sep 17, 2010, at 12:14 AM, Markus D?ring (GBIF) wrote: > Impressive. > just woke up and all seems to be settled already. Im happy to see all those changes and the new namespace version. > I will adapt the gbif recommended subset of eml to work with this 2.1.1 solution right now. > > Thanks so much, > Markus > > > > On Sep 17, 2010, at 8:12, ben leinfelder wrote: > >> Matt, >> Looking over some TFRI business cards I have, I can certainly see a utility in allowing translations for contact information... >> I've augmented the eml-party schema to allow for internationalized values. >> Method steps are TextType (a la DocBook) and now support internationalization because of the changes I made to TextType for the 'abstract' element. >> >> The next step will be to update the EML namespace in the schema modules to reflect this minor update. I am targeting "eml://ecoinformatics.org/eml-2.1.1" unless anyone objects. >> Thanks, >> -ben >> >> >> On Sep 16, 2010, at 8:55 PM, Matt Jones wrote: >> >>> Ben, >>> >>> I agree with you on the identifier and creator, contact, etc fields as not strictly needing translation. However, even some of those fields may benefit, such as the use of a name in Mandarin and its Romanized translation. Also, I think all of the fields that might allow for general text should be included, such as methods, etc. Certainly anything that accepts TextType might need to be translated in addition to the fields you listed. Does that sound reasonable? >>> >>> Matt >>> >>> On Thu, Sep 16, 2010 at 6:18 PM, Mark Servilla wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email - >>> that is, the "mixed content" approach. It is not entirely clear what the >>> long-term implications of the changes will be for parsing and validation, but >>> the short-term approach seems manageable (albeit, with effort from some warm >>> body). Internationalization of EML is a necessary step as we move research and >>> its associated data/metadata to a global level. >>> >>> I personally do not see the alternatives as being viable long-term solutions. >>> Multiple documents of differing languages will ultimately be too cumbersome and, >>> likely, not kept synchronized. Introducing another inline content attribute >>> (i.e., [Language:En]Snow cover...) only adds yet more syntactical parsing >>> issues. The use of the xml:lang attribute is, at least, a recognized and >>> standard approach in many systems. >>> >>> I appreciate and thank Ben and others for their efforts in this matter. >>> >>> Sincerely, >>> Mark >>> >>> On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: >>>> The solution that Ben proposed is meant to address the requirements that arose >>>> from the iLTER Lake Taihu meeting for providing core metadata in multiple >>>> languages. These recommendations then were also at the core of the >>>> recommendations made to GBIF about which fields should contain English >>>> translations, but the set of fields differs slightly in the two recommendations. >>>> Because many of these fields are not currently repeatable according to the EML >>>> 2.1 schema, we would need to, at a minumum, change cardinality rules to allow >>>> for each field to be included multiple times if the xml:lang tag were used to >>>> differentiate them (or for the approach Inigo points to). As Ben points out, it >>>> would still be ambiguous as to whether the repeating fields represent different >>>> information, or the same information translated. So his proposal is meant to >>>> explicitly flag translations as such within mixed content string fields, with >>>> the goal of doing so without breaking existing EML 2.1 compatibility and without >>>> having to change existing cardinality rules. >>>> >>>> Ben's prior discussion on this highlighted the conflict with the NonEmptyString >>>> type that was introduced in EML 2.1, in that mixed content elements would not be >>>> validated and so the rules for NonEmptyString would not be enforced. I think >>>> this would only be a small issue, and that the advantages in compatibility >>>> provided by using a mixed content model for language translations outweigh the >>>> loss of validation within our string types. Either way, we would need to add >>>> the xml:lang attribute so that it can be used throughout EML, including in the >>>> translation elements that Ben proposed. >>>> >>>> Are there any objections to moving forward with the schema changes to use a >>>> mixed content models for translations that Ben proposed in his earlier emails? >>>> >>>> Matt >>>> >>>> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu >>>> <mailto:isangil at canyon.lternet.edu>> wrote: >>>> >>>> >>>> We'll keep our eyes on the ball, then. >>>> >>>> Meanwhile others have adopted their own solution. >>>> Here are two examples: >>>> 1) a site from Spain reports this implementation >>>> >>>> <title>[Language:En]Snow cover data provided by MODIS satellite imagery >>>> [Language:Sp]Datos de innivación según imágenes >>>> MODIS >>>> >>>> We thought that the use of the XML attribute "lang=en | sp" >>>> was interesting -but, among other problems, we would have >>>> gotten screwed by eml-dev eventual internationalization >>>> implementation. Call it luck, but you can bet the "eventual >>>> eml-dev decision" would force us to re-code the EML >>>> generation. >>>> >>>> 2) From Taiwan, it is also a mix and match. I had the >>>> internationalization conversation years ago, when we set >>>> harvesting into the NBII clearinghouse. at the TFRI, we >>>> found EML documents that have a hybrid of english and >>>> chinese, with no sign or whatsoever of the language used. >>>> We had to devise a mechanism to detect language. We >>>> simply did not harvest those docs whose critical content >>>> was not translated in English. >>>> >>>> ILTER discussed (two years ago?) some guidelines on >>>> how the different countries were going to deal with the >>>> tower of Babel problem. May be you can look into those >>>> if you feel curious, but if I recall correctly, it went along >>>> the lines of encoding the metadata in the native language, >>>> and produce some discovery-level EML in English. This >>>> strategy would create two EMLs per EML.. >>>> >>>> Sparks or not, I still have to recommend the EML users >>>> to implement some solution. Im inclined to suggest that >>>> such solution 1) does not break the current EML rules. >>>> 2) The solution should allow for easy language detection. >>>> Spain's case fits here, for example. >>>> >>>> Cheers, inigo >>>> >>>> >>>> >>>> >>>> >>>> On 9/16/2010 10:56 AM, ben leinfelder wrote: >>>> >>>> Hi Markus, >>>> I'm afraid your findings are accurate with respect to the xml:lang >>>> attribute in the element (or any "NonEmptyStringType" element). >>>> In the course of my experimentation with allowing backwards-compatible >>>> internationalization with a new EML version (2.1.1) I did have to >>>> include the "http://www.w3.org/XML/1998/namespace" namespace just as you >>>> did and also declare the xml:lang attribute in elements where I wanted >>>> to employ it. >>>> While certain EML elements are repeatable, it's not always clear what >>>> the presence of multiple elements represent (are they translations in >>>> different languages or are they alternate titles?). In order to clarify >>>> this confusion and also allow multiple translations for non-repeatable >>>> elements I proposed a solution for allowing mixed element content for >>>> fields that should be internationalized. There's a fairly comprehensive >>>> discussion of this approach in our eml-dev archives: >>>> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >>>> I didn't get a lot of decisive feedback and so have not moved forward >>>> with releasing an updated EML version. Hopefully this thread will again >>>> set the ball rolling. >>>> -ben >>>> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>> <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> >>>> >>>> >>>> _______________________________________________ >>>> Eml-dev mailing list >>>> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> >>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Eml-dev mailing list >>>> Eml-dev at ecoinformatics.org >>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >>> - -- >>> Mark Servilla, Ph.D. >>> >>> LTER Network Office >>> Department of Biology >>> MSC 03 2020 >>> 1 University of New Mexico >>> Albuquerque, NM 87131-0001 >>> >>> servilla at LTERnet.edu >>> Office (505) 277-2619 >>> Cell (505) 453-8593 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.8 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH >>> z0YAn1HQNykMFDCt8zIm02bwMv5iecng >>> =z21i >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> > From dblankman1 at gmail.com Tue Sep 21 02:06:19 2010 From: dblankman1 at gmail.com (David Blankman) Date: Tue, 21 Sep 2010 11:06:19 +0200 Subject: [eml-dev] xml:lang attribute for title in EML 2.1.0 In-Reply-To: <AE241711-7AF1-4E40-B97D-F7AE7C4561B0@nceas.ucsb.edu> References: <mailman.754.1284640205.6418.eml-dev@ecoinformatics.org> <511D02BD-5335-40E1-B3B0-F4D788A8AE08@gbif.org> <BBE399F8-555F-4761-8C0B-5753194AE7D6@nceas.ucsb.edu> <4C927166.2050001@canyon.lternet.edu> <AANLkTimzBB5KRWuVxCzL8_kx4=WOqKsOOPYFDoJwzcLh@mail.gmail.com> <4C92CFFE.6060909@lternet.edu> <AANLkTi=y0WmHkwMBvqL1SQf7WpDX=tx-Mu_ivKcR-z2t@mail.gmail.com> <7E74F0CF-9E37-4922-A769-D36318A39D0B@nceas.ucsb.edu> <D9845ED2-3BAB-4D51-BC1C-7C7434524BEE@gbif.org> <AE241711-7AF1-4E40-B97D-F7AE7C4561B0@nceas.ucsb.edu> Message-ID: <E5911CFB-A39E-457B-A754-0ECEC91FD295@gmail.com> Ben, The ILTER has established the following as "Core" metadata: Creator,Contact,Title, Abstract to be provided in English and strongly encourages keywords. David On 20 Sep 2010, at 23:59, ben leinfelder wrote: > Folks interested in i18n progress - > I've added a section to the EML documentation that describes the internationalization features implemented so far for EML 2.1.1. Please look over what I've got - hopefully your comments will help make the documentation clearer, or discussion will ensue over best-practices for generating multi-lingual EML documents. > Thanks, > -ben > > -------------------------------------------------------------------------------------------------- > 2.8. Internationalization - Metadata in multiple languages > > EML supports internationalization using the i18nNonEmptyStringType. Fields defined as this type include: > ? Title > ? Keyword > ? Contact information (e.g. names, organizations, addresses) > > TextType fields also support language translations. These fields include: > ? Abstract > ? Methods > ? Protocol > > Example 2.1. Internationalization techniques > Core metadata should be provided in English. The core elements can be augmented with translations in a native language. Detailed metadata can be provided in the native language as declared using the xml:lang attribute. Authors can opt to include English translations of this detailed metadata as they see fit. > The following example metadata document is provided primarily in Portuguese but includes English translations of core metadata fields. The xml:lang="pt_BR" attribute at the root of the EML document indicates that, unless otherwise specified, the content of the document is supplied in Portuguese (Brazil). The xml:lang="en_US" attributes on child elements denote that the content of that element is provided in English. Core metadata (i.e. title) is provided in English, supplemented with a Portuguese translation using the value tag with an xml:lang attribute. Note that child elements can override the root language declaration of the document as well as the language declaration of their containing elements. The abstract element is primarily given in Portuguese (as inherited from the root language declaration), with an English translation. > Many EML fields are repeatable (i.e. keyword) so that multiple values can be provided for the same concept. Translations for these fields should be included as nested value tags to indicate that they are equivalent concepts expressed in different languages rather than entirely different concepts. > > <?xml version="1.0"?> > <eml:eml > packageId="eml.1.1" system="knb" > xml:lang="pt_BR" > xmlns:eml="eml://ecoinformatics.org/eml-2.1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="eml://ecoinformatics.org/eml-2.1.1 eml.xsd"> > <dataset id="ds.1"> > <!-- English title with Portuguese translation --> > <title xml:lang=""en_US" > > Sample Dataset Description > <value xml:lang="pt_BR" >Exemplo Descri??o Dataset</value> > > ... > > > > Neste exemplo, a tradu??o em Ingl?s ? secund?rio > In this example, the English translation is secondary > > > ... > > > > ?rvore > tree > > > ?gua > water > > > ... > > > > ------------------------------------------------- > > > On Sep 17, 2010, at 12:14 AM, Markus D?ring (GBIF) wrote: > >> Impressive. >> just woke up and all seems to be settled already. Im happy to see all those changes and the new namespace version. >> I will adapt the gbif recommended subset of eml to work with this 2.1.1 solution right now. >> >> Thanks so much, >> Markus >> >> >> >> On Sep 17, 2010, at 8:12, ben leinfelder wrote: >> >>> Matt, >>> Looking over some TFRI business cards I have, I can certainly see a utility in allowing translations for contact information... >>> I've augmented the eml-party schema to allow for internationalized values. >>> Method steps are TextType (a la DocBook) and now support internationalization because of the changes I made to TextType for the 'abstract' element. >>> >>> The next step will be to update the EML namespace in the schema modules to reflect this minor update. I am targeting "eml://ecoinformatics.org/eml-2.1.1" unless anyone objects. >>> Thanks, >>> -ben >>> >>> >>> On Sep 16, 2010, at 8:55 PM, Matt Jones wrote: >>> >>>> Ben, >>>> >>>> I agree with you on the identifier and creator, contact, etc fields as not strictly needing translation. However, even some of those fields may benefit, such as the use of a name in Mandarin and its Romanized translation. Also, I think all of the fields that might allow for general text should be included, such as methods, etc. Certainly anything that accepts TextType might need to be translated in addition to the fields you listed. Does that sound reasonable? >>>> >>>> Matt >>>> >>>> On Thu, Sep 16, 2010 at 6:18 PM, Mark Servilla wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I agree with the changes proposed by Ben in his 7/30/10 Jul 30, 2010 email - >>>> that is, the "mixed content" approach. It is not entirely clear what the >>>> long-term implications of the changes will be for parsing and validation, but >>>> the short-term approach seems manageable (albeit, with effort from some warm >>>> body). Internationalization of EML is a necessary step as we move research and >>>> its associated data/metadata to a global level. >>>> >>>> I personally do not see the alternatives as being viable long-term solutions. >>>> Multiple documents of differing languages will ultimately be too cumbersome and, >>>> likely, not kept synchronized. Introducing another inline content attribute >>>> (i.e., [Language:En]Snow cover...) only adds yet more syntactical parsing >>>> issues. The use of the xml:lang attribute is, at least, a recognized and >>>> standard approach in many systems. >>>> >>>> I appreciate and thank Ben and others for their efforts in this matter. >>>> >>>> Sincerely, >>>> Mark >>>> >>>> On 9/16/10 Sep 16, 2010 1:56 PM, Matt Jones wrote: >>>>> The solution that Ben proposed is meant to address the requirements that arose >>>>> from the iLTER Lake Taihu meeting for providing core metadata in multiple >>>>> languages. These recommendations then were also at the core of the >>>>> recommendations made to GBIF about which fields should contain English >>>>> translations, but the set of fields differs slightly in the two recommendations. >>>>> Because many of these fields are not currently repeatable according to the EML >>>>> 2.1 schema, we would need to, at a minumum, change cardinality rules to allow >>>>> for each field to be included multiple times if the xml:lang tag were used to >>>>> differentiate them (or for the approach Inigo points to). As Ben points out, it >>>>> would still be ambiguous as to whether the repeating fields represent different >>>>> information, or the same information translated. So his proposal is meant to >>>>> explicitly flag translations as such within mixed content string fields, with >>>>> the goal of doing so without breaking existing EML 2.1 compatibility and without >>>>> having to change existing cardinality rules. >>>>> >>>>> Ben's prior discussion on this highlighted the conflict with the NonEmptyString >>>>> type that was introduced in EML 2.1, in that mixed content elements would not be >>>>> validated and so the rules for NonEmptyString would not be enforced. I think >>>>> this would only be a small issue, and that the advantages in compatibility >>>>> provided by using a mixed content model for language translations outweigh the >>>>> loss of validation within our string types. Either way, we would need to add >>>>> the xml:lang attribute so that it can be used throughout EML, including in the >>>>> translation elements that Ben proposed. >>>>> >>>>> Are there any objections to moving forward with the schema changes to use a >>>>> mixed content models for translations that Ben proposed in his earlier emails? >>>>> >>>>> Matt >>>>> >>>>> On Thu, Sep 16, 2010 at 11:35 AM, Inigo San Gil <isangil at canyon.lternet.edu >>>>> <mailto:isangil at canyon.lternet.edu>> wrote: >>>>> >>>>> >>>>> We'll keep our eyes on the ball, then. >>>>> >>>>> Meanwhile others have adopted their own solution. >>>>> Here are two examples: >>>>> 1) a site from Spain reports this implementation >>>>> >>>>> <title>[Language:En]Snow cover data provided by MODIS satellite imagery >>>>> [Language:Sp]Datos de innivación según imágenes >>>>> MODIS >>>>> >>>>> We thought that the use of the XML attribute "lang=en | sp" >>>>> was interesting -but, among other problems, we would have >>>>> gotten screwed by eml-dev eventual internationalization >>>>> implementation. Call it luck, but you can bet the "eventual >>>>> eml-dev decision" would force us to re-code the EML >>>>> generation. >>>>> >>>>> 2) From Taiwan, it is also a mix and match. I had the >>>>> internationalization conversation years ago, when we set >>>>> harvesting into the NBII clearinghouse. at the TFRI, we >>>>> found EML documents that have a hybrid of english and >>>>> chinese, with no sign or whatsoever of the language used. >>>>> We had to devise a mechanism to detect language. We >>>>> simply did not harvest those docs whose critical content >>>>> was not translated in English. >>>>> >>>>> ILTER discussed (two years ago?) some guidelines on >>>>> how the different countries were going to deal with the >>>>> tower of Babel problem. May be you can look into those >>>>> if you feel curious, but if I recall correctly, it went along >>>>> the lines of encoding the metadata in the native language, >>>>> and produce some discovery-level EML in English. This >>>>> strategy would create two EMLs per EML.. >>>>> >>>>> Sparks or not, I still have to recommend the EML users >>>>> to implement some solution. Im inclined to suggest that >>>>> such solution 1) does not break the current EML rules. >>>>> 2) The solution should allow for easy language detection. >>>>> Spain's case fits here, for example. >>>>> >>>>> Cheers, inigo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 9/16/2010 10:56 AM, ben leinfelder wrote: >>>>> >>>>> Hi Markus, >>>>> I'm afraid your findings are accurate with respect to the xml:lang >>>>> attribute in the element (or any "NonEmptyStringType" element). >>>>> In the course of my experimentation with allowing backwards-compatible >>>>> internationalization with a new EML version (2.1.1) I did have to >>>>> include the "http://www.w3.org/XML/1998/namespace" namespace just as you >>>>> did and also declare the xml:lang attribute in elements where I wanted >>>>> to employ it. >>>>> While certain EML elements are repeatable, it's not always clear what >>>>> the presence of multiple elements represent (are they translations in >>>>> different languages or are they alternate titles?). In order to clarify >>>>> this confusion and also allow multiple translations for non-repeatable >>>>> elements I proposed a solution for allowing mixed element content for >>>>> fields that should be internationalized. There's a fairly comprehensive >>>>> discussion of this approach in our eml-dev archives: >>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2010-July/001828.html >>>>> I didn't get a lot of decisive feedback and so have not moved forward >>>>> with releasing an updated EML version. Hopefully this thread will again >>>>> set the ball rolling. >>>>> -ben >>>>> .nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>>> <http://nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Eml-dev mailing list >>>>> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> >>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Eml-dev mailing list >>>>> Eml-dev at ecoinformatics.org >>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>> >>>> - -- >>>> Mark Servilla, Ph.D. >>>> >>>> LTER Network Office >>>> Department of Biology >>>> MSC 03 2020 >>>> 1 University of New Mexico >>>> Albuquerque, NM 87131-0001 >>>> >>>> servilla at LTERnet.edu >>>> Office (505) 277-2619 >>>> Cell (505) 453-8593 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.8 (Darwin) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>>> >>>> iEYEARECAAYFAkySz/4ACgkQqFW3+12RyXOEggCeLtSSf8r3pJty+lv06lk9uSVH >>>> z0YAn1HQNykMFDCt8zIm02bwMv5iecng >>>> =z21i >>>> -----END PGP SIGNATURE----- >>>> >>>> _______________________________________________ >>>> Eml-dev mailing list >>>> Eml-dev at ecoinformatics.org >>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >> > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev From dblankman1 at gmail.com Wed Sep 29 02:43:57 2010 From: dblankman1 at gmail.com (David Blankman) Date: Wed, 29 Sep 2010 11:43:57 +0200 Subject: [eml-dev] EML and ISO19115 Message-ID: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> Matt et al, I was wondering if there is a plan to create cross-walks between EML and ISO19115. All of the European LTERs will be required to report in ISO19115 format. An XSLT analogous to the EML to FGDC would be very inportant David Blankman Chair, ILTER Information Management Committee Director, Information Management Israel LTER / MARAG 972-54-685-9345 (cell) 972-77-442-1951 (work) Skype: dblankman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100929/0aec9c85/attachment.html> From jones at nceas.ucsb.edu Wed Sep 29 07:26:01 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Wed, 29 Sep 2010 06:26:01 -0800 Subject: [eml-dev] EML and ISO19115 In-Reply-To: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> References: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> Message-ID: <AANLkTi=fP3Zb58KYZGit+b-PFdb9mSbu4pgNRRHgxopX@mail.gmail.com> We've wanted that for a long time, but I don't know of anyone who is working on it directly. I think that this conversion would be a little easier than the conversion to the BDP. Would this be something that the folks at ILTER could tackle and make available through the EML project alongside the other conversion XSLTs? Matt On Wed, Sep 29, 2010 at 1:43 AM, David Blankman <dblankman1 at gmail.com>wrote: > Matt et al, > > I was wondering if there is a plan to create cross-walks between EML and > ISO19115. All of the European LTERs will be required to report in ISO19115 > format. An XSLT analogous to the EML to FGDC would be very inportant > > > *David Blankman * > Chair, ILTER Information Management Committee > > Director, Information Management > Israel LTER / MARAG > > 972-54-685-9345 (cell) > 972-77-442-1951 (work) > Skype: dblankman > > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100929/4c7ca873/attachment.html> From jones at nceas.ucsb.edu Wed Sep 29 12:09:56 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Wed, 29 Sep 2010 11:09:56 -0800 Subject: [eml-dev] EML and ISO19115 In-Reply-To: <8638F29270898544933A7663226809E50310C711FE@pcmail3.umweltbundesamt.at> References: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> <AANLkTi=fP3Zb58KYZGit+b-PFdb9mSbu4pgNRRHgxopX@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FE@pcmail3.umweltbundesamt.at> Message-ID: <AANLkTikohvXD8HuQvVSmpVLoazUb1wDq3+QEqkkEz-Rr@mail.gmail.com> There is a lot of overlap among all three metadata specs. Portions of EML are in the FGDC standard and vice versa, and portions of 19115 are in EML. EML also incorporates metadata from ESRI's FGDC implementation that was missing in the real FGDC and ISO. Probably > 80% will be isomorphic and easily mapped, so I think the mapping is the easier part of the process. The hard part is the transformation itself, and in particular the transformation at the point where the models diverge. The hard decisions are what to do when the transformation will be necessarily lossy or imprecise due to granularity mismatches, or how to manage for missing content that is required in one specification but optional and therefore not provided by the user in the other. The FGDC/EML stylesheets encode a bunch of these logistical decisions, and represent a compromise on hard situations where the mappings break down. Matt On Wed, Sep 29, 2010 at 9:24 AM, Schentz Herbert < herbert.schentz at umweltbundesamt.at> wrote: > If ILTER could do that, it would be great. Is not the FGDC metadata > standard very closely related to ISO 19115? > I think that, once the contents mapping is done, the establishment of an > XSLT is not really the tricky part of it. > What about several people working on the contents mapping within an UML > diagramm. (with enterprise architect for example it is easy to create UML > diagrams by reverse engeneering from XSDs.) > > regards > Herbert > > ------------------------------ > *Von:* mbjones.89 at gmail.com [mbjones.89 at gmail.com] im Auftrag von Matt > Jones [jones at nceas.ucsb.edu] > *Gesendet:* Mittwoch, 29. September 2010 16:26 > *An:* David Blankman > *Cc:* eml-dev; Magagna Barbara; Victoria Goodall; Schentz Herbert; Meei-ru > Jeng; Helena Karasti > *Betreff:* Re: [eml-dev] EML and ISO19115 > > We've wanted that for a long time, but I don't know of anyone who is > working on it directly. I think that this conversion would be a little > easier than the conversion to the BDP. Would this be something that the > folks at ILTER could tackle and make available through the EML project > alongside the other conversion XSLTs? > > Matt > > On Wed, Sep 29, 2010 at 1:43 AM, David Blankman <dblankman1 at gmail.com>wrote: > >> Matt et al, >> >> I was wondering if there is a plan to create cross-walks between EML and >> ISO19115. All of the European LTERs will be required to report in ISO19115 >> format. An XSLT analogous to the EML to FGDC would be very inportant >> >> >> *David Blankman * >> Chair, ILTER Information Management Committee >> >> Director, Information Management >> Israel LTER / MARAG >> >> 972-54-685-9345 (cell) >> 972-77-442-1951 (work) >> Skype: dblankman >> >> >> >> >> _______________________________________________ >> Eml-dev mailing list >> Eml-dev at ecoinformatics.org >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100929/1348a1a6/attachment.html> From dblankman1 at gmail.com Thu Sep 30 07:40:19 2010 From: dblankman1 at gmail.com (David Blankman) Date: Thu, 30 Sep 2010 16:40:19 +0200 Subject: [eml-dev] EML and ISO19115 In-Reply-To: <8638F29270898544933A7663226809E50310C71204@pcmail3.umweltbundesamt.at> References: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> <AANLkTi=fP3Zb58KYZGit+b-PFdb9mSbu4pgNRRHgxopX@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FE@pcmail3.umweltbundesamt.at> <AANLkTikohvXD8HuQvVSmpVLoazUb1wDq3+QEqkkEz-Rr@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FF@pcmail3.umweltbundesamt.at> <8638F29270898544933A7663226809E50310C71204@pcmail3.umweltbundesamt.at> Message-ID: <AANLkTi=WZj5J-ZQTbT508VMxpZHA1MyvK8BEsnqVApbn@mail.gmail.com> Matt and Inigo, Herbert and I will be working together on developing a cross-walk between EML and ISO-19115. I know that Inigo has a lot of experience developing cross-walks. I jope that Inogo will be able to lend his experience to the project. David ??????????????????? Everything is possible with a chocolate cookie! - Rabbi Herbie of Jerusalem If I am not for myself, then who will be for me? If I am for myself alone, then who am I? If not now, when? - Rabbi Hillel On Thu, Sep 30, 2010 at 10:38 AM, Schentz Herbert < herbert.schentz at umweltbundesamt.at> wrote: > Matt, is this the entrypoint for further information on FGDC to EML? > http://intranet.lternet.edu/im/project/Esri2Eml > > if so, do you think that we (me and barbara) could get access to it? I > suppose that david already has an account. > thanks > Herbert > > ------------------------------ > *Von:* Schentz Herbert [herbert.schentz at umweltbundesamt.at] > *Gesendet:* Donnerstag, 30. September 2010 08:25 > *An:* Matt Jones > > *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; Meei-ru > Jeng; Helena Karasti > *Betreff:* AW: [eml-dev] EML and ISO19115 > > Thanks Matt! Do you think that the logistical decisions for FGDC/EML > could serve as good guidelines when establishing the logistical decisions > for ISO19115/EML. If so, are they written down somewhere or does someone > have to get them out of the XSLT(s)? > Herbert > > ------------------------------ > *Von:* mbjones.89 at gmail.com [mbjones.89 at gmail.com] im Auftrag von Matt > Jones [jones at nceas.ucsb.edu] > *Gesendet:* Mittwoch, 29. September 2010 21:09 > *An:* Schentz Herbert > *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; Meei-ru > Jeng; Helena Karasti > *Betreff:* Re: [eml-dev] EML and ISO19115 > > There is a lot of overlap among all three metadata specs. Portions of > EML are in the FGDC standard and vice versa, and portions of 19115 are in > EML. EML also incorporates metadata from ESRI's FGDC implementation that > was missing in the real FGDC and ISO. Probably > 80% will be isomorphic > and easily mapped, so I think the mapping is the easier part of the process. > The hard part is the transformation itself, and in particular the > transformation at the point where the models diverge. The hard decisions > are what to do when the transformation will be necessarily lossy or > imprecise due to granularity mismatches, or how to manage for missing > content that is required in one specification but optional and therefore not > provided by the user in the other. The FGDC/EML stylesheets encode a bunch > of these logistical decisions, and represent a compromise on hard situations > where the mappings break down. > > Matt > > On Wed, Sep 29, 2010 at 9:24 AM, Schentz Herbert < > herbert.schentz at umweltbundesamt.at> wrote: > >> If ILTER could do that, it would be great. Is not the FGDC metadata >> standard very closely related to ISO 19115? >> I think that, once the contents mapping is done, the establishment of an >> XSLT is not really the tricky part of it. >> What about several people working on the contents mapping within an UML >> diagramm. (with enterprise architect for example it is easy to create UML >> diagrams by reverse engeneering from XSDs.) >> >> regards >> Herbert >> >> ------------------------------ >> *Von:* mbjones.89 at gmail.com [mbjones.89 at gmail.com] im Auftrag von Matt >> Jones [jones at nceas.ucsb.edu] >> *Gesendet:* Mittwoch, 29. September 2010 16:26 >> *An:* David Blankman >> *Cc:* eml-dev; Magagna Barbara; Victoria Goodall; Schentz Herbert; >> Meei-ru Jeng; Helena Karasti >> *Betreff:* Re: [eml-dev] EML and ISO19115 >> >> We've wanted that for a long time, but I don't know of anyone who is >> working on it directly. I think that this conversion would be a little >> easier than the conversion to the BDP. Would this be something that the >> folks at ILTER could tackle and make available through the EML project >> alongside the other conversion XSLTs? >> >> Matt >> >> On Wed, Sep 29, 2010 at 1:43 AM, David Blankman <dblankman1 at gmail.com>wrote: >> >>> Matt et al, >>> >>> I was wondering if there is a plan to create cross-walks between EML >>> and ISO19115. All of the European LTERs will be required to report in >>> ISO19115 format. An XSLT analogous to the EML to FGDC would be very >>> inportant >>> >>> >>> *David Blankman * >>> Chair, ILTER Information Management Committee >>> >>> Director, Information Management >>> Israel LTER / MARAG >>> >>> 972-54-685-9345 (cell) >>> 972-77-442-1951 (work) >>> Skype: dblankman >>> >>> >>> >>> >>> _______________________________________________ >>> Eml-dev mailing list >>> Eml-dev at ecoinformatics.org >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100930/f5df38bb/attachment.html> From jones at nceas.ucsb.edu Thu Sep 30 12:22:14 2010 From: jones at nceas.ucsb.edu (Matt Jones) Date: Thu, 30 Sep 2010 11:22:14 -0800 Subject: [eml-dev] EML and ISO19115 In-Reply-To: <AANLkTikZqZBZ4R33YuZoB=-EFHatALRrOr+MwYyQ1uBp@mail.gmail.com> References: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> <AANLkTi=fP3Zb58KYZGit+b-PFdb9mSbu4pgNRRHgxopX@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FE@pcmail3.umweltbundesamt.at> <AANLkTikohvXD8HuQvVSmpVLoazUb1wDq3+QEqkkEz-Rr@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FF@pcmail3.umweltbundesamt.at> <8638F29270898544933A7663226809E50310C71204@pcmail3.umweltbundesamt.at> <AANLkTi=WZj5J-ZQTbT508VMxpZHA1MyvK8BEsnqVApbn@mail.gmail.com> <AANLkTikZqZBZ4R33YuZoB=-EFHatALRrOr+MwYyQ1uBp@mail.gmail.com> Message-ID: <AANLkTikhdbjgba4Xzu9VC2drThg9weRiw8qgacbYte4P@mail.gmail.com> The XSLT stylesheets that we use ship publicly for the conversion are located in the EML repository, specifically for NBII BDP and ESRI here: https://code.ecoinformatics.org/code/eml/trunk/lib/eml2tonbii/ https://code.ecoinformatics.org/code/eml/trunk/lib/esri2eml/ These are the ones we use in Morpho to provide transformations, but Inigo did a ton of work on these too and may have additional updates to the stylesheets. Matt On Thu, Sep 30, 2010 at 6:44 AM, Victoria Goodall <victoria at saeon.ac.za>wrote: > Hi David > > Please could you let me know if you make progress with the cross-walk as > this is something that would be very useful to us here in South Africa. > > Many thanks, > Victoria > > On 30 September 2010 16:40, David Blankman <dblankman1 at gmail.com> wrote: > >> Matt and Inigo, >> >> Herbert and I will be working together on developing a cross-walk between >> EML and ISO-19115. I know that Inigo has a lot of experience developing >> cross-walks. I jope that Inogo will be able to lend his experience to the >> project. >> >> David >> >> >> ??????????????????? >> Everything is possible with a chocolate cookie! >> - Rabbi Herbie of Jerusalem >> >> If I am not for myself, then who will be for me? If I am for myself alone, >> then who am I? If not now, when? >> - Rabbi Hillel >> >> >> >> On Thu, Sep 30, 2010 at 10:38 AM, Schentz Herbert < >> herbert.schentz at umweltbundesamt.at> wrote: >> >>> Matt, is this the entrypoint for further information on FGDC to EML? >>> http://intranet.lternet.edu/im/project/Esri2Eml >>> >>> if so, do you think that we (me and barbara) could get access to it? I >>> suppose that david already has an account. >>> thanks >>> Herbert >>> >>> ------------------------------ >>> *Von:* Schentz Herbert [herbert.schentz at umweltbundesamt.at] >>> *Gesendet:* Donnerstag, 30. September 2010 08:25 >>> *An:* Matt Jones >>> >>> *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; >>> Meei-ru Jeng; Helena Karasti >>> *Betreff:* AW: [eml-dev] EML and ISO19115 >>> >>> Thanks Matt! Do you think that the logistical decisions for FGDC/EML >>> could serve as good guidelines when establishing the logistical decisions >>> for ISO19115/EML. If so, are they written down somewhere or does someone >>> have to get them out of the XSLT(s)? >>> Herbert >>> >>> ------------------------------ >>> *Von:* mbjones.89 at gmail.com [mbjones.89 at gmail.com] im Auftrag von Matt >>> Jones [jones at nceas.ucsb.edu] >>> *Gesendet:* Mittwoch, 29. September 2010 21:09 >>> *An:* Schentz Herbert >>> *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; >>> Meei-ru Jeng; Helena Karasti >>> *Betreff:* Re: [eml-dev] EML and ISO19115 >>> >>> There is a lot of overlap among all three metadata specs. Portions of >>> EML are in the FGDC standard and vice versa, and portions of 19115 are in >>> EML. EML also incorporates metadata from ESRI's FGDC implementation that >>> was missing in the real FGDC and ISO. Probably > 80% will be isomorphic >>> and easily mapped, so I think the mapping is the easier part of the process. >>> The hard part is the transformation itself, and in particular the >>> transformation at the point where the models diverge. The hard decisions >>> are what to do when the transformation will be necessarily lossy or >>> imprecise due to granularity mismatches, or how to manage for missing >>> content that is required in one specification but optional and therefore not >>> provided by the user in the other. The FGDC/EML stylesheets encode a bunch >>> of these logistical decisions, and represent a compromise on hard situations >>> where the mappings break down. >>> >>> Matt >>> >>> On Wed, Sep 29, 2010 at 9:24 AM, Schentz Herbert < >>> herbert.schentz at umweltbundesamt.at> wrote: >>> >>>> If ILTER could do that, it would be great. Is not the FGDC metadata >>>> standard very closely related to ISO 19115? >>>> I think that, once the contents mapping is done, the establishment of an >>>> XSLT is not really the tricky part of it. >>>> What about several people working on the contents mapping within an UML >>>> diagramm. (with enterprise architect for example it is easy to create UML >>>> diagrams by reverse engeneering from XSDs.) >>>> >>>> regards >>>> Herbert >>>> >>>> ------------------------------ >>>> *Von:* mbjones.89 at gmail.com [mbjones.89 at gmail.com] im Auftrag von Matt >>>> Jones [jones at nceas.ucsb.edu] >>>> *Gesendet:* Mittwoch, 29. September 2010 16:26 >>>> *An:* David Blankman >>>> *Cc:* eml-dev; Magagna Barbara; Victoria Goodall; Schentz Herbert; >>>> Meei-ru Jeng; Helena Karasti >>>> *Betreff:* Re: [eml-dev] EML and ISO19115 >>>> >>>> We've wanted that for a long time, but I don't know of anyone who is >>>> working on it directly. I think that this conversion would be a little >>>> easier than the conversion to the BDP. Would this be something that the >>>> folks at ILTER could tackle and make available through the EML project >>>> alongside the other conversion XSLTs? >>>> >>>> Matt >>>> >>>> On Wed, Sep 29, 2010 at 1:43 AM, David Blankman <dblankman1 at gmail.com>wrote: >>>> >>>>> Matt et al, >>>>> >>>>> I was wondering if there is a plan to create cross-walks between EML >>>>> and ISO19115. All of the European LTERs will be required to report in >>>>> ISO19115 format. An XSLT analogous to the EML to FGDC would be very >>>>> inportant >>>>> >>>>> >>>>> *David Blankman * >>>>> Chair, ILTER Information Management Committee >>>>> >>>>> Director, Information Management >>>>> Israel LTER / MARAG >>>>> >>>>> 972-54-685-9345 (cell) >>>>> 972-77-442-1951 (work) >>>>> Skype: dblankman >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Eml-dev mailing list >>>>> Eml-dev at ecoinformatics.org >>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev >>>>> >>>>> >>>> >>> >> > > > -- > Victoria Goodall > Data Manager > South African Environmental Observation Network (SAEON): > Fynbos Node > Tel: +27 21 799 8745 > Fax2email: +27 86 555 9332 > Email: victoria at saeon.ac.za > Postal address: Private Bag X7, Claremont, 7735 > Physical address: Centre for Biodiversity Conservation, Kirstenbosch > Gardens, Rhodes Avenue, Newlands, 7700 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100930/53f7a9fb/attachment.html> From isangil at canyon.lternet.edu Thu Sep 30 12:38:53 2010 From: isangil at canyon.lternet.edu (Inigo San Gil) Date: Thu, 30 Sep 2010 13:38:53 -0600 Subject: [eml-dev] EML and ISO19115 In-Reply-To: <AANLkTi=WZj5J-ZQTbT508VMxpZHA1MyvK8BEsnqVApbn@mail.gmail.com> References: <AEC7D426-327E-469D-98ED-512535988134@gmail.com> <AANLkTi=fP3Zb58KYZGit+b-PFdb9mSbu4pgNRRHgxopX@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FE@pcmail3.umweltbundesamt.at> <AANLkTikohvXD8HuQvVSmpVLoazUb1wDq3+QEqkkEz-Rr@mail.gmail.com> <8638F29270898544933A7663226809E50310C711FF@pcmail3.umweltbundesamt.at> <8638F29270898544933A7663226809E50310C71204@pcmail3.umweltbundesamt.at> <AANLkTi=WZj5J-ZQTbT508VMxpZHA1MyvK8BEsnqVApbn@mail.gmail.com> Message-ID: <4CA4E74D.5000604@canyon.lternet.edu> Ill be glad to help David. The approach some of us are taking is slightly different (not too keen on a eml2iso stylesheet, really) - more on our modest roadmap for ISOxxx compliance later. Producing ISO compliance for me has also been in the back burner mainly for the following two reasons 1) ISO compliance has not penetrated our realm yet in a major way, although the ISO drumming has been in crescendo -- I.e, there is still slow or negligible demand for ISO in our orbit -NBII, US-LTER.- 2) the old reluctance shared with some in this email recipient list about the proprietary character of ISO standards cheers, inigo On 9/30/2010 8:40 AM, David Blankman wrote: > Matt and Inigo, > > Herbert and I will be working together on developing a cross-walk > between EML and ISO-19115. I know that Inigo has a lot of experience > developing cross-walks. I jope that Inogo will be able to lend his > experience to the project. > > David > > > ??????????????????? > Everything is possible with a chocolate cookie! > - Rabbi Herbie of Jerusalem > > If I am not for myself, then who will be for me? If I am for myself > alone, then who am I? If not now, when? > - Rabbi Hillel > > > On Thu, Sep 30, 2010 at 10:38 AM, Schentz Herbert > <herbert.schentz at umweltbundesamt.at > <mailto:herbert.schentz at umweltbundesamt.at>> wrote: > > Matt, is this the entrypoint for further information on FGDC to EML? > http://intranet.lternet.edu/im/project/Esri2Eml > if so, do you think that we (me and barbara) could get access to > it? I suppose that david already has an account. > thanks > Herbert > ------------------------------------------------------------------------ > *Von:* Schentz Herbert [herbert.schentz at umweltbundesamt.at > <mailto:herbert.schentz at umweltbundesamt.at>] > *Gesendet:* Donnerstag, 30. September 2010 08:25 > *An:* Matt Jones > > *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; > Meei-ru Jeng; Helena Karasti > *Betreff:* AW: [eml-dev] EML and ISO19115 > > Thanks Matt! Do you think that the logistical decisions for > FGDC/EML could serve as good guidelines when establishing the > logistical decisions for ISO19115/EML. If so, are they written > down somewhere or does someone have to get them out of the XSLT(s)? > Herbert > ------------------------------------------------------------------------ > *Von:* mbjones.89 at gmail.com <mailto:mbjones.89 at gmail.com> > [mbjones.89 at gmail.com <mailto:mbjones.89 at gmail.com>] im Auftrag > von Matt Jones [jones at nceas.ucsb.edu <mailto:jones at nceas.ucsb.edu>] > *Gesendet:* Mittwoch, 29. September 2010 21:09 > *An:* Schentz Herbert > *Cc:* David Blankman; eml-dev; Magagna Barbara; Victoria Goodall; > Meei-ru Jeng; Helena Karasti > *Betreff:* Re: [eml-dev] EML and ISO19115 > > There is a lot of overlap among all three metadata specs. > Portions of EML are in the FGDC standard and vice versa, and > portions of 19115 are in EML. EML also incorporates metadata from > ESRI's FGDC implementation that was missing in the real FGDC and > ISO. Probably > 80% will be isomorphic and easily mapped, so I > think the mapping is the easier part of the process. The hard > part is the transformation itself, and in particular the > transformation at the point where the models diverge. The hard > decisions are what to do when the transformation will be > necessarily lossy or imprecise due to granularity mismatches, or > how to manage for missing content that is required in one > specification but optional and therefore not provided by the user > in the other. The FGDC/EML stylesheets encode a bunch of these > logistical decisions, and represent a compromise on hard > situations where the mappings break down. > > Matt > > On Wed, Sep 29, 2010 at 9:24 AM, Schentz Herbert > <herbert.schentz at umweltbundesamt.at > <mailto:herbert.schentz at umweltbundesamt.at>> wrote: > > If ILTER could do that, it would be great. Is not the FGDC > metadata standard very closely related to ISO 19115? > I think that, once the contents mapping is done, the > establishment of an XSLT is not really the tricky part of it. > What about several people working on the contents mapping > within an UML diagramm. (with enterprise architect for example > it is easy to create UML diagrams by reverse engeneering from > XSDs.) > regards > Herbert > ------------------------------------------------------------------------ > *Von:* mbjones.89 at gmail.com <mailto:mbjones.89 at gmail.com> > [mbjones.89 at gmail.com <mailto:mbjones.89 at gmail.com>] im > Auftrag von Matt Jones [jones at nceas.ucsb.edu > <mailto:jones at nceas.ucsb.edu>] > *Gesendet:* Mittwoch, 29. September 2010 16:26 > *An:* David Blankman > *Cc:* eml-dev; Magagna Barbara; Victoria Goodall; Schentz > Herbert; Meei-ru Jeng; Helena Karasti > *Betreff:* Re: [eml-dev] EML and ISO19115 > > We've wanted that for a long time, but I don't know of anyone > who is working on it directly. I think that this conversion > would be a little easier than the conversion to the BDP. Would > this be something that the folks at ILTER could tackle and > make available through the EML project alongside the other > conversion XSLTs? > > Matt > > On Wed, Sep 29, 2010 at 1:43 AM, David Blankman > <dblankman1 at gmail.com <mailto:dblankman1 at gmail.com>> wrote: > > Matt et al, > > I was wondering if there is a plan to create cross-walks > between EML and ISO19115. All of the European LTERs will > be required to report in ISO19115 format. An XSLT > analogous to the EML to FGDC would be very inportant > > > *David Blankman * > Chair, ILTER Information Management Committee > > Director, Information Management > Israel LTER / MARAG > > 972-54-685-9345 (cell) > 972-77-442-1951 (work) > Skype: dblankman > > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev > > > > > > _______________________________________________ > Eml-dev mailing list > Eml-dev at ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20100930/c78d53b1/attachment-0001.html>