From bugzilla-daemon at ecoinformatics.org  Tue Dec  2 15:53:40 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Tue,  2 Dec 2008 15:53:40 -0800 (PST)
Subject: [eml-dev] [Bug 2568] - Inconsistent naming of "method"(s) element
Message-ID: <20081202235340.6F56F2FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2568





------- Comment #6 from mob at icess.ucsb.edu  2008-12-02 15:53 -------
Just adding a summary of what Jing and I found for method/s declarations:

These 2 were already declared as "methods" and dont need to be changed:
eml-dataset.xsd:        <xs:element name="methods" type="md:MethodsType"
minOccurs="0">
eml-methods.xsd:  <xs:element name="methods" type="MethodsType">

This path need to be changed: attribute/method
eml-attribute.xsd:        <xs:element name="method" type="md:MethodsType"
minOccurs="0">



and those that use the EntityGroup: 
otherEntity/method
dataTable/method
spatialRaster/method
spatialVector/method
view/method

eml-entity.xsd:  <xs:group name="EntityGroup">
eml-entity.xsd:      <xs:element name="method" type="md:MethodsType"
minOccurs="0">
eml-dataTable.xsd:        <xs:group ref="ent:EntityGroup"/>
eml-entity.xsd:        <xs:group ref="EntityGroup"/>
eml-spatialRaster.xsd:        <xs:group ref="ent:EntityGroup"/>
eml-spatialVector.xsd:        <xs:group ref="ent:EntityGroup"/>
eml-storedProcedure.xsd:        <xs:group ref="ent:EntityGroup"/>
eml-view.xsd:        <xs:group ref="ent:EntityGroup"/>

From bugzilla-daemon at ecoinformatics.org  Tue Dec  2 16:41:04 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Tue,  2 Dec 2008 16:41:04 -0800 (PST)
Subject: [eml-dev] [Bug 1132]  - fix access control rule ambiguities
Message-ID: <20081203004104.585FE2FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1132





------- Comment #15 from mob at icess.ucsb.edu  2008-12-02 16:41 -------
Created an attachment (id=198)
 --> (http://bugzilla.ecoinformatics.org/attachment.cgi?id=198&action=view)
doc is a summary of the possible ways that EML201 instances could have access
trees, and how these should be moved around in EMl-2.1.0

From bugzilla-daemon at ecoinformatics.org  Wed Dec  3 15:21:33 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Wed,  3 Dec 2008 15:21:33 -0800 (PST)
Subject: [eml-dev] [Bug 3600]  - recreate all the PNG files
Message-ID: <20081203232133.45E862FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3600





------- Comment #1 from mob at icess.ucsb.edu  2008-12-03 15:21 -------
These pngs need to be replaced:
coverage
dataset
dataTable
entity
eml
literature
physical
protocol
software
spatialRaster
spatialReference
spatialVector
storedProcedure
text
view

but not these (no changes affected the pngs):
access
attribute
constraint
methods
party
project
protocol

From bugzilla-daemon at ecoinformatics.org  Thu Dec  4 12:07:08 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Thu,  4 Dec 2008 12:07:08 -0800 (PST)
Subject: [eml-dev] [Bug 3600]  - recreate all the PNG files
Message-ID: <20081204200708.701C32FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3600


mob at icess.ucsb.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from mob at icess.ucsb.edu  2008-12-04 12:07 -------
These pngs were replaced:
coverage, dataset, dataTable, entity, eml, literature, physical, protocol,
esource, software, spatialRaster, spatialVector, storedProcedure, text, view

not affected by schema changes:
access, attribute, constraint, methods, party, project, spatialReference

For the most part, nodes were expanded to the same level as in the EML201
documentation. However, I tried to standardize the expansions a bit more: I
expanded the types in the schema diagram where they were defined and collapsed
them where they were imported. For example, this meant replacing the
resource.png so that the changes to the distributionType could be illustrated.
This tree had not been expanded in the 201 png, and so the existing diagram was
accurate as is. But there is no other diagram where the res:DistributionType
could be guaranteed to be expanded, and it should be, since it is different
from phys:PhysicalDistributionType. 

From bugzilla-daemon at ecoinformatics.org  Thu Dec  4 12:11:37 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Thu,  4 Dec 2008 12:11:37 -0800 (PST)
Subject: [eml-dev] [Bug 3688]  - documentation to be fixed
Message-ID: <20081204201137.9B2542FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3688


mob at icess.ucsb.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from mob at icess.ucsb.edu  2008-12-04 12:11 -------
The link will need to be from software/eml at knb, not from the eml schema
documentation index

From dblankman1 at gmail.com  Thu Dec  4 18:31:02 2008
From: dblankman1 at gmail.com (David Blankman)
Date: Thu, 4 Dec 2008 20:31:02 -0600
Subject: [eml-dev] Multiple language extensions to EML
Message-ID: <4222aeb80812041831y4fe2c13foeb8a61be71d5f411@mail.gmail.com>

Margaret,

As EML is becoming an international standard, we need to start thinking
about ways to make EML more intelligent about multiple languages.Wwhile EML
allows multiple titles, there is currently no way to indicated that multiple
titles are equivalent. For example,if I have:
<title> North American Forests </title>  AND
<title> Bosques de Norte Americano</title>

EML currently has no way to indicate that these are the same title, just in
a different language.

Matt and I were taling about this at the ISEI-Cancun meeting, but I thought
that it would be a good idea to get this discussion started within eml-dev
and the ILTER group as well.

David

David Blankman
Director of Information Management, Israel LTER/Ma'arag
Mitrani Department of Desert Ecology
Jacob Blaustein Desert Research Institute
Ben Gurion University
Midreshet Ben Gurion, 84990 Israel
972-54-685-9345 (cell)
1-505-349-5680 (Skype)



-- 
Nature is trying very hard to make us succeed, but nature does not depend on
us. We are not the only experiment.
 - R. Buckminster Fuller

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081204/be8d06e5/attachment.html>

From bugzilla-daemon at ecoinformatics.org  Fri Dec  5 09:31:44 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Fri,  5 Dec 2008 09:31:44 -0800 (PST)
Subject: [eml-dev] [Bug 585]  - internationalization needed in EML
Message-ID: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585





------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
This comment from an email from David Blankman:
As EML is becoming an international standard, we need to start thinking about
ways to make EML more intelligent about multiple languages. While EML allows
multiple titles, there is currently no way to indicated that multiple titles
are equivalent. For example,if I have:
<title> North American Forests </title>  AND
<title> Bosques de Norte Americano</title>

EML currently has no way to indicate that these are the same title, just in a
different language.

Matt and I were talking about this at the ISEI-Cancun meeting, but I thought
that it would be a good idea to get this discussion started within eml-dev and
the ILTER group as well.

From isangil at lternet.edu  Fri Dec  5 13:54:05 2008
From: isangil at lternet.edu (inigo san gil)
Date: Fri, 05 Dec 2008 14:54:05 -0700
Subject: [eml-dev] [Bug 585]  - internationalization needed in EML
In-Reply-To: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
Message-ID: <4939A2FD.5080401@lternet.edu>


Metadata folks:

I think this opens (perhaps re-opens) and interesting discussion.

EML's resource (main module) offers us a <language> element that,
as I understand it, serves to specify the language used for the document.
The cardinality is set to <= 1, so it is optional, and if used, only one
language.

However, we understood from Kristin Valnderbilt and David Blankman
that at a recent ILTER meeting, there was an agreement to provide
referencial-level EML for all metadata in English (and perhaps more
rich EML in their native languages). 

The option David proposes, providing content in two languages
one being english, does not play well with the EML schema as is.
There are options in the interim, while we think whether 'we' tweak
the EML schema.  Some solutions go in the direction of "duplicating" the
original EML record: Take what it is in the native language, and either
have it translate at some minimal-compliance level EML (ouch) or
run it by a translation web service and laugh (or rather cry) at the 
results.

There are of course many other approaches to this problem, Mark
Servilla mentioned some in the hallways of the LTER Network Office.

The thing is that part of the international community in ecology has
expressed formal interest/commitment in using EML to document their
metadata. The ILTER group quickly realized of the Babelian challenge
ahead, (see Blankman's ISEI-6 presentation & future paper) and
David, Akiko Ocgawa and others took in helping the ILTER providing
basic EML in english (remember ILTER committed to use English
-chinglish and spanglish- as the lingua franca for referential level EML,
EML level 1, title, creator, abstract, contact at least

Cheers,
Inigo


bugzilla-daemon at ecoinformatics.org wrote:
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>
>
>
>
>
> ------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
> This comment from an email from David Blankman:
> As EML is becoming an international standard, we need to start thinking about
> ways to make EML more intelligent about multiple languages. While EML allows
> multiple titles, there is currently no way to indicated that multiple titles
> are equivalent. For example,if I have:
> <title> North American Forests </title>  AND
> <title> Bosques de Norte Americano</title>
>
> EML currently has no way to indicate that these are the same title, just in a
> different language.
>
> Matt and I were talking about this at the ISEI-Cancun meeting, but I thought
> that it would be a good idea to get this discussion started within eml-dev and
> the ILTER group as well.
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>   


From bugzilla-daemon at ecoinformatics.org  Mon Dec  8 10:33:22 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Mon,  8 Dec 2008 10:33:22 -0800 (PST)
Subject: [eml-dev] [Bug 585]  - internationalization needed in EML
Message-ID: <20081208183322.9E1322FA86@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585


jones at nceas.ucsb.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Postpone                    |EML2.2.0




------- Comment #3 from jones at nceas.ucsb.edu  2008-12-08 10:33 -------
David and I discussed (briefly) some of these issues at ISEI.  And we also
discussed them at the ILTER meeting in China.  The 'language' tag in
eml-resource defines the language of the resource, which in the case of
eml-dataset resources means the language of the data.  Interestingly, we don't
really have a language tag per se for the EMl document itself, except that all
XML documents can use the built-in "xml:lang" attribute, which is optional for
all XML elements (http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one
to set the language for each and every element in an XML document, such as:

<title xml:lang="en">North American Forests</title>
<title xml:lang="es">Bosques de Norte Americano</title>

Two problems we would need to address with this approach come immedately to
mind:

1) Many elements in EML are not repeatable, and therefore it is not possible to
have one copy of the element in English and another in a different language. So
cardinality would have to be updated throughout the EML schemas, which would
make some aspects of validation more confusing.
2) For those elements that are already repeatable or are made repatable through
a revision, there is no mechanism to indicate that the two element nodes are
meant to be have the same semantic meaning in different languages, as opposed
to two semantically different elements that happen to also differ in their
language.

This second issue is the one that would require more structural changes to EML.
 For example, one might sometimes want to have more than one title (which is
why title is currently repeatable), but other times want to have one title in
two different languages.  Either way, EML's current structures don't allow
these subtleties to be specified.

Matt

From jones at nceas.ucsb.edu  Mon Dec  8 10:34:59 2008
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Mon, 8 Dec 2008 09:34:59 -0900
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <4939A2FD.5080401@lternet.edu>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
	<4939A2FD.5080401@lternet.edu>
Message-ID: <fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>

David and I discussed (briefly) some of these issues at ISEI.  And we also
discussed them at the ILTER meeting in China.  The 'language' tag in
eml-resource defines the language of the resource, which in the case of
eml-dataset resources means the language of the data.  Interestingly, we
don't really have a language tag per se for the EML document content itself,
except that all XML documents can use the built-in "xml:lang" attribute,
which is optional for all XML elements (
http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one to set the
language for each and every element in an XML document, such as:

<title xml:lang="en">North American Forests</title>
<title xml:lang="es">Bosques de Norte Americano</title>

Two problems we would need to address with this approach come immedately to
mind:

1) Many elements in EML are not repeatable, and therefore it is not possible
to have one copy of the element in English and another in a different
language. So cardinality would have to be updated throughout the EML
schemas, which would make some aspects of validation more confusing.
2) For those elements that are already repeatable or are made repatable
through a revision, there is no mechanism to indicate that the two element
nodes are meant to be have the same semantic meaning in different languages,
as opposed to two semantically different elements that happen to also differ
in their language.

This second issue is the one that would require more structural changes to
EML.  For example, one might sometimes want to have more than one title
(which is why title is currently repeatable), but other times want to have
one title in two different languages.  Either way, EML's current structures
don't allow these subtleties to be specified.

Matt

On Fri, Dec 5, 2008 at 12:54 PM, inigo san gil <isangil at lternet.edu> wrote:

>
> Metadata folks:
>
> I think this opens (perhaps re-opens) and interesting discussion.
>
> EML's resource (main module) offers us a <language> element that,
> as I understand it, serves to specify the language used for the document.
> The cardinality is set to <= 1, so it is optional, and if used, only one
> language.
>
> However, we understood from Kristin Valnderbilt and David Blankman
> that at a recent ILTER meeting, there was an agreement to provide
> referencial-level EML for all metadata in English (and perhaps more
> rich EML in their native languages).
> The option David proposes, providing content in two languages
> one being english, does not play well with the EML schema as is.
> There are options in the interim, while we think whether 'we' tweak
> the EML schema.  Some solutions go in the direction of "duplicating" the
> original EML record: Take what it is in the native language, and either
> have it translate at some minimal-compliance level EML (ouch) or
> run it by a translation web service and laugh (or rather cry) at the
> results.
>
> There are of course many other approaches to this problem, Mark
> Servilla mentioned some in the hallways of the LTER Network Office.
>
> The thing is that part of the international community in ecology has
> expressed formal interest/commitment in using EML to document their
> metadata. The ILTER group quickly realized of the Babelian challenge
> ahead, (see Blankman's ISEI-6 presentation & future paper) and
> David, Akiko Ocgawa and others took in helping the ILTER providing
> basic EML in english (remember ILTER committed to use English
> -chinglish and spanglish- as the lingua franca for referential level EML,
> EML level 1, title, creator, abstract, contact at least
>
> Cheers,
> Inigo
>
>
>
> bugzilla-daemon at ecoinformatics.org wrote:
>
>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>>
>>
>>
>>
>>
>> ------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
>> This comment from an email from David Blankman:
>> As EML is becoming an international standard, we need to start thinking
>> about
>> ways to make EML more intelligent about multiple languages. While EML
>> allows
>> multiple titles, there is currently no way to indicated that multiple
>> titles
>> are equivalent. For example,if I have:
>> <title> North American Forests </title>  AND
>> <title> Bosques de Norte Americano</title>
>>
>> EML currently has no way to indicate that these are the same title, just
>> in a
>> different language.
>>
>> Matt and I were talking about this at the ISEI-Cancun meeting, but I
>> thought
>> that it would be a good idea to get this discussion started within eml-dev
>> and
>> the ILTER group as well.
>> _______________________________________________
>> 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
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081208/5106880e/attachment.html>

From dblankman1 at gmail.com  Mon Dec  8 11:59:27 2008
From: dblankman1 at gmail.com (David Blankman)
Date: Mon, 8 Dec 2008 14:59:27 -0500
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
	<4939A2FD.5080401@lternet.edu>
	<fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>
Message-ID: <4222aeb80812081159y4f7aa63dofd066342d43db8e9@mail.gmail.com>

As I think back upon the discussions in China and my discussions with Matt
at ISEI, it seems to me that my initial thought that multiple language
versions of EML documents are probably better handled by creating separate
EML documents for each language used. EML is already complex, I see no
reason to make it more complex.

In the ILTER situation  we are asking ILTER member networks to provide a
core of EML in English, on the understanding that more complete metadata may
be in another language. In this case should there be an EML module,
eml-ilter or eml-language analogous to eml-access that specifies the
identifier of the "main" eml-document and the language of that document.
This module might also include an element to record a brief statement about
the amount of data in that foreign language. I am not sure what else might
be appropriate for this module. I know that Matt was thinking that there
might be some modifications to metacat replication that might be needed.

David





On Mon, Dec 8, 2008 at 1:34 PM, Matt Jones <jones at nceas.ucsb.edu> wrote:

> David and I discussed (briefly) some of these issues at ISEI.  And we also
> discussed them at the ILTER meeting in China.  The 'language' tag in
> eml-resource defines the language of the resource, which in the case of
> eml-dataset resources means the language of the data.  Interestingly, we
> don't really have a language tag per se for the EML document content itself,
> except that all XML documents can use the built-in "xml:lang" attribute,
> which is optional for all XML elements (
> http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one to set the
> language for each and every element in an XML document, such as:
>
> <title xml:lang="en">North American Forests</title>
> <title xml:lang="es">Bosques de Norte Americano</title>
>
> Two problems we would need to address with this approach come immedately to
> mind:
>
> 1) Many elements in EML are not repeatable, and therefore it is not
> possible to have one copy of the element in English and another in a
> different language. So cardinality would have to be updated throughout the
> EML schemas, which would make some aspects of validation more confusing.
> 2) For those elements that are already repeatable or are made repatable
> through a revision, there is no mechanism to indicate that the two element
> nodes are meant to be have the same semantic meaning in different languages,
> as opposed to two semantically different elements that happen to also differ
> in their language.
>
> This second issue is the one that would require more structural changes to
> EML.  For example, one might sometimes want to have more than one title
> (which is why title is currently repeatable), but other times want to have
> one title in two different languages.  Either way, EML's current structures
> don't allow these subtleties to be specified.
>
> Matt
>
>
> On Fri, Dec 5, 2008 at 12:54 PM, inigo san gil <isangil at lternet.edu>wrote:
>
>>
>> Metadata folks:
>>
>> I think this opens (perhaps re-opens) and interesting discussion.
>>
>> EML's resource (main module) offers us a <language> element that,
>> as I understand it, serves to specify the language used for the document.
>> The cardinality is set to <= 1, so it is optional, and if used, only one
>> language.
>>
>> However, we understood from Kristin Valnderbilt and David Blankman
>> that at a recent ILTER meeting, there was an agreement to provide
>> referencial-level EML for all metadata in English (and perhaps more
>> rich EML in their native languages).
>> The option David proposes, providing content in two languages
>> one being english, does not play well with the EML schema as is.
>> There are options in the interim, while we think whether 'we' tweak
>> the EML schema.  Some solutions go in the direction of "duplicating" the
>> original EML record: Take what it is in the native language, and either
>> have it translate at some minimal-compliance level EML (ouch) or
>> run it by a translation web service and laugh (or rather cry) at the
>> results.
>>
>> There are of course many other approaches to this problem, Mark
>> Servilla mentioned some in the hallways of the LTER Network Office.
>>
>> The thing is that part of the international community in ecology has
>> expressed formal interest/commitment in using EML to document their
>> metadata. The ILTER group quickly realized of the Babelian challenge
>> ahead, (see Blankman's ISEI-6 presentation & future paper) and
>> David, Akiko Ocgawa and others took in helping the ILTER providing
>> basic EML in english (remember ILTER committed to use English
>> -chinglish and spanglish- as the lingua franca for referential level EML,
>> EML level 1, title, creator, abstract, contact at least
>>
>> Cheers,
>> Inigo
>>
>>
>>
>> bugzilla-daemon at ecoinformatics.org wrote:
>>
>>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>>>
>>>
>>>
>>>
>>>
>>> ------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
>>> This comment from an email from David Blankman:
>>> As EML is becoming an international standard, we need to start thinking
>>> about
>>> ways to make EML more intelligent about multiple languages. While EML
>>> allows
>>> multiple titles, there is currently no way to indicated that multiple
>>> titles
>>> are equivalent. For example,if I have:
>>> <title> North American Forests </title>  AND
>>> <title> Bosques de Norte Americano</title>
>>>
>>> EML currently has no way to indicate that these are the same title, just
>>> in a
>>> different language.
>>>
>>> Matt and I were talking about this at the ISEI-Cancun meeting, but I
>>> thought
>>> that it would be a good idea to get this discussion started within
>>> eml-dev and
>>> the ILTER group as well.
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
>


-- 
Nature is trying very hard to make us succeed, but nature does not depend on
us. We are not the only experiment.
 - R. Buckminster Fuller

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081208/30992102/attachment.html>

From bugzilla-daemon at ecoinformatics.org  Tue Dec  9 11:04:02 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Tue,  9 Dec 2008 11:04:02 -0800 (PST)
Subject: [eml-dev] [Bug 3444]  - xsl template needed for ulink
Message-ID: <20081209190402.601092FA87@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3444


mob at icess.ucsb.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #3 from mob at icess.ucsb.edu  2008-12-09 11:04 -------
ulink is there

From jones at nceas.ucsb.edu  Tue Dec  9 11:12:16 2008
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Tue, 9 Dec 2008 10:12:16 -0900
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
	<4939A2FD.5080401@lternet.edu>
	<fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>
	<4222aeb80812081159y4f7aa63dofd066342d43db8e9@mail.gmail.com>
	<003101c959df$dafe0770$90fa1650$@org>
	<fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>
Message-ID: <fa9a3c5e0812091112r5ae8a56bn2ce7b8bf0f29b1ea@mail.gmail.com>

The cc: list on this email thread has gotten quite long and is a bit
eclectic.  I recommend that anyone who is interested in these sorts of
discussions about metadata in general (such as these language issues) and
EML in particular should subscribe to the EML mailing list, where many
issues of this sort are discussed:
  eml-dev at ecoinformatics.org
You can sign up at this web site:
  http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml/

Matt
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081209/8981e3db/attachment.html>

From jones at nceas.ucsb.edu  Tue Dec  9 11:07:25 2008
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Tue, 9 Dec 2008 10:07:25 -0900
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <003101c959df$dafe0770$90fa1650$@org>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
	<4939A2FD.5080401@lternet.edu>
	<fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>
	<4222aeb80812081159y4f7aa63dofd066342d43db8e9@mail.gmail.com>
	<003101c959df$dafe0770$90fa1650$@org>
Message-ID: <fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>

Thanks, Eammon, for the information.  Very useful.

The frustrating thing about ISO standards is how impossible they are to
obtain.  I have an old draft copy of ISO 19115, but neither I nor the UC
library has a copy of the current standard or of the 19139.  I have a
fundamental philosophical problem with standards that are not free and
open.  Nevertheless, I will continue to try to find a copy of these so that
I can look into it.

In the meantime, a couple of comments below in your note...

On Tue, Dec 9, 2008 at 12:23 AM, Eamonn O Tuama (GBIF) <eotuama at gbif.org>wrote:

>  Hi All,
>
> I presume any extensions to EML will involve changes to the schemas and
> therefore versioning. I do not know how complicated that will be ? someone
> familiar with the EML schemas construction is best suited to answering.
> However, I think we might be able to learn something from the ISO
> 19115/19139 standard regarding multilingual metadata.
>
> First of all, it provides a distinct set of attributes for the metadata
> document itself (rather than the data the metadata document is describing).
> These include:
>
> 1. fileIdentifier
>
same as EML packageID

> 2. language
>
see my earlier discussion on this issue

> 3. characterSet
>
same as 'encoding' attribute in the XML prolog

> 4. contact
>
 why would the metadata contact be different from the data contact?  We have
trouble enough keeping one up to date

> 5. dateStamp
>
this would be useful, we should consider adding it to EML.  Presumably, this
is the date on which the metadata document was last updated, which would
probably belong in the 'maintenance' section of EML

> 6. metadataStandardname
>
provided in the namesapce of EML

> 7. metadataStandardVersion
>
provided in the namespace of EML

> 8. locale
>
this could be useful, although it seems like providing the language code
would be just as effective and essentially redundant.

> ISO 19139 (the implementation standard for the conceptual model in ISO
> 19115) also provides a means for encoding multilingual metadata. This is
> achieved through use of an optional, repeatable "locale" attribute
> consisting of language, country and characterset encodings.
>
This sounds interesting.  So, how does it repeat?  XML attributes are not
repeatable, nor do they have substructure.  Is it an element?  And if so, is
it a child element of every other element in the model?

> Multiple instances of locale may be defined for a metadata document and
> translations representing those locales provided for each metadata element.
> So, repeatability in multiple languages is built in.
>
I don't quite see how this would work.  Could you show a brief snippet as an
example.  For example, for the title of the dataset, how would you encode
two titles, each in both english and spanish, and be able to tell which of
the elements were semantically linked?  Here's one way I could see doing it,
but its a bit clunky:
 <title>
    <translation xml:lang="en">Forests of New Mexico</translation>
    <translation xml:lang="es">Bosques del Nuevo M?xico</translation>
 </title>
 <title>
    <translation xml:lang="en">Survey of Plants and Animals</translation>
    <translation xml:lang="es">Estudio de Plantas y Animales</translation>
 </title>

How would the ISO 19139 propose representing this content?

> The ability to work with multiple languages is seen as a strong advantage
> in moving from the FGDC metadata standard to the North American Profile
> (NAP) of ISO 19115. The problem, at the moment, is that a biological profile
> in ISO 19115 does not exist but it seems that work is underway to express
> the FDGC Biological Profile in ISO. (I understand that EML based their
> taxonomic module directly on the FGDC biological profile component.)
>
Actually, the BDP standard first got these fields from EML 1.3.x and 1.4.x,
and then EML 2.x reincorporated the changes from the BDP. Either way, we've
been looking at replacing the EML taxonomic module with something more in
line with TDWG standards, in particular with TCS.  I have worked out a new
set of schemas for eml-taxon with Jessie Kennedy and Bob Peet that directly
incorporate TCS, but I haven't had time to introduce these changes to the
rest of the EML community.  On the TODO list.  Nevertheless, as you said,
there's a lot of compatibility between EML and the BDP.

>
>
> The European Union, because of its composition, has always faced the
> challenge of dealing with multiple languages. A document by the European
> Committee for Standardisation (CEN) on "Geographic information ? Standards,
> specifications, technical reports and guidelines, required to implement
> Spatial Data Infrastructure" (can't find URL where I downloaded originally
> but have PDF if anyone wants it) provides some insights on "Cultural and
> Linguistic Adaptibility" where it places the emphasis on use of multilingual
> thesauri rather than efforts to translate element contents.
>
Interesting.  I'd like to see that.  So, given a metadata document in
Chinese, they are arguiing that scientists that speak other languages can
get by with multilingual thesausrus entries in place of the natural language
metadata?  I find this somewhat unconvincing if you really want to re-use
the data.

Thanks for your comments, Eammon.

Matt

> See also Nowak et al paper "Issues of multilinguality in creating a
> European SDI ? the perspective for spatial data interoperability"
>
> http://www.ec-gis.org/Workshops/11ec-gis/papers/309nowak.pdf
>
>
>
> Regards,
>
>
>
> ?amonn
>
>
>
>
>
> *From:* David Blankman [mailto:dblankman1 at gmail.com]
> *Sent:* 08 December 2008 20:59
> *To:* Matt Jones
> *Cc:* inigo san gil; eml-dev at ecoinformatics.org;
> bugzilla-daemon at ecoinformatics.org; Vivian B Hutchison;
> burkeker at gate.sinica.edu.tw; chin at tfri.gov.tw; guoxb at igsnrr.ac.cn;
> hehl at igsnrr.ac.cn; lijh at sdb.cnic.cn; Aikiko Ogawa; Eamonn O Tuama; Kristin
> Vanderbilt; Schentz Herbert; Shang; Su Wen; Werf, Bert van der
> *Subject:* Re: [eml-dev] [Bug 585] - internationalization needed in EML
>
>
>
> As I think back upon the discussions in China and my discussions with Matt
> at ISEI, it seems to me that my initial thought that multiple language
> versions of EML documents are probably better handled by creating separate
> EML documents for each language used. EML is already complex, I see no
> reason to make it more complex.
>
>
> In the ILTER situation  we are asking ILTER member networks to provide a
> core of EML in English, on the understanding that more complete metadata may
> be in another language. In this case should there be an EML module,
> eml-ilter or eml-language analogous to eml-access that specifies the
> identifier of the "main" eml-document and the language of that document.
> This module might also include an element to record a brief statement about
> the amount of data in that foreign language. I am not sure what else might
> be appropriate for this module. I know that Matt was thinking that there
> might be some modifications to metacat replication that might be needed.
>
> David
>
>
>
>
>  On Mon, Dec 8, 2008 at 1:34 PM, Matt Jones <jones at nceas.ucsb.edu> wrote:
>
> David and I discussed (briefly) some of these issues at ISEI.  And we also
> discussed them at the ILTER meeting in China.  The 'language' tag in
> eml-resource defines the language of the resource, which in the case of
> eml-dataset resources means the language of the data.  Interestingly, we
> don't really have a language tag per se for the EML document content itself,
> except that all XML documents can use the built-in "xml:lang" attribute,
> which is optional for all XML elements (
> http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one to set the
> language for each and every element in an XML document, such as:
>
> <title xml:lang="en">North American Forests</title>
> <title xml:lang="es">Bosques de Norte Americano</title>
>
> Two problems we would need to address with this approach come immedately to
> mind:
>
> 1) Many elements in EML are not repeatable, and therefore it is not
> possible to have one copy of the element in English and another in a
> different language. So cardinality would have to be updated throughout the
> EML schemas, which would make some aspects of validation more confusing.
> 2) For those elements that are already repeatable or are made repatable
> through a revision, there is no mechanism to indicate that the two element
> nodes are meant to be have the same semantic meaning in different languages,
> as opposed to two semantically different elements that happen to also differ
> in their language.
>
> This second issue is the one that would require more structural changes to
> EML.  For example, one might sometimes want to have more than one title
> (which is why title is currently repeatable), but other times want to have
> one title in two different languages.  Either way, EML's current structures
> don't allow these subtleties to be specified.
>
> Matt
>
>
>
> On Fri, Dec 5, 2008 at 12:54 PM, inigo san gil <isangil at lternet.edu>
> wrote:
>
>
> Metadata folks:
>
> I think this opens (perhaps re-opens) and interesting discussion.
>
> EML's resource (main module) offers us a <language> element that,
> as I understand it, serves to specify the language used for the document.
> The cardinality is set to <= 1, so it is optional, and if used, only one
> language.
>
> However, we understood from Kristin Valnderbilt and David Blankman
> that at a recent ILTER meeting, there was an agreement to provide
> referencial-level EML for all metadata in English (and perhaps more
> rich EML in their native languages).
> The option David proposes, providing content in two languages
> one being english, does not play well with the EML schema as is.
> There are options in the interim, while we think whether 'we' tweak
> the EML schema.  Some solutions go in the direction of "duplicating" the
> original EML record: Take what it is in the native language, and either
> have it translate at some minimal-compliance level EML (ouch) or
> run it by a translation web service and laugh (or rather cry) at the
> results.
>
> There are of course many other approaches to this problem, Mark
> Servilla mentioned some in the hallways of the LTER Network Office.
>
> The thing is that part of the international community in ecology has
> expressed formal interest/commitment in using EML to document their
> metadata. The ILTER group quickly realized of the Babelian challenge
> ahead, (see Blankman's ISEI-6 presentation & future paper) and
> David, Akiko Ocgawa and others took in helping the ILTER providing
> basic EML in english (remember ILTER committed to use English
> -chinglish and spanglish- as the lingua franca for referential level EML,
> EML level 1, title, creator, abstract, contact at least
>
> Cheers,
> Inigo
>
>
>
>
> bugzilla-daemon at ecoinformatics.org wrote:
>
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>
>
>
>
>
> ------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
> This comment from an email from David Blankman:
> As EML is becoming an international standard, we need to start thinking
> about
> ways to make EML more intelligent about multiple languages. While EML
> allows
> multiple titles, there is currently no way to indicated that multiple
> titles
> are equivalent. For example,if I have:
> <title> North American Forests </title>  AND
> <title> Bosques de Norte Americano</title>
>
> EML currently has no way to indicate that these are the same title, just in
> a
> different language.
>
> Matt and I were talking about this at the ISEI-Cancun meeting, but I
> thought
> that it would be a good idea to get this discussion started within eml-dev
> and
> the ILTER group as well.
> _______________________________________________
> 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
>
>
>
>   --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
>
>
>
> --
> Nature is trying very hard to make us succeed, but nature does not depend
> on us. We are not the only experiment.
>  - R. Buckminster Fuller
>
> 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
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081209/1806b7cb/attachment-0001.html>

From eotuama at gbif.org  Tue Dec  9 14:44:51 2008
From: eotuama at gbif.org (=?windows-1252?Q?=C9amonn_=D3_Tuama?=)
Date: Tue, 09 Dec 2008 23:44:51 +0100
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>	
	<4939A2FD.5080401@lternet.edu>	
	<fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>	
	<4222aeb80812081159y4f7aa63dofd066342d43db8e9@mail.gmail.com>	
	<003101c959df$dafe0770$90fa1650$@org>
	<fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>
Message-ID: <493EF4E3.2030405@gbif.org>

Hi Matt,

I agree about the inaccessability of ISO standards - I also had to use a 
draft release of ISO 19115. At least the ISO 19139 XSD schemas are 
freely available once you accept to a stern copyright notice. You can 
view them 
here:http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/ 
, or download as a zipped archive by going here (one dir up) and 
searching for 19139: 
http://standards.iso.org/ittf/PubliclyAvailableStandards/ .

Regarding the points you raise below -

'contact' : details for the metadata writer could be different to those 
of the data custodian, collector, etc.

'locale' : I presume using the combination of language code and country 
is because one country can have multiple languages and one language can 
be spoken in many countries.

I was using the term "attribute" in the general sense of a property and 
not in the strict XML sense of element vs attribute. 'locale' is 
actually expressed as a repeating element in ISO 19139.

I have attached an incomplete example of an ISO 19139 instance document 
to show you how I understand multiple locales are used with related, 
translated free text elements. I have based this on an example in an 
INSPIRE document  "Draft Guidelines ? INSPIRE metadata implementing 
rules based on ISO 19115 and ISO 19119" 
(http://inspire.brgm.fr/Documents/MD_IR_and_ISO_20080425.pdf)
See Section A.6, page 34 - 37.
I'm only beginning to explore the schemas themselves and the 
multilingual aspects of ISO 19139 so apart from what I have copied from 
the INSPIRE doc, the encoding in the example may not be fully correct.

I have joined the eml-dev list so I assume this will now get posted there.

?amonn



Matt Jones wrote:
> Thanks, Eammon, for the information.  Very useful.
>
> The frustrating thing about ISO standards is how impossible they are 
> to obtain.  I have an old draft copy of ISO 19115, but neither I nor 
> the UC library has a copy of the current standard or of the 19139.  I 
> have a fundamental philosophical problem with standards that are not 
> free and open.  Nevertheless, I will continue to try to find a copy of 
> these so that I can look into it.
>
> In the meantime, a couple of comments below in your note...
>
> On Tue, Dec 9, 2008 at 12:23 AM, Eamonn O Tuama (GBIF) 
> <eotuama at gbif.org <mailto:eotuama at gbif.org>> wrote:
>
>     Hi All,
>
>     I presume any extensions to EML will involve changes to the
>     schemas and therefore versioning. I do not know how complicated
>     that will be ? someone familiar with the EML schemas construction
>     is best suited to answering. However, I think we might be able to
>     learn something from the ISO 19115/19139 standard regarding
>     multilingual metadata.
>
>     First of all, it provides a distinct set of attributes for the
>     metadata document itself (rather than the data the metadata
>     document is describing). These include:
>
>     1. fileIdentifier
>
> same as EML packageID
>
>     2. language
>
> see my earlier discussion on this issue
>
>     3. characterSet
>
> same as 'encoding' attribute in the XML prolog
>
>     4. contact
>
>  why would the metadata contact be different from the data contact?  
> We have trouble enough keeping one up to date
>
>     5. dateStamp
>
> this would be useful, we should consider adding it to EML.  
> Presumably, this is the date on which the metadata document was last 
> updated, which would probably belong in the 'maintenance' section of EML
>
>     6. metadataStandardname
>
> provided in the namesapce of EML
>
>     7. metadataStandardVersion
>
> provided in the namespace of EML
>
>     8. locale
>
> this could be useful, although it seems like providing the language 
> code would be just as effective and essentially redundant.
>
>     ISO 19139 (the implementation standard for the conceptual model in
>     ISO 19115) also provides a means for encoding multilingual
>     metadata. This is achieved through use of an optional, repeatable
>     "locale" attribute consisting of language, country and
>     characterset encodings.
>
> This sounds interesting.  So, how does it repeat?  XML attributes are 
> not repeatable, nor do they have substructure.  Is it an element?  And 
> if so, is it a child element of every other element in the model?
>
>     Multiple instances of locale may be defined for a metadata
>     document and translations representing those locales provided for
>     each metadata element. So, repeatability in multiple languages is
>     built in.
>
> I don't quite see how this would work.  Could you show a brief snippet 
> as an example.  For example, for the title of the dataset, how would 
> you encode two titles, each in both english and spanish, and be able 
> to tell which of the elements were semantically linked?  Here's one 
> way I could see doing it, but its a bit clunky:
>  <title>
>     <translation xml:lang="en">Forests of New Mexico</translation>
>     <translation xml:lang="es">Bosques del Nuevo M?xico</translation>
>  </title>
>  <title>
>     <translation xml:lang="en">Survey of Plants and Animals</translation>
>     <translation xml:lang="es">Estudio de Plantas y Animales</translation>
>  </title>
>  
> How would the ISO 19139 propose representing this content?
>
>     The ability to work with multiple languages is seen as a strong
>     advantage in moving from the FGDC metadata standard to the North
>     American Profile (NAP) of ISO 19115. The problem, at the moment,
>     is that a biological profile in ISO 19115 does not exist but it
>     seems that work is underway to express the FDGC Biological Profile
>     in ISO. (I understand that EML based their taxonomic module
>     directly on the FGDC biological profile component.)
>
> Actually, the BDP standard first got these fields from EML 1.3.x and 
> 1.4.x, and then EML 2.x reincorporated the changes from the BDP. 
> Either way, we've been looking at replacing the EML taxonomic module 
> with something more in line with TDWG standards, in particular with 
> TCS.  I have worked out a new set of schemas for eml-taxon with Jessie 
> Kennedy and Bob Peet that directly incorporate TCS, but I haven't had 
> time to introduce these changes to the rest of the EML community.  On 
> the TODO list.  Nevertheless, as you said, there's a lot of 
> compatibility between EML and the BDP.
>
>      
>
>     The European Union, because of its composition, has always faced
>     the challenge of dealing with multiple languages. A document by
>     the European Committee for Standardisation (CEN) on "Geographic
>     information ? Standards, specifications, technical reports and
>     guidelines, required to implement Spatial Data Infrastructure"
>     (can't find URL where I downloaded originally but have PDF if
>     anyone wants it) provides some insights on "Cultural and
>     Linguistic Adaptibility" where it places the emphasis on use of
>     multilingual thesauri rather than efforts to translate element
>     contents.
>
> Interesting.  I'd like to see that.  So, given a metadata document in 
> Chinese, they are arguiing that scientists that speak other languages 
> can get by with multilingual thesausrus entries in place of the 
> natural language metadata?  I find this somewhat unconvincing if you 
> really want to re-use the data.
>
> Thanks for your comments, Eammon.
>
> Matt
>
>     See also Nowak et al paper "Issues of multilinguality in creating
>     a European SDI ? the perspective for spatial data interoperability"
>
>     http://www.ec-gis.org/Workshops/11ec-gis/papers/309nowak.pdf
>
>      
>
>     Regards,
>
>      
>
>     ?amonn
>
>      
>
>      
>
>     *From:* David Blankman [mailto:dblankman1 at gmail.com
>     <mailto:dblankman1 at gmail.com>]
>     *Sent:* 08 December 2008 20:59
>     *To:* Matt Jones
>     *Cc:* inigo san gil; eml-dev at ecoinformatics.org
>     <mailto:eml-dev at ecoinformatics.org>;
>     bugzilla-daemon at ecoinformatics.org
>     <mailto:bugzilla-daemon at ecoinformatics.org>; Vivian B Hutchison;
>     burkeker at gate.sinica.edu.tw <mailto:burkeker at gate.sinica.edu.tw>;
>     chin at tfri.gov.tw <mailto:chin at tfri.gov.tw>; guoxb at igsnrr.ac.cn
>     <mailto:guoxb at igsnrr.ac.cn>; hehl at igsnrr.ac.cn
>     <mailto:hehl at igsnrr.ac.cn>; lijh at sdb.cnic.cn
>     <mailto:lijh at sdb.cnic.cn>; Aikiko Ogawa; Eamonn O Tuama; Kristin
>     Vanderbilt; Schentz Herbert; Shang; Su Wen; Werf, Bert van der
>
>     *Subject:* Re: [eml-dev] [Bug 585] - internationalization needed
>     in EML
>
>      
>
>     As I think back upon the discussions in China and my discussions
>     with Matt at ISEI, it seems to me that my initial thought that
>     multiple language versions of EML documents are probably better
>     handled by creating separate EML documents for each language used.
>     EML is already complex, I see no reason to make it more complex.
>
>
>
>     In the ILTER situation  we are asking ILTER member networks to
>     provide a core of EML in English, on the understanding that more
>     complete metadata may be in another language. In this case should
>     there be an EML module, eml-ilter or eml-language analogous to
>     eml-access that specifies the identifier of the "main"
>     eml-document and the language of that document. This module might
>     also include an element to record a brief statement about the
>     amount of data in that foreign language. I am not sure what else
>     might be appropriate for this module. I know that Matt was
>     thinking that there might be some modifications to metacat
>     replication that might be needed.
>
>     David
>
>
>
>
>     On Mon, Dec 8, 2008 at 1:34 PM, Matt Jones <jones at nceas.ucsb.edu
>     <mailto:jones at nceas.ucsb.edu>> wrote:
>
>     David and I discussed (briefly) some of these issues at ISEI.  And
>     we also discussed them at the ILTER meeting in China.  The
>     'language' tag in eml-resource defines the language of the
>     resource, which in the case of eml-dataset resources means the
>     language of the data.  Interestingly, we don't really have a
>     language tag per se for the EML document content itself, except
>     that all XML documents can use the built-in "xml:lang" attribute,
>     which is optional for all XML elements
>     (http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one to
>     set the language for each and every element in an XML document,
>     such as:
>
>     <title xml:lang="en">North American Forests</title>
>     <title xml:lang="es">Bosques de Norte Americano</title>
>
>     Two problems we would need to address with this approach come
>     immedately to mind:
>
>     1) Many elements in EML are not repeatable, and therefore it is
>     not possible to have one copy of the element in English and
>     another in a different language. So cardinality would have to be
>     updated throughout the EML schemas, which would make some aspects
>     of validation more confusing.
>     2) For those elements that are already repeatable or are made
>     repatable through a revision, there is no mechanism to indicate
>     that the two element nodes are meant to be have the same semantic
>     meaning in different languages, as opposed to two semantically
>     different elements that happen to also differ in their language.
>
>     This second issue is the one that would require more structural
>     changes to EML.  For example, one might sometimes want to have
>     more than one title (which is why title is currently repeatable),
>     but other times want to have one title in two different
>     languages.  Either way, EML's current structures don't allow these
>     subtleties to be specified.
>
>     Matt
>
>      
>
>     On Fri, Dec 5, 2008 at 12:54 PM, inigo san gil
>     <isangil at lternet.edu <mailto:isangil at lternet.edu>> wrote:
>
>
>     Metadata folks:
>
>     I think this opens (perhaps re-opens) and interesting discussion.
>
>     EML's resource (main module) offers us a <language> element that,
>     as I understand it, serves to specify the language used for the
>     document.
>     The cardinality is set to <= 1, so it is optional, and if used,
>     only one
>     language.
>
>     However, we understood from Kristin Valnderbilt and David Blankman
>     that at a recent ILTER meeting, there was an agreement to provide
>     referencial-level EML for all metadata in English (and perhaps more
>     rich EML in their native languages).
>     The option David proposes, providing content in two languages
>     one being english, does not play well with the EML schema as is.
>     There are options in the interim, while we think whether 'we' tweak
>     the EML schema.  Some solutions go in the direction of
>     "duplicating" the
>     original EML record: Take what it is in the native language, and
>     either
>     have it translate at some minimal-compliance level EML (ouch) or
>     run it by a translation web service and laugh (or rather cry) at
>     the results.
>
>     There are of course many other approaches to this problem, Mark
>     Servilla mentioned some in the hallways of the LTER Network Office.
>
>     The thing is that part of the international community in ecology has
>     expressed formal interest/commitment in using EML to document their
>     metadata. The ILTER group quickly realized of the Babelian challenge
>     ahead, (see Blankman's ISEI-6 presentation & future paper) and
>     David, Akiko Ocgawa and others took in helping the ILTER providing
>     basic EML in english (remember ILTER committed to use English
>     -chinglish and spanglish- as the lingua franca for referential
>     level EML,
>     EML level 1, title, creator, abstract, contact at least
>
>     Cheers,
>     Inigo
>
>
>
>
>     bugzilla-daemon at ecoinformatics.org
>     <mailto:bugzilla-daemon at ecoinformatics.org> wrote:
>
>     http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>
>
>
>
>
>     ------- Comment #2 from mob at icess.ucsb.edu
>     <mailto:mob at icess.ucsb.edu>  2008-12-05 09:31 -------
>     This comment from an email from David Blankman:
>     As EML is becoming an international standard, we need to start
>     thinking about
>     ways to make EML more intelligent about multiple languages. While
>     EML allows
>     multiple titles, there is currently no way to indicated that
>     multiple titles
>     are equivalent. For example,if I have:
>     <title> North American Forests </title>  AND
>     <title> Bosques de Norte Americano</title>
>
>     EML currently has no way to indicate that these are the same
>     title, just in a
>     different language.
>
>     Matt and I were talking about this at the ISEI-Cancun meeting, but
>     I thought
>     that it would be a good idea to get this discussion started within
>     eml-dev and
>     the ILTER group as well.
>     _______________________________________________
>     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
>
>
>
>     -- 
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     Matthew B. Jones
>     Director of Informatics Research and Development
>     National Center for Ecological Analysis and Synthesis (NCEAS)
>     UC Santa Barbara
>     jones at nceas.ucsb.edu <mailto:jones at nceas.ucsb.edu>                
>           Ph: 1-907-523-1960
>     http://www.nceas.ucsb.edu/ecoinfo
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>     _______________________________________________
>     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
>
>
>
>
>     -- 
>     Nature is trying very hard to make us succeed, but nature does not
>     depend on us. We are not the only experiment.
>      - R. Buckminster Fuller
>
>     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
>
>
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu <mailto:jones at nceas.ucsb.edu>                     
>   Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081209/09c3e1a1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISO-19139-multilingual-example.xml
Type: text/xml
Size: 1757 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081209/09c3e1a1/attachment-0001.xml>

From bugzilla-daemon at ecoinformatics.org  Tue Dec  9 15:15:31 2008
From: bugzilla-daemon at ecoinformatics.org (bugzilla-daemon at ecoinformatics.org)
Date: Tue,  9 Dec 2008 15:15:31 -0800 (PST)
Subject: [eml-dev] [Bug 585]  - internationalization needed in EML
Message-ID: <20081209231531.185BD2FA86@ceres.ecoinformatics.org>

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585





------- Comment #4 from jones at nceas.ucsb.edu  2008-12-09 15:15 -------
After more conversation on the email list, it seems that the approach to
localization used in ISO 19139 may be applicable here.  A fragment of a 19139
document might include:

<abstract xsi:type="PT_FreeText_PropertyType">
  <gco:CharacterString>Brief narrative summary of the content of the
resource</gco:CharacterString>
  <!--== Alternative value ==-->
  <PT_FreeText>
    <textGroup>
      <LocalisedCharacterString locale="#locale-fr">R??sum?? succinct
du contenu de la ressource</LocalisedCharacterString>
    </textGroup>
  </PT_FreeText>
</abstract>

So, the PT_FreeText_PropertyType is very similar in concept to the EML
TextType.  We could indeed define a new LocalizedTextType that use this same
trick, basically allowing textGroup subelements with alternate language
strings.  Or we could simply use the definition of PT_FreeText in EML via an
import (except that there may be restrictions on free reuse of ISO standards,
which would prevent us from incorporating such a thing directly in EML, as
redistribution is critical to an open standard). Although the naming
conventions they've used are not particularly readable.

Note that this approach depends on a previously defined locale
(locale="#locale-fr"), which is provided by a different set of elements earlier
in the metadata for defining locales.  The local defines both a language code
and a character encoding for strings in that locale:

  <locale> 
    <PT_Locale id="locale-fr"> 
      <languageCode> 
        <LanguageCode  
           codeList="resources/Codelist/gmxcodelists.xml# 
LanguageCode" 
           codeListValue="fra"> French </LanguageCode> 
      </languageCode> 
      <characterEncoding> 
        <MD_CharacterSetCode 
         codeList="resources/Codelist/gmxcodelists.xml# 
MD_CharacterSetCode" 
         codeListValue="utf8">UTF 8</MD_CharacterSetCode> 
      </characterEncoding> 
   </PT_Locale> 
  </locale> 

This is powerful, but it seems to me that the characterEncoding could get one
in trouble with XML parsers if the locale character encoding differs from the
encoding defined in the XML Prolog.  As far as I know, an XML document can have
one and only one character encoding, so mixing different elements with
different encodings will probably mess up standard XML processors.  This would
have to be explored to see if it is a significant issue.

From jones at nceas.ucsb.edu  Tue Dec  9 15:08:02 2008
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Tue, 9 Dec 2008 14:08:02 -0900
Subject: [eml-dev] [Bug 585] - internationalization needed in EML
In-Reply-To: <493EF4E3.2030405@gbif.org>
References: <20081205173144.A165A2FA87@ceres.ecoinformatics.org>
	<4939A2FD.5080401@lternet.edu>
	<fa9a3c5e0812081034g4448c2dej1ee0b11edbbb8fe2@mail.gmail.com>
	<4222aeb80812081159y4f7aa63dofd066342d43db8e9@mail.gmail.com>
	<003101c959df$dafe0770$90fa1650$@org>
	<fa9a3c5e0812091107y92fd2d1w958a3e855cbfa4e@mail.gmail.com>
	<493EF4E3.2030405@gbif.org>
Message-ID: <fa9a3c5e0812091508x349c6906q2ea31a98278f8378@mail.gmail.com>

Hi ?amonn,

Thanks for the INSPIRE document.  That clarified things a lot.  The section
A.6.3 was particularly useful.  The crux seems to be that they have defined
a complex type called PT_FreeText_PropertyType that allows a simple
character string in the default language to be accompanied by one or more
versions in other languages.  So, for abstract, they would have:

<abstract xsi:type="PT_FreeText_PropertyType">
  <gco:CharacterString>Brief narrative summary of the content of the
resource</gco:CharacterString>
  <!--== Alternative value ==-->
  <PT_FreeText>
    <textGroup>
      <LocalisedCharacterString locale="#locale-fr">R?sum? succinct
du contenu de la ressource</LocalisedCharacterString>
    </textGroup>
  </PT_FreeText>
</abstract>

So, the PT_FreeText_PropertyType is very similar in concept to the EML
TextType.  We could indeed define a new set of types that use this same
trick, basically allowing textGroup subelements with alternate language
strings.  Or we could simply use the definition of PT_FreeText in EML via an
import (except that there may be restrictions on free reuse of ISO
standards, which would prevent us from incorporating such a thing directly
in EML, as redistribution is critical to an open standard).

I'll add this to the bugzilla bug for a record of the discussion for EML
developers.

Matt

On Tue, Dec 9, 2008 at 1:44 PM, ?amonn ? Tuama <eotuama at gbif.org> wrote:

>  Hi Matt,
>
> I agree about the inaccessability of ISO standards - I also had to use a
> draft release of ISO 19115. At least the ISO 19139 XSD schemas are freely
> available once you accept to a stern copyright notice. You can view them
> here:
> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/, or download as a zipped archive by going here (one dir up) and searching
> for 19139: http://standards.iso.org/ittf/PubliclyAvailableStandards/ .
>
> Regarding the points you raise below -
>
> 'contact' : details for the metadata writer could be different to those of
> the data custodian, collector, etc.
>
> 'locale' : I presume using the combination of language code and country is
> because one country can have multiple languages and one language can be
> spoken in many countries.
>
> I was using the term "attribute" in the general sense of a property and not
> in the strict XML sense of element vs attribute. 'locale' is actually
> expressed as a repeating element in ISO 19139.
>
> I have attached an incomplete example of an ISO 19139 instance document to
> show you how I understand multiple locales are used with related, translated
> free text elements. I have based this on an example in an INSPIRE document
> "Draft Guidelines ? INSPIRE metadata implementing rules based on ISO 19115
> and ISO 19119" (
> http://inspire.brgm.fr/Documents/MD_IR_and_ISO_20080425.pdf)
> See Section A.6, page 34 - 37.
> I'm only beginning to explore the schemas themselves and the multilingual
> aspects of ISO 19139 so apart from what I have copied from the INSPIRE doc,
> the encoding in the example may not be fully correct.
>
> I have joined the eml-dev list so I assume this will now get posted there.
>
> ?amonn
>
>
>
>
> Matt Jones wrote:
>
> Thanks, Eammon, for the information.  Very useful.
>
> The frustrating thing about ISO standards is how impossible they are to
> obtain.  I have an old draft copy of ISO 19115, but neither I nor the UC
> library has a copy of the current standard or of the 19139.  I have a
> fundamental philosophical problem with standards that are not free and
> open.  Nevertheless, I will continue to try to find a copy of these so that
> I can look into it.
>
> In the meantime, a couple of comments below in your note...
>
> On Tue, Dec 9, 2008 at 12:23 AM, Eamonn O Tuama (GBIF) <eotuama at gbif.org>wrote:
>
>>  Hi All,
>>
>> I presume any extensions to EML will involve changes to the schemas and
>> therefore versioning. I do not know how complicated that will be ? someone
>> familiar with the EML schemas construction is best suited to answering.
>> However, I think we might be able to learn something from the ISO
>> 19115/19139 standard regarding multilingual metadata.
>>
>> First of all, it provides a distinct set of attributes for the metadata
>> document itself (rather than the data the metadata document is describing).
>> These include:
>>
>> 1. fileIdentifier
>>
> same as EML packageID
>
>>   2. language
>>
> see my earlier discussion on this issue
>
>>   3. characterSet
>>
> same as 'encoding' attribute in the XML prolog
>
>>   4. contact
>>
>  why would the metadata contact be different from the data contact?  We
> have trouble enough keeping one up to date
>
>>   5. dateStamp
>>
> this would be useful, we should consider adding it to EML.  Presumably,
> this is the date on which the metadata document was last updated, which
> would probably belong in the 'maintenance' section of EML
>
>>   6. metadataStandardname
>>
> provided in the namesapce of EML
>
>>   7. metadataStandardVersion
>>
> provided in the namespace of EML
>
>>   8. locale
>>
> this could be useful, although it seems like providing the language code
> would be just as effective and essentially redundant.
>
>>   ISO 19139 (the implementation standard for the conceptual model in ISO
>> 19115) also provides a means for encoding multilingual metadata. This is
>> achieved through use of an optional, repeatable "locale" attribute
>> consisting of language, country and characterset encodings.
>>
> This sounds interesting.  So, how does it repeat?  XML attributes are not
> repeatable, nor do they have substructure.  Is it an element?  And if so, is
> it a child element of every other element in the model?
>
>>  Multiple instances of locale may be defined for a metadata document and
>> translations representing those locales provided for each metadata element.
>> So, repeatability in multiple languages is built in.
>>
> I don't quite see how this would work.  Could you show a brief snippet as
> an example.  For example, for the title of the dataset, how would you encode
> two titles, each in both english and spanish, and be able to tell which of
> the elements were semantically linked?  Here's one way I could see doing it,
> but its a bit clunky:
>  <title>
>     <translation xml:lang="en">Forests of New Mexico</translation>
>     <translation xml:lang="es">Bosques del Nuevo M?xico</translation>
>  </title>
>  <title>
>     <translation xml:lang="en">Survey of Plants and Animals</translation>
>     <translation xml:lang="es">Estudio de Plantas y Animales</translation>
>  </title>
>
> How would the ISO 19139 propose representing this content?
>
>>  The ability to work with multiple languages is seen as a strong
>> advantage in moving from the FGDC metadata standard to the North American
>> Profile (NAP) of ISO 19115. The problem, at the moment, is that a biological
>> profile in ISO 19115 does not exist but it seems that work is underway to
>> express the FDGC Biological Profile in ISO. (I understand that EML based
>> their taxonomic module directly on the FGDC biological profile component.)
>>
> Actually, the BDP standard first got these fields from EML 1.3.x and 1.4.x,
> and then EML 2.x reincorporated the changes from the BDP. Either way, we've
> been looking at replacing the EML taxonomic module with something more in
> line with TDWG standards, in particular with TCS.  I have worked out a new
> set of schemas for eml-taxon with Jessie Kennedy and Bob Peet that directly
> incorporate TCS, but I haven't had time to introduce these changes to the
> rest of the EML community.  On the TODO list.  Nevertheless, as you said,
> there's a lot of compatibility between EML and the BDP.
>
>>
>>
>> The European Union, because of its composition, has always faced the
>> challenge of dealing with multiple languages. A document by the European
>> Committee for Standardisation (CEN) on "Geographic information ? Standards,
>> specifications, technical reports and guidelines, required to implement
>> Spatial Data Infrastructure" (can't find URL where I downloaded originally
>> but have PDF if anyone wants it) provides some insights on "Cultural and
>> Linguistic Adaptibility" where it places the emphasis on use of multilingual
>> thesauri rather than efforts to translate element contents.
>>
> Interesting.  I'd like to see that.  So, given a metadata document in
> Chinese, they are arguiing that scientists that speak other languages can
> get by with multilingual thesausrus entries in place of the natural language
> metadata?  I find this somewhat unconvincing if you really want to re-use
> the data.
>
> Thanks for your comments, Eammon.
>
> Matt
>
>>   See also Nowak et al paper "Issues of multilinguality in creating a
>> European SDI ? the perspective for spatial data interoperability"
>>
>> http://www.ec-gis.org/Workshops/11ec-gis/papers/309nowak.pdf
>>
>>
>>
>> Regards,
>>
>>
>>
>> ?amonn
>>
>>
>>
>>
>>
>> *From:* David Blankman [mailto:dblankman1 at gmail.com]
>> *Sent:* 08 December 2008 20:59
>> *To:* Matt Jones
>> *Cc:* inigo san gil; eml-dev at ecoinformatics.org;
>> bugzilla-daemon at ecoinformatics.org; Vivian B Hutchison;
>> burkeker at gate.sinica.edu.tw; chin at tfri.gov.tw; guoxb at igsnrr.ac.cn;
>> hehl at igsnrr.ac.cn; lijh at sdb.cnic.cn; Aikiko Ogawa; Eamonn O Tuama;
>> Kristin Vanderbilt; Schentz Herbert; Shang; Su Wen; Werf, Bert van der
>> *Subject:* Re: [eml-dev] [Bug 585] - internationalization needed in EML
>>
>>
>>
>> As I think back upon the discussions in China and my discussions with Matt
>> at ISEI, it seems to me that my initial thought that multiple language
>> versions of EML documents are probably better handled by creating separate
>> EML documents for each language used. EML is already complex, I see no
>> reason to make it more complex.
>>
>>
>> In the ILTER situation  we are asking ILTER member networks to provide a
>> core of EML in English, on the understanding that more complete metadata may
>> be in another language. In this case should there be an EML module,
>> eml-ilter or eml-language analogous to eml-access that specifies the
>> identifier of the "main" eml-document and the language of that document.
>> This module might also include an element to record a brief statement about
>> the amount of data in that foreign language. I am not sure what else might
>> be appropriate for this module. I know that Matt was thinking that there
>> might be some modifications to metacat replication that might be needed.
>>
>> David
>>
>>
>>
>>
>>    On Mon, Dec 8, 2008 at 1:34 PM, Matt Jones <jones at nceas.ucsb.edu>
>> wrote:
>>
>> David and I discussed (briefly) some of these issues at ISEI.  And we also
>> discussed them at the ILTER meeting in China.  The 'language' tag in
>> eml-resource defines the language of the resource, which in the case of
>> eml-dataset resources means the language of the data.  Interestingly, we
>> don't really have a language tag per se for the EML document content itself,
>> except that all XML documents can use the built-in "xml:lang" attribute,
>> which is optional for all XML elements (
>> http://www.w3.org/TR/REC-xml/#sec-lang-tag).  This allows one to set the
>> language for each and every element in an XML document, such as:
>>
>> <title xml:lang="en">North American Forests</title>
>> <title xml:lang="es">Bosques de Norte Americano</title>
>>
>> Two problems we would need to address with this approach come immedately
>> to mind:
>>
>> 1) Many elements in EML are not repeatable, and therefore it is not
>> possible to have one copy of the element in English and another in a
>> different language. So cardinality would have to be updated throughout the
>> EML schemas, which would make some aspects of validation more confusing.
>> 2) For those elements that are already repeatable or are made repatable
>> through a revision, there is no mechanism to indicate that the two element
>> nodes are meant to be have the same semantic meaning in different languages,
>> as opposed to two semantically different elements that happen to also differ
>> in their language.
>>
>> This second issue is the one that would require more structural changes to
>> EML.  For example, one might sometimes want to have more than one title
>> (which is why title is currently repeatable), but other times want to have
>> one title in two different languages.  Either way, EML's current structures
>> don't allow these subtleties to be specified.
>>
>> Matt
>>
>>
>>
>> On Fri, Dec 5, 2008 at 12:54 PM, inigo san gil <isangil at lternet.edu>
>> wrote:
>>
>>
>> Metadata folks:
>>
>> I think this opens (perhaps re-opens) and interesting discussion.
>>
>> EML's resource (main module) offers us a <language> element that,
>> as I understand it, serves to specify the language used for the document.
>> The cardinality is set to <= 1, so it is optional, and if used, only one
>> language.
>>
>> However, we understood from Kristin Valnderbilt and David Blankman
>> that at a recent ILTER meeting, there was an agreement to provide
>> referencial-level EML for all metadata in English (and perhaps more
>> rich EML in their native languages).
>> The option David proposes, providing content in two languages
>> one being english, does not play well with the EML schema as is.
>> There are options in the interim, while we think whether 'we' tweak
>> the EML schema.  Some solutions go in the direction of "duplicating" the
>> original EML record: Take what it is in the native language, and either
>> have it translate at some minimal-compliance level EML (ouch) or
>> run it by a translation web service and laugh (or rather cry) at the
>> results.
>>
>> There are of course many other approaches to this problem, Mark
>> Servilla mentioned some in the hallways of the LTER Network Office.
>>
>> The thing is that part of the international community in ecology has
>> expressed formal interest/commitment in using EML to document their
>> metadata. The ILTER group quickly realized of the Babelian challenge
>> ahead, (see Blankman's ISEI-6 presentation & future paper) and
>> David, Akiko Ocgawa and others took in helping the ILTER providing
>> basic EML in english (remember ILTER committed to use English
>> -chinglish and spanglish- as the lingua franca for referential level EML,
>> EML level 1, title, creator, abstract, contact at least
>>
>> Cheers,
>> Inigo
>>
>>
>>
>>
>> bugzilla-daemon at ecoinformatics.org wrote:
>>
>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=585
>>
>>
>>
>>
>>
>> ------- Comment #2 from mob at icess.ucsb.edu  2008-12-05 09:31 -------
>> This comment from an email from David Blankman:
>> As EML is becoming an international standard, we need to start thinking
>> about
>> ways to make EML more intelligent about multiple languages. While EML
>> allows
>> multiple titles, there is currently no way to indicated that multiple
>> titles
>> are equivalent. For example,if I have:
>> <title> North American Forests </title>  AND
>> <title> Bosques de Norte Americano</title>
>>
>> EML currently has no way to indicate that these are the same title, just
>> in a
>> different language.
>>
>> Matt and I were talking about this at the ISEI-Cancun meeting, but I
>> thought
>> that it would be a good idea to get this discussion started within eml-dev
>> and
>> the ILTER group as well.
>> _______________________________________________
>> 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
>>
>>
>>
>>   --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Matthew B. Jones
>> Director of Informatics Research and Development
>> National Center for Ecological Analysis and Synthesis (NCEAS)
>> UC Santa Barbara
>> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
>> http://www.nceas.ucsb.edu/ecoinfo
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>
>>
>>
>>
>> --
>> Nature is trying very hard to make us succeed, but nature does not depend
>> on us. We are not the only experiment.
>>  - R. Buckminster Fuller
>>
>> 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
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20081209/8b3444c1/attachment-0001.html>

From tao at nceas.ucsb.edu  Fri Dec 12 21:26:20 2008
From: tao at nceas.ucsb.edu (Jing Tao)
Date: Fri, 12 Dec 2008 21:26:20 -0800 (PST)
Subject: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
Message-ID: <Pine.LNX.4.63.0812121842050.19337@mercury.nceas.ucsb.edu>

Hi, Margaret:

I am writting a java program to transform eml201(eml200) documents to 
eml210 in a Metacat by the style sheet from eml module. It works now in my 
test server. But I found a issue here:

In some eml201 documents, some elements, e.g. objectName, have a 
space as text value. It is valid in eml201. After transforming to 
eml210 document, the space value will be kept there. However, current eml-210 
schema doesn't allow the value to be a space. This results that the 
generated eml210 document is invalid.

I guess there are maybe two possible solutions:

First, change the eml schema - back to string type rather than non-empty 
string type in those elements.

Second, in the eml201to210.xsl style sheet, if it finds the text value of 
a leaf node is a space, replace the space by some other text - such as 
"Unavailable".

Do you have any suggestion on this?

Thanks,

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

From mob at icess.ucsb.edu  Mon Dec 15 08:30:10 2008
From: mob at icess.ucsb.edu (Margaret O'Brien)
Date: Mon, 15 Dec 2008 08:30:10 -0800
Subject: [eml-dev] Fwd: Issue on transforming from eml-2.0.1 to eml-2.1.0
In-Reply-To: <fa9a3c5e0812122216v5a487f6cp844bcc4334f6544c@mail.gmail.com>
References: <Pine.LNX.4.63.0812121842050.19337@mercury.nceas.ucsb.edu>	
	<fa9a3c5e0812122214n71cd9d20gd4e5ba6a542ddfa9@mail.gmail.com>
	<fa9a3c5e0812122216v5a487f6cp844bcc4334f6544c@mail.gmail.com>
Message-ID: <49468612.8070303@icess.ucsb.edu>

The problem is a Morpho feature that allows an author to completely 
describe a dataTable without actually attaching it, and  objectName is a 
required child of dataTable. To accommodate this, Morpho has been 
putting a single space into the objectName field to meet the "content" 
requirement of xs:string. So it seems that there are these choices: come 
up with an acceptable string for Morpho to use in these cases and leave 
the schema alone, define another type so Morpho can have some other 
acceptable content, make objectName optional, or remove this feature 
from Morpho.

As far as strings like ' ' , and '\t' --  these have always been 
legitimate fieldDelimeters. '\t' is allowed by the pattern currently in 
the NonEmptyStringType. But since ' ' was not, I reset the types for 
*Delimeters back to xs:string. We could define a separate pattern for 
delimeters and create very specific examples


Matt Jones wrote:
> Discussion merited sometime soon?
>
> Matt
>
>
> ---------- Forwarded message ----------
> From: Matt Jones <jones at nceas.ucsb.edu>
> Date: Fri, Dec 12, 2008 at 9:14 PM
> Subject: Re: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
> To: Jing Tao <tao at nceas.ucsb.edu>
>
>
> The whole point of changing the schema was to prevent people from
> leaving required elements with empty content.  Changing it to
> 'Unavailable' is equally unappealing.  If we will accept 'Unavailable'
> as a schema choice, we might as well just go ahead and make all
> elements in EML optional so that people don't have to put in some
> garbage text just to get it to validate.  But if we agree that there
> are minimum requirements for things to make sense, then we also
> shouldn't accept '', ' ', '\t', 'N/A', 'Unavailable' or any other
> non-content placeholder.  Unfortunately, we can't stop people from
> doing this through purely technical means, but at least its clear to
> them that its not appropriate with the new content model.
>
> The downside, of course, is that it prevents automatic and full
> translation from eml 2.0.1 to eml 2.1, but we knew they were not
> backwards compatible, so this won't be the only case.
>
> Matt
>
> On Fri, Dec 12, 2008 at 8:26 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>   
>> Hi, Margaret:
>>
>> I am writting a java program to transform eml201(eml200) documents to eml210
>> in a Metacat by the style sheet from eml module. It works now in my test
>> server. But I found a issue here:
>>
>> In some eml201 documents, some elements, e.g. objectName, have a space as
>> text value. It is valid in eml201. After transforming to eml210 document,
>> the space value will be kept there. However, current eml-210 schema doesn't
>> allow the value to be a space. This results that the generated eml210
>> document is invalid.
>>
>> I guess there are maybe two possible solutions:
>>
>> First, change the eml schema - back to string type rather than non-empty
>> string type in those elements.
>>
>> Second, in the eml201to210.xsl style sheet, if it finds the text value of a
>> leaf node is a space, replace the space by some other text - such as
>> "Unavailable".
>>
>> Do you have any suggestion on this?
>>
>> Thanks,
>>
>> Jing
>>
>> Jing Tao
>> National Center for Ecological
>> Analysis and Synthesis (NCEAS)
>> 735 State St. Suite 204
>> Santa Barbara, CA 93101
>> _______________________________________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>
>>     
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>   

-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================


From jones at nceas.ucsb.edu  Mon Dec 15 09:24:34 2008
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Mon, 15 Dec 2008 08:24:34 -0900
Subject: [eml-dev] Fwd: Issue on transforming from eml-2.0.1 to eml-2.1.0
In-Reply-To: <49468612.8070303@icess.ucsb.edu>
References: <Pine.LNX.4.63.0812121842050.19337@mercury.nceas.ucsb.edu>
	<fa9a3c5e0812122214n71cd9d20gd4e5ba6a542ddfa9@mail.gmail.com>
	<fa9a3c5e0812122216v5a487f6cp844bcc4334f6544c@mail.gmail.com>
	<49468612.8070303@icess.ucsb.edu>
Message-ID: <fa9a3c5e0812150924k4a23aff2ic982bc59aa42f3fb@mail.gmail.com>

Hi Margaret,

I think Morpho should be able to fill in the objectName even if they
don't upload the file -- the name still exists. I agree that the
delimiter fields should allow whitespace characters because whitespace
is legitimate as delimiters, but it seems like Morpho should be able
to deal with providing the objectName even if it is required and
doesn't allow just whitespace.  I must be missing a critical issue
here, because this doesn't seem like a problem to me.

Matt

On Mon, Dec 15, 2008 at 7:30 AM, Margaret O'Brien <mob at icess.ucsb.edu> wrote:
> The problem is a Morpho feature that allows an author to completely describe
> a dataTable without actually attaching it, and  objectName is a required
> child of dataTable. To accommodate this, Morpho has been putting a single
> space into the objectName field to meet the "content" requirement of
> xs:string. So it seems that there are these choices: come up with an
> acceptable string for Morpho to use in these cases and leave the schema
> alone, define another type so Morpho can have some other acceptable content,
> make objectName optional, or remove this feature from Morpho.
>
> As far as strings like ' ' , and '\t' --  these have always been legitimate
> fieldDelimeters. '\t' is allowed by the pattern currently in the
> NonEmptyStringType. But since ' ' was not, I reset the types for *Delimeters
> back to xs:string. We could define a separate pattern for delimeters and
> create very specific examples
>
>
> Matt Jones wrote:
>>
>> Discussion merited sometime soon?
>>
>> Matt
>>
>>
>> ---------- Forwarded message ----------
>> From: Matt Jones <jones at nceas.ucsb.edu>
>> Date: Fri, Dec 12, 2008 at 9:14 PM
>> Subject: Re: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
>> To: Jing Tao <tao at nceas.ucsb.edu>
>>
>>
>> The whole point of changing the schema was to prevent people from
>> leaving required elements with empty content.  Changing it to
>> 'Unavailable' is equally unappealing.  If we will accept 'Unavailable'
>> as a schema choice, we might as well just go ahead and make all
>> elements in EML optional so that people don't have to put in some
>> garbage text just to get it to validate.  But if we agree that there
>> are minimum requirements for things to make sense, then we also
>> shouldn't accept '', ' ', '\t', 'N/A', 'Unavailable' or any other
>> non-content placeholder.  Unfortunately, we can't stop people from
>> doing this through purely technical means, but at least its clear to
>> them that its not appropriate with the new content model.
>>
>> The downside, of course, is that it prevents automatic and full
>> translation from eml 2.0.1 to eml 2.1, but we knew they were not
>> backwards compatible, so this won't be the only case.
>>
>> Matt
>>
>> On Fri, Dec 12, 2008 at 8:26 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>>
>>>
>>> Hi, Margaret:
>>>
>>> I am writting a java program to transform eml201(eml200) documents to
>>> eml210
>>> in a Metacat by the style sheet from eml module. It works now in my test
>>> server. But I found a issue here:
>>>
>>> In some eml201 documents, some elements, e.g. objectName, have a space as
>>> text value. It is valid in eml201. After transforming to eml210 document,
>>> the space value will be kept there. However, current eml-210 schema
>>> doesn't
>>> allow the value to be a space. This results that the generated eml210
>>> document is invalid.
>>>
>>> I guess there are maybe two possible solutions:
>>>
>>> First, change the eml schema - back to string type rather than non-empty
>>> string type in those elements.
>>>
>>> Second, in the eml201to210.xsl style sheet, if it finds the text value of
>>> a
>>> leaf node is a space, replace the space by some other text - such as
>>> "Unavailable".
>>>
>>> Do you have any suggestion on this?
>>>
>>> Thanks,
>>>
>>> Jing
>>>
>>> Jing Tao
>>> National Center for Ecological
>>> Analysis and Synthesis (NCEAS)
>>> 735 State St. Suite 204
>>> Santa Barbara, CA 93101
>>> _______________________________________________
>>> Eml-dev mailing list
>>> Eml-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>>
>>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Matthew B. Jones
>> Director of Informatics Research and Development
>> National Center for Ecological Analysis and Synthesis (NCEAS)
>> UC Santa Barbara
>> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
>> http://www.nceas.ucsb.edu/ecoinfo
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>
>
> --
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA  93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From mob at icess.ucsb.edu  Mon Dec 15 09:35:05 2008
From: mob at icess.ucsb.edu (Margaret O'Brien)
Date: Mon, 15 Dec 2008 09:35:05 -0800
Subject: [eml-dev] Fwd: Issue on transforming from eml-2.0.1 to eml-2.1.0
In-Reply-To: <fa9a3c5e0812150924k4a23aff2ic982bc59aa42f3fb@mail.gmail.com>
References: <Pine.LNX.4.63.0812121842050.19337@mercury.nceas.ucsb.edu>	
	<fa9a3c5e0812122214n71cd9d20gd4e5ba6a542ddfa9@mail.gmail.com>	
	<fa9a3c5e0812122216v5a487f6cp844bcc4334f6544c@mail.gmail.com>	
	<49468612.8070303@icess.ucsb.edu>
	<fa9a3c5e0812150924k4a23aff2ic982bc59aa42f3fb@mail.gmail.com>
Message-ID: <49469549.7060303@icess.ucsb.edu>

Morpho should just ask for an objectName, then, even if the table is not 
included. One way to use this feature (along with the "save duplicate") 
is for creating/editing a template.

However, I noticed something else (Morpho 1.6.1):
you can describe and save a package with an empty table, ie, the 
template --  no problem.
but when you to to edit it (or a saved duplicate), clicking the OK 
button results in:
"Unable to trim following nodes:
eml/dataset/(CHOICE)/dataTable(SEQUENCE)/physical/(SEQUENCE)/objectName"

when all it has is the ' '.  So Morpho already cannot handle the 
empty-string content.

margaret


Matt Jones wrote:
> Hi Margaret,
>
> I think Morpho should be able to fill in the objectName even if they
> don't upload the file -- the name still exists. I agree that the
> delimiter fields should allow whitespace characters because whitespace
> is legitimate as delimiters, but it seems like Morpho should be able
> to deal with providing the objectName even if it is required and
> doesn't allow just whitespace.  I must be missing a critical issue
> here, because this doesn't seem like a problem to me.
>
> Matt
>
> On Mon, Dec 15, 2008 at 7:30 AM, Margaret O'Brien <mob at icess.ucsb.edu> wrote:
>   
>> The problem is a Morpho feature that allows an author to completely describe
>> a dataTable without actually attaching it, and  objectName is a required
>> child of dataTable. To accommodate this, Morpho has been putting a single
>> space into the objectName field to meet the "content" requirement of
>> xs:string. So it seems that there are these choices: come up with an
>> acceptable string for Morpho to use in these cases and leave the schema
>> alone, define another type so Morpho can have some other acceptable content,
>> make objectName optional, or remove this feature from Morpho.
>>
>> As far as strings like ' ' , and '\t' --  these have always been legitimate
>> fieldDelimeters. '\t' is allowed by the pattern currently in the
>> NonEmptyStringType. But since ' ' was not, I reset the types for *Delimeters
>> back to xs:string. We could define a separate pattern for delimeters and
>> create very specific examples
>>
>>
>> Matt Jones wrote:
>>     
>>> Discussion merited sometime soon?
>>>
>>> Matt
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Matt Jones <jones at nceas.ucsb.edu>
>>> Date: Fri, Dec 12, 2008 at 9:14 PM
>>> Subject: Re: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
>>> To: Jing Tao <tao at nceas.ucsb.edu>
>>>
>>>
>>> The whole point of changing the schema was to prevent people from
>>> leaving required elements with empty content.  Changing it to
>>> 'Unavailable' is equally unappealing.  If we will accept 'Unavailable'
>>> as a schema choice, we might as well just go ahead and make all
>>> elements in EML optional so that people don't have to put in some
>>> garbage text just to get it to validate.  But if we agree that there
>>> are minimum requirements for things to make sense, then we also
>>> shouldn't accept '', ' ', '\t', 'N/A', 'Unavailable' or any other
>>> non-content placeholder.  Unfortunately, we can't stop people from
>>> doing this through purely technical means, but at least its clear to
>>> them that its not appropriate with the new content model.
>>>
>>> The downside, of course, is that it prevents automatic and full
>>> translation from eml 2.0.1 to eml 2.1, but we knew they were not
>>> backwards compatible, so this won't be the only case.
>>>
>>> Matt
>>>
>>> On Fri, Dec 12, 2008 at 8:26 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>>>
>>>       
>>>> Hi, Margaret:
>>>>
>>>> I am writting a java program to transform eml201(eml200) documents to
>>>> eml210
>>>> in a Metacat by the style sheet from eml module. It works now in my test
>>>> server. But I found a issue here:
>>>>
>>>> In some eml201 documents, some elements, e.g. objectName, have a space as
>>>> text value. It is valid in eml201. After transforming to eml210 document,
>>>> the space value will be kept there. However, current eml-210 schema
>>>> doesn't
>>>> allow the value to be a space. This results that the generated eml210
>>>> document is invalid.
>>>>
>>>> I guess there are maybe two possible solutions:
>>>>
>>>> First, change the eml schema - back to string type rather than non-empty
>>>> string type in those elements.
>>>>
>>>> Second, in the eml201to210.xsl style sheet, if it finds the text value of
>>>> a
>>>> leaf node is a space, replace the space by some other text - such as
>>>> "Unavailable".
>>>>
>>>> Do you have any suggestion on this?
>>>>
>>>> Thanks,
>>>>
>>>> Jing
>>>>
>>>> Jing Tao
>>>> National Center for Ecological
>>>> Analysis and Synthesis (NCEAS)
>>>> 735 State St. Suite 204
>>>> Santa Barbara, CA 93101
>>>> _______________________________________________
>>>> Eml-dev mailing list
>>>> Eml-dev at ecoinformatics.org
>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>>>
>>>>
>>>>         
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Matthew B. Jones
>>> Director of Informatics Research and Development
>>> National Center for Ecological Analysis and Synthesis (NCEAS)
>>> UC Santa Barbara
>>> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
>>> http://www.nceas.ucsb.edu/ecoinfo
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>>
>>>
>>>       
>> --
>>
>>
>> ========================
>> Margaret O'Brien
>> Information Management
>> Santa Barbara Coastal LTER Marine Science Institute
>> University of California
>> Santa Barbara, CA  93106-6150
>>
>> 805-893-2071
>> mob at icess.ucsb.edu
>> http://sbc.lternet.edu
>> ========================
>>
>>
>>     
>
>
>
>   

-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================


From tao at nceas.ucsb.edu  Mon Dec 15 10:09:20 2008
From: tao at nceas.ucsb.edu (Jing Tao)
Date: Mon, 15 Dec 2008 10:09:20 -0800 (PST)
Subject: [eml-dev] [morpho-dev] Fwd: Issue on transforming from
 eml-2.0.1 to eml-2.1.0
In-Reply-To: <49469549.7060303@icess.ucsb.edu>
References: <Pine.LNX.4.63.0812121842050.19337@mercury.nceas.ucsb.edu> 
	<fa9a3c5e0812122214n71cd9d20gd4e5ba6a542ddfa9@mail.gmail.com> 
	<fa9a3c5e0812122216v5a487f6cp844bcc4334f6544c@mail.gmail.com> 
	<49468612.8070303@icess.ucsb.edu>
	<fa9a3c5e0812150924k4a23aff2ic982bc59aa42f3fb@mail.gmail.com>
	<49469549.7060303@icess.ucsb.edu>
Message-ID: <Pine.LNX.4.63.0812151000540.19125@mercury.nceas.ucsb.edu>

When morpho describe offline data which data location is not available, 
morpho 1.6.1 put a space as objectname, 1.6.2 release candidate change to 
put "Unavailable" as objectname. Is this okay? In this case, morpho 
doesn't have interface for user to input object name.

Thanks,

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Mon, 15 Dec 2008, Margaret O'Brien wrote:

> Morpho should just ask for an objectName, then, even if the table is not 
> included. One way to use this feature (along with the "save duplicate") is 
> for creating/editing a template.
>
> However, I noticed something else (Morpho 1.6.1):
> you can describe and save a package with an empty table, ie, the template -- 
> no problem.
> but when you to to edit it (or a saved duplicate), clicking the OK button 
> results in:
> "Unable to trim following nodes:
> eml/dataset/(CHOICE)/dataTable(SEQUENCE)/physical/(SEQUENCE)/objectName"
>
> when all it has is the ' '.  So Morpho already cannot handle the empty-string 
> content.
>
> margaret
>
>
> Matt Jones wrote:
>> Hi Margaret,
>> 
>> I think Morpho should be able to fill in the objectName even if they
>> don't upload the file -- the name still exists. I agree that the
>> delimiter fields should allow whitespace characters because whitespace
>> is legitimate as delimiters, but it seems like Morpho should be able
>> to deal with providing the objectName even if it is required and
>> doesn't allow just whitespace.  I must be missing a critical issue
>> here, because this doesn't seem like a problem to me.
>> 
>> Matt
>> 
>> On Mon, Dec 15, 2008 at 7:30 AM, Margaret O'Brien <mob at icess.ucsb.edu> 
>> wrote:
>> 
>>> The problem is a Morpho feature that allows an author to completely 
>>> describe
>>> a dataTable without actually attaching it, and  objectName is a required
>>> child of dataTable. To accommodate this, Morpho has been putting a single
>>> space into the objectName field to meet the "content" requirement of
>>> xs:string. So it seems that there are these choices: come up with an
>>> acceptable string for Morpho to use in these cases and leave the schema
>>> alone, define another type so Morpho can have some other acceptable 
>>> content,
>>> make objectName optional, or remove this feature from Morpho.
>>> 
>>> As far as strings like ' ' , and '\t' --  these have always been 
>>> legitimate
>>> fieldDelimeters. '\t' is allowed by the pattern currently in the
>>> NonEmptyStringType. But since ' ' was not, I reset the types for 
>>> *Delimeters
>>> back to xs:string. We could define a separate pattern for delimeters and
>>> create very specific examples
>>> 
>>> 
>>> Matt Jones wrote:
>>> 
>>>> Discussion merited sometime soon?
>>>> 
>>>> Matt
>>>> 
>>>> 
>>>> ---------- Forwarded message ----------
>>>> From: Matt Jones <jones at nceas.ucsb.edu>
>>>> Date: Fri, Dec 12, 2008 at 9:14 PM
>>>> Subject: Re: [eml-dev] Issue on transforming from eml-2.0.1 to eml-2.1.0
>>>> To: Jing Tao <tao at nceas.ucsb.edu>
>>>> 
>>>> 
>>>> The whole point of changing the schema was to prevent people from
>>>> leaving required elements with empty content.  Changing it to
>>>> 'Unavailable' is equally unappealing.  If we will accept 'Unavailable'
>>>> as a schema choice, we might as well just go ahead and make all
>>>> elements in EML optional so that people don't have to put in some
>>>> garbage text just to get it to validate.  But if we agree that there
>>>> are minimum requirements for things to make sense, then we also
>>>> shouldn't accept '', ' ', '\t', 'N/A', 'Unavailable' or any other
>>>> non-content placeholder.  Unfortunately, we can't stop people from
>>>> doing this through purely technical means, but at least its clear to
>>>> them that its not appropriate with the new content model.
>>>> 
>>>> The downside, of course, is that it prevents automatic and full
>>>> translation from eml 2.0.1 to eml 2.1, but we knew they were not
>>>> backwards compatible, so this won't be the only case.
>>>> 
>>>> Matt
>>>> 
>>>> On Fri, Dec 12, 2008 at 8:26 PM, Jing Tao <tao at nceas.ucsb.edu> wrote:
>>>>
>>>> 
>>>>> Hi, Margaret:
>>>>> 
>>>>> I am writting a java program to transform eml201(eml200) documents to
>>>>> eml210
>>>>> in a Metacat by the style sheet from eml module. It works now in my test
>>>>> server. But I found a issue here:
>>>>> 
>>>>> In some eml201 documents, some elements, e.g. objectName, have a space 
>>>>> as
>>>>> text value. It is valid in eml201. After transforming to eml210 
>>>>> document,
>>>>> the space value will be kept there. However, current eml-210 schema
>>>>> doesn't
>>>>> allow the value to be a space. This results that the generated eml210
>>>>> document is invalid.
>>>>> 
>>>>> I guess there are maybe two possible solutions:
>>>>> 
>>>>> First, change the eml schema - back to string type rather than non-empty
>>>>> string type in those elements.
>>>>> 
>>>>> Second, in the eml201to210.xsl style sheet, if it finds the text value 
>>>>> of
>>>>> a
>>>>> leaf node is a space, replace the space by some other text - such as
>>>>> "Unavailable".
>>>>> 
>>>>> Do you have any suggestion on this?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jing
>>>>> 
>>>>> Jing Tao
>>>>> National Center for Ecological
>>>>> Analysis and Synthesis (NCEAS)
>>>>> 735 State St. Suite 204
>>>>> Santa Barbara, CA 93101
>>>>> _______________________________________________
>>>>> Eml-dev mailing list
>>>>> Eml-dev at ecoinformatics.org
>>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>>>> 
>>>>>
>>>>> 
>>>> 
>>>> --
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> Matthew B. Jones
>>>> Director of Informatics Research and Development
>>>> National Center for Ecological Analysis and Synthesis (NCEAS)
>>>> UC Santa Barbara
>>>> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
>>>> http://www.nceas.ucsb.edu/ecoinfo
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 
>>>> 
>>>> 
>>>>
>>>> 
>>> --
>>> 
>>> 
>>> ========================
>>> Margaret O'Brien
>>> Information Management
>>> Santa Barbara Coastal LTER Marine Science Institute
>>> University of California
>>> Santa Barbara, CA  93106-6150
>>> 
>>> 805-893-2071
>>> mob at icess.ucsb.edu
>>> http://sbc.lternet.edu
>>> ========================
>>> 
>>>
>>> 
>> 
>> 
>>
>> 
>
> -- 
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA  93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
> _______________________________________________
> Morpho-dev mailing list
> Morpho-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/morpho-dev
>
>

From mob at icess.ucsb.edu  Wed Dec 17 17:15:54 2008
From: mob at icess.ucsb.edu (Margaret O'Brien)
Date: Wed, 17 Dec 2008 17:15:54 -0800
Subject: [eml-dev] EML 2.1.0 Release Candidate 4
Message-ID: <4949A44A.8040603@icess.ucsb.edu>

Hi all -
A release candidate for EML 2.1.0 is now tagged and available as 
RELEASE_EML_2_1_0_RC_4.
Since the summer, several other features were added. Particularly, many 
elements were retyped to constrain their content, and overall, this will 
result in higher quality instance docs.

Special notes, and requests for review
1. Documentation:
a. First, see the new document "eml-210info.html". It has 2 sections: 
the first is a synopsis of changes and new features in this release, and 
the second section describes the transformation stylesheet, with examples.
b. All the areas of the schema which changed or were retyped also 
required updates to documentation, and to the pngs. Please review these 
areas in the normative docs: geographicCoverage, access, physical, 
attribute (boundsGroup). The html documentation is not under cvs 
control, but is easy to build:
ant clean init docbook docbookhtml faqhtml tablehtml docs eml210infohtml

But to save you running 'ant' and all those targets, I've made a copy 
available at
http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/eml-210info.html
and
http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/index.html
these will remain till they're finalized, and I'll recreate them from 
the head as needed.


2. Transformation stylesheet for 2.0.1 -> 2.1.0: please test the 
stylesheet (style/eml201to210.xsl). It has been run with 3 processors: 
Java (Xalan), the linux command line utility, xsltproc (C++), and MSXML 
(thanks, Wade). However, with the variety of authoring styles in use, it 
would be helpful to see more documents tested.
Jing and I identified only 2 situations where an instance document might 
cause a problem when transformed. Both had to do with moving access 
trees out of additionalMetadata and into distribution nodes. One will 
cause the transformation process to stop, and it prints an error 
message. In the other case, transformation can continue, but a warning 
message is returned.

All the junit tests passed, and additional test documents have been 
added.  The instructions for access using anonymous cvs checkout are 
here, and notes from the README are below.
http://www.kepler-project.org/Wiki.jsp?page=DevelopmentForKepler
 
Cheers -
Margaret


HIGHLIGHTS IN THIS RELEASE
--------------------------
This release addresses bugs which caused the schema to be invalid with
respect to the W3C specifications using modern validators
(e.g., http://www.w3.org/2001/03/webdata/xsv). Although the changes were 
minor,
one was incompatible with 2.0 releases, which necessitated the version
number "2.1". In the 2.0 series, the content model for additionalMetadata
included an element <describes> whose cardinality was 0..many, alongside
<xs:any>. This construct is non-deterministic, and so a child element
was added to the additionalMetadata section to contain the <xs:any> content.
Additionally, several elements of txt:TypeText required additional
definition so that mixed content could be accommodated. These errors
were not apparent with validation software available in 2004-2005, but
were brought to light more recently. Several small changes were made to
the enumeration list and unitTypes for standard units and stmml descriptions
of customUnits. Two elements in the literature schema were allowed to be
optional so that articles-in-press could be described.  The named type for
element gRing was changed to GRingType.

EML makes use of the STMML schema (stmml.xsd) for describing custom units
and describing its included list of standardUnits (unitList). The STMML
schema was also found to be non-deterministic, and the most reasonable fix
for this bug was not compatible with earlier versions. This error
was NOT related to elements used by EML (unitList or unitType). However,
given that authors of EML instance documents may have made use of other
parts of stmml.xsd, it was decided to the advance the namespace used for
stmml-related files to "stmml-1.1", in keeping with the pattern of version
naming in EML. The stmml authors have been contacted.

KNOWN ISSUES (see also http://bugzilla.ecoinformatics.org/)
-----------------------------------------------------------
Some areas of EML remain problematic for particular data types, and these
are being addressed by sub-groups of the EML development group. These
will be addressed in a backwards-incompatible release in the future. Areas
of future development include:
1. use of external (or multiple) dictionaries
2. handling of ongoing data, (e.g.,use of temporal coverage elements)
3. spatial datasets and map projections

BUGS FIXED AND NEW FEATURES IN CURRENT RELEASE
(see also http://bugzilla.ecoinformatics.org/)
--------------------------------------------------------------------------
2.1.0   (numbers refer to the corresponding Bugzilla bug)
Schema changes:
1132: eml.xsd, physical.xsd: fix access rule ambiguities
2054: eml.xsd: added the <metadata> tag to additionalMetadata
1154: resource.xsd: required element offline has no required children
3480: resource.xsd, physical.xsd: nearly duplicate complexTypes, 
DistributionType and PhysicalDistributionType
3165: resource.xsd: provide a place for a url description
3227: coverage.xsd: gRing was declared as GRingPointType, is now GRingType
1019: coverage.xsd: altitudeUnits should use eml-unitDictionary
3500: coverage.xsd: restrict boundingCoordinates to realistic lat/lon ranges
1152: attribute.xsd: dateTime elements are named inconsistently; 
standarized on dateTime
2272: attribute.xsd: base types in BoundsGroup changed to xs:float
3051: attribute.xsd: missing units were added to enumeration list to 
match eml-unitDitionary
2568: attribute.xsd, entity.xsd: inconsistent naming of methods 
elements, standardized to <methods>
2703: text.xsd: refined element declarations in txt:TextType for para, 
section; added ulink, citetitle
3163: literature.xsd: cardinality of volume and pageRange is now 0..1
3164: literature.xsd: literature needs a contact tree
3445: stmml.xsd: non-deterministic
2083: stmml.xsd: dimension 'current' was wrongly entered as 'charge'

Parser :
3232: EML parser should use full-schema-checking

Stylesheets :
3508: create a stylesheet for EML2.0.x to EML 2.1.0
3590: eml-documentation stylesheet problem with derived content.
2048: param attributeindex defined twice in eml-settings.xsl
2085: Access ontrol rules adapted for 2.0.1 and 2.1 (currently not shown)
2147: EML Stylesheet problem with web address URL's
2226: EML2 style sheet double the number of complex delimited f...






-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at msi.ucsb.edu
http://sbc.lternet.edu
========================


-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================


From tao at nceas.ucsb.edu  Thu Dec 18 09:42:50 2008
From: tao at nceas.ucsb.edu (Jing Tao)
Date: Thu, 18 Dec 2008 09:42:50 -0800 (PST)
Subject: [eml-dev] EML 2.1.0 Release Candidate 4
In-Reply-To: <4949A44A.8040603@icess.ucsb.edu>
References: <4949A44A.8040603@icess.ucsb.edu>
Message-ID: <Pine.LNX.4.63.0812180938080.32263@mercury.nceas.ucsb.edu>

I am also trying to transform a entire metacat documents (a backup copy 
from knb production server) from eml-2.0.0 or eml-2.0.1 to eml-2.1.0. The 
processing is going. I will let you know when it is done.

Thanks,

Jing


Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Wed, 17 Dec 2008, Margaret O'Brien wrote:

> Hi all -
> A release candidate for EML 2.1.0 is now tagged and available as 
> RELEASE_EML_2_1_0_RC_4.
> Since the summer, several other features were added. Particularly, many 
> elements were retyped to constrain their content, and overall, this will 
> result in higher quality instance docs.
>
> Special notes, and requests for review
> 1. Documentation:
> a. First, see the new document "eml-210info.html". It has 2 sections: the 
> first is a synopsis of changes and new features in this release, and the 
> second section describes the transformation stylesheet, with examples.
> b. All the areas of the schema which changed or were retyped also required 
> updates to documentation, and to the pngs. Please review these areas in the 
> normative docs: geographicCoverage, access, physical, attribute 
> (boundsGroup). The html documentation is not under cvs control, but is easy 
> to build:
> ant clean init docbook docbookhtml faqhtml tablehtml docs eml210infohtml
>
> But to save you running 'ant' and all those targets, I've made a copy 
> available at
> http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/eml-210info.html
> and
> http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/index.html
> these will remain till they're finalized, and I'll recreate them from the 
> head as needed.
>
>
> 2. Transformation stylesheet for 2.0.1 -> 2.1.0: please test the stylesheet 
> (style/eml201to210.xsl). It has been run with 3 processors: Java (Xalan), the 
> linux command line utility, xsltproc (C++), and MSXML (thanks, Wade). 
> However, with the variety of authoring styles in use, it would be helpful to 
> see more documents tested.
> Jing and I identified only 2 situations where an instance document might 
> cause a problem when transformed. Both had to do with moving access trees out 
> of additionalMetadata and into distribution nodes. One will cause the 
> transformation process to stop, and it prints an error message. In the other 
> case, transformation can continue, but a warning message is returned.
>
> All the junit tests passed, and additional test documents have been added. 
> The instructions for access using anonymous cvs checkout are here, and notes 
> from the README are below.
> http://www.kepler-project.org/Wiki.jsp?page=DevelopmentForKepler
>
> Cheers -
> Margaret
>
>
> HIGHLIGHTS IN THIS RELEASE
> --------------------------
> This release addresses bugs which caused the schema to be invalid with
> respect to the W3C specifications using modern validators
> (e.g., http://www.w3.org/2001/03/webdata/xsv). Although the changes were 
> minor,
> one was incompatible with 2.0 releases, which necessitated the version
> number "2.1". In the 2.0 series, the content model for additionalMetadata
> included an element <describes> whose cardinality was 0..many, alongside
> <xs:any>. This construct is non-deterministic, and so a child element
> was added to the additionalMetadata section to contain the <xs:any> content.
> Additionally, several elements of txt:TypeText required additional
> definition so that mixed content could be accommodated. These errors
> were not apparent with validation software available in 2004-2005, but
> were brought to light more recently. Several small changes were made to
> the enumeration list and unitTypes for standard units and stmml descriptions
> of customUnits. Two elements in the literature schema were allowed to be
> optional so that articles-in-press could be described.  The named type for
> element gRing was changed to GRingType.
>
> EML makes use of the STMML schema (stmml.xsd) for describing custom units
> and describing its included list of standardUnits (unitList). The STMML
> schema was also found to be non-deterministic, and the most reasonable fix
> for this bug was not compatible with earlier versions. This error
> was NOT related to elements used by EML (unitList or unitType). However,
> given that authors of EML instance documents may have made use of other
> parts of stmml.xsd, it was decided to the advance the namespace used for
> stmml-related files to "stmml-1.1", in keeping with the pattern of version
> naming in EML. The stmml authors have been contacted.
>
> KNOWN ISSUES (see also http://bugzilla.ecoinformatics.org/)
> -----------------------------------------------------------
> Some areas of EML remain problematic for particular data types, and these
> are being addressed by sub-groups of the EML development group. These
> will be addressed in a backwards-incompatible release in the future. Areas
> of future development include:
> 1. use of external (or multiple) dictionaries
> 2. handling of ongoing data, (e.g.,use of temporal coverage elements)
> 3. spatial datasets and map projections
>
> BUGS FIXED AND NEW FEATURES IN CURRENT RELEASE
> (see also http://bugzilla.ecoinformatics.org/)
> --------------------------------------------------------------------------
> 2.1.0   (numbers refer to the corresponding Bugzilla bug)
> Schema changes:
> 1132: eml.xsd, physical.xsd: fix access rule ambiguities
> 2054: eml.xsd: added the <metadata> tag to additionalMetadata
> 1154: resource.xsd: required element offline has no required children
> 3480: resource.xsd, physical.xsd: nearly duplicate complexTypes, 
> DistributionType and PhysicalDistributionType
> 3165: resource.xsd: provide a place for a url description
> 3227: coverage.xsd: gRing was declared as GRingPointType, is now GRingType
> 1019: coverage.xsd: altitudeUnits should use eml-unitDictionary
> 3500: coverage.xsd: restrict boundingCoordinates to realistic lat/lon ranges
> 1152: attribute.xsd: dateTime elements are named inconsistently; standarized 
> on dateTime
> 2272: attribute.xsd: base types in BoundsGroup changed to xs:float
> 3051: attribute.xsd: missing units were added to enumeration list to match 
> eml-unitDitionary
> 2568: attribute.xsd, entity.xsd: inconsistent naming of methods elements, 
> standardized to <methods>
> 2703: text.xsd: refined element declarations in txt:TextType for para, 
> section; added ulink, citetitle
> 3163: literature.xsd: cardinality of volume and pageRange is now 0..1
> 3164: literature.xsd: literature needs a contact tree
> 3445: stmml.xsd: non-deterministic
> 2083: stmml.xsd: dimension 'current' was wrongly entered as 'charge'
>
> Parser :
> 3232: EML parser should use full-schema-checking
>
> Stylesheets :
> 3508: create a stylesheet for EML2.0.x to EML 2.1.0
> 3590: eml-documentation stylesheet problem with derived content.
> 2048: param attributeindex defined twice in eml-settings.xsl
> 2085: Access ontrol rules adapted for 2.0.1 and 2.1 (currently not shown)
> 2147: EML Stylesheet problem with web address URL's
> 2226: EML2 style sheet double the number of complex delimited f...
>
>
>
>
>
>
> -- 
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA  93106-6150
>
> 805-893-2071
> mob at msi.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
>
> -- 
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA  93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
>

From kramsey at jornada.nmsu.edu  Fri Dec 19 09:33:53 2008
From: kramsey at jornada.nmsu.edu (Ken Ramsey)
Date: Fri, 19 Dec 2008 10:33:53 -0700
Subject: [eml-dev] EML 2.1.0 Release Candidate 4
In-Reply-To: <4949A44A.8040603@icess.ucsb.edu>
References: <4949A44A.8040603@icess.ucsb.edu>
Message-ID: <494B7890.308E.00AA.0@jornada.nmsu.edu>

Hi Margaret, 

Great job on the HTML document describing the changes to EML. Is there any way to download or access the entire release candidate specification?

Thanks for taking the lead on this update of EML. You and Jing have been doing a remarkable job. 

Ken 

-------------------------------
Ken Ramsey
Information Manager
Jornada Basin LTER Project
New Mexico State University
2995 Knox Street, suite 200
Box 30003, MSC 3JER
Las Cruces, NM 88003
(575)646-7918 (office)
(575)646-5665 (fax)
kramsey at jornada.nmsu.edu
-------------------------------


>>> Margaret O'Brien <mob at icess.ucsb.edu> 12/17/2008 6:15 PM >>>
Hi all -
A release candidate for EML 2.1.0 is now tagged and available as 
RELEASE_EML_2_1_0_RC_4.
Since the summer, several other features were added. Particularly, many 
elements were retyped to constrain their content, and overall, this will 
result in higher quality instance docs.

Special notes, and requests for review
1. Documentation:
a. First, see the new document "eml-210info.html". It has 2 sections: 
the first is a synopsis of changes and new features in this release, and 
the second section describes the transformation stylesheet, with examples.
b. All the areas of the schema which changed or were retyped also 
required updates to documentation, and to the pngs. Please review these 
areas in the normative docs: geographicCoverage, access, physical, 
attribute (boundsGroup). The html documentation is not under cvs 
control, but is easy to build:
ant clean init docbook docbookhtml faqhtml tablehtml docs eml210infohtml

But to save you running 'ant' and all those targets, I've made a copy 
available at
http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/eml-210info.html 
and
http://sbc.lternet.edu/~mob/eml/docs/eml-2.1.0/index.html 
these will remain till they're finalized, and I'll recreate them from 
the head as needed.


2. Transformation stylesheet for 2.0.1 -> 2.1.0: please test the 
stylesheet (style/eml201to210.xsl). It has been run with 3 processors: 
Java (Xalan), the linux command line utility, xsltproc (C++), and MSXML 
(thanks, Wade). However, with the variety of authoring styles in use, it 
would be helpful to see more documents tested.
Jing and I identified only 2 situations where an instance document might 
cause a problem when transformed. Both had to do with moving access 
trees out of additionalMetadata and into distribution nodes. One will 
cause the transformation process to stop, and it prints an error 
message. In the other case, transformation can continue, but a warning 
message is returned.

All the junit tests passed, and additional test documents have been 
added.  The instructions for access using anonymous cvs checkout are 
here, and notes from the README are below.
http://www.kepler-project.org/Wiki.jsp?page=DevelopmentForKepler 
 
Cheers -
Margaret


HIGHLIGHTS IN THIS RELEASE
--------------------------
This release addresses bugs which caused the schema to be invalid with
respect to the W3C specifications using modern validators
(e.g., http://www.w3.org/2001/03/webdata/xsv). Although the changes were 
minor,
one was incompatible with 2.0 releases, which necessitated the version
number "2.1". In the 2.0 series, the content model for additionalMetadata
included an element <describes> whose cardinality was 0..many, alongside
<xs:any>. This construct is non-deterministic, and so a child element
was added to the additionalMetadata section to contain the <xs:any> content.
Additionally, several elements of txt:TypeText required additional
definition so that mixed content could be accommodated. These errors
were not apparent with validation software available in 2004-2005, but
were brought to light more recently. Several small changes were made to
the enumeration list and unitTypes for standard units and stmml descriptions
of customUnits. Two elements in the literature schema were allowed to be
optional so that articles-in-press could be described.  The named type for
element gRing was changed to GRingType.

EML makes use of the STMML schema (stmml.xsd) for describing custom units
and describing its included list of standardUnits (unitList). The STMML
schema was also found to be non-deterministic, and the most reasonable fix
for this bug was not compatible with earlier versions. This error
was NOT related to elements used by EML (unitList or unitType). However,
given that authors of EML instance documents may have made use of other
parts of stmml.xsd, it was decided to the advance the namespace used for
stmml-related files to "stmml-1.1", in keeping with the pattern of version
naming in EML. The stmml authors have been contacted.

KNOWN ISSUES (see also http://bugzilla.ecoinformatics.org/)
-----------------------------------------------------------
Some areas of EML remain problematic for particular data types, and these
are being addressed by sub-groups of the EML development group. These
will be addressed in a backwards-incompatible release in the future. Areas
of future development include:
1. use of external (or multiple) dictionaries
2. handling of ongoing data, (e.g.,use of temporal coverage elements)
3. spatial datasets and map projections

BUGS FIXED AND NEW FEATURES IN CURRENT RELEASE
(see also http://bugzilla.ecoinformatics.org/)
--------------------------------------------------------------------------
2.1.0   (numbers refer to the corresponding Bugzilla bug)
Schema changes:
1132: eml.xsd, physical.xsd: fix access rule ambiguities
2054: eml.xsd: added the <metadata> tag to additionalMetadata
1154: resource.xsd: required element offline has no required children
3480: resource.xsd, physical.xsd: nearly duplicate complexTypes, 
DistributionType and PhysicalDistributionType
3165: resource.xsd: provide a place for a url description
3227: coverage.xsd: gRing was declared as GRingPointType, is now GRingType
1019: coverage.xsd: altitudeUnits should use eml-unitDictionary
3500: coverage.xsd: restrict boundingCoordinates to realistic lat/lon ranges
1152: attribute.xsd: dateTime elements are named inconsistently; 
standarized on dateTime
2272: attribute.xsd: base types in BoundsGroup changed to xs:float
3051: attribute.xsd: missing units were added to enumeration list to 
match eml-unitDitionary
2568: attribute.xsd, entity.xsd: inconsistent naming of methods 
elements, standardized to <methods>
2703: text.xsd: refined element declarations in txt:TextType for para, 
section; added ulink, citetitle
3163: literature.xsd: cardinality of volume and pageRange is now 0..1
3164: literature.xsd: literature needs a contact tree
3445: stmml.xsd: non-deterministic
2083: stmml.xsd: dimension 'current' was wrongly entered as 'charge'

Parser :
3232: EML parser should use full-schema-checking

Stylesheets :
3508: create a stylesheet for EML2.0.x to EML 2.1.0
3590: eml-documentation stylesheet problem with derived content.
2048: param attributeindex defined twice in eml-settings.xsl
2085: Access ontrol rules adapted for 2.0.1 and 2.1 (currently not shown)
2147: EML Stylesheet problem with web address URL's
2226: EML2 style sheet double the number of complex delimited f...






-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at msi.ucsb.edu 
http://sbc.lternet.edu 
========================


-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu 
http://sbc.lternet.edu 
========================

_______________________________________________
Eml-dev mailing list
Eml-dev at ecoinformatics.org 
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev

From mob at icess.ucsb.edu  Fri Dec 19 11:04:12 2008
From: mob at icess.ucsb.edu (Margaret O'Brien)
Date: Fri, 19 Dec 2008 11:04:12 -0800
Subject: [eml-dev] EML_2.1.0 RC4, anonymous CVS access
Message-ID: <494BF02C.1020003@icess.ucsb.edu>

Hi all -
Several people have pointed out that the instructions for anonymous 
checkout now point to SVN, not CVS. Sorry - I did not check on the 
instructions first. If you need to use anonymous access for EML, here's 
how:

cvs -d anonymous at ecoinformatics.org:/cvs checkout -r 
RELEASE_EML_2_1_0_RC_4 eml
password is "guestaccess"

best,
Margaret



-------- Original Message --------
Subject: 	anonymous access to ecoinformatics CVS
Date: 	Fri, 19 Dec 2008 08:40:44 -0800
From: 	Margaret O'Brien <mob at icess.ucsb.edu>
To: 	David Blankman <dblankman1 at gmail.com>



Hi David -
I found the instructions. It looks like the Kepler project has been 
moved to svn, and the access page updated, and I didnt check on it. 
Sorry for the delay.
Here are the instructions for anonymous cvs access:
cvs -d anonymous at ecoinformatics.org:/cvs checkout -r 
RELEASE_EML_2_1_0_RC_4 eml
password is "guestaccess"

let me know if you have any problems
Margaret


-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================




-- 


========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER 
Marine Science Institute
University of California
Santa Barbara, CA  93106-6150

805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================


