Do you have any questions related to DataCite's metadata or metadata schema? Please details.

[Joan Starr]

[Stefan Kramer - American University]

Hi,

Is there (a plan to create) a listing of tools that work with the DataCite metadata schema, similar to the one for the Data Documentation Initiative?  

Thanks,

--

Stefan Kramer
Research Data Librarian
American University
4400 Massachusetts Ave NW
Washington, DC 20016, USA
SKr...@american.edu

[Joan Starr]

Hi Stefan

We do not have a plan at the present time, but are certainly open to establishing one. Are you a participant in the DDI community? Would you like to share how that community maintains their list? The challenge is, of course, that we only know about those entities that inform us they are using our metadata schema.

Best,

Joan Starr

Chair, DataCite Metadata Working Group

[Stefan Jakobsson]

Hi,

I have a question regarding the geoLocationBox element. The specification says that the first latitude-longitude pair specifies the lower corner, and the second specifies the upper corner. It does not say whether it's the south-west and north-east corner, or the north-west and south-east corner that should be specified. Can someone clarify this?

An alternative way to describe a bounding box would be to specify the west longitude, east longitude, north latitude and south latitude as separate elements under geoLocationBox. That way the ordering is unimportant. DDI, for example, uses this method, see http://www.ddialliance.org/Specification/DDI-Lifecycle/3.1/XMLSchema/FieldLevelDocumentation/reusable_xsd/complexTypes/BoundingBoxType.html.

Thanks,

Stefan Jakobsson

Systems Developer

Swedish National Data Service

On Monday, August 19, 2013 8:44:37 PM UTC+2, Joan Starr wrote:

[frauke.ziedorn]

Hello Stefan,

Thank you for your comment. I clearified the description of GeoLocation Box in our documentation and also corrected the example. It now reads:

A box contains two white space separated latitude-longitude pairs, with each pair separated by whitespace. The first pair is the lower corner (normally south west), the second is the upper corner (normally north east).

Example:<geoLocationBox>41.090 -71.032  42.893 -68.211 </geoLocationBox>

I hope this clears things up.
It may take some time before the changes are online as our admin is currently out of office.

Best regards
Frauke Ziedorn

---

[Frauke Ziedorn]

The updated documentation is now online avaiable at http://schema.datacite.org/meta/kernel-3/index.html

[Stefan Kramer - American University]

Hi Joan,

I was an active participant in the DDI community through 2011 - the maintenance of the DDI Tools list is undertaken by the Tools Catalog Working Group (http://www.ddialliance.org/alliance/working-groups#tcg - there's a listing of annual reports that describes the progress of the group). The challenge is unquestionable, I think it's really a matter of the list maintainers keeping an outlook on appropriate forums for new tool announcements, as well as tool developers being cognizant of the list and sending updates to its maintainers.  That's still no guarantee for completeness, of course.

Stefan

[sarah]

In order to link our DataCite metadata and DOIs with a search engine, we are being asked to include a full citation, as a text string, for the publication associated with each resource (DOI) within our DataCite metadata. We will have one associated publication for each DOI. An example of a full citation string is

"Holland RA, Wikelski M, Kuemmeth F, Bosque C (2012) The secret life of oilbirds: new insights into the movement ecology of a unique avian frugivore. PLoS ONE 4(12): e8264. doi:10.1371/journal.pone.0008264"

The best solution I see is to use "relatedIdentifier", with relationType="IsDocumentedBy". However I don't see a suitable option for relatedIdentifierType.

Do you have any suggestion for how we might include this information in our metadata?

Thanks in advance for any advice.

Sarah

On Monday, August 19, 2013 2:44:37 PM UTC-4, Joan Starr wrote:

[lynne.mcavoy]

Hello Sarah,

Thank you for providing this excellent use case. In order to meet your current needs, we would like to suggest using the free text option provided within alternateIdentifier:

alternateIdentifier type=”citation”    For an example of how this appears in DataCite, please see http://data.datacite.org/10.5061/DRYAD.3801D

This question will be investigated further by the Metadata Working Group in its deliberations on features to add to our next version.

All the best,
Lynne McAvoy

DataCite WG-1 Metadata

[sarah]

Dear Lynne,

Thank you for the suggestion, this will work for us.

Best regards,

Sarah

[lynne.mcavoy]

Hello Sarah,

 

Please do not proceed with the approach I suggested on Wednesday. It seems that I was mistaken in my understanding of what you were trying to accomplish. I thought you wanted an unparsed citation for the same title you had assigned to the dataset. This could have been accomplished by the method I proposed.

 

However, since you were looking for a way to record the citation of the associated journal article, this will not work.

 

AlternateIdentifier is not an appropriate place for the citation of a related article. RelatedIdentifier is also not a good place because the citation is not an identifier.

In our current schema the only appropriate place would be description with descriptionType="SeriesInformation", not an intuitive place to store a citation to a related item.

 

As this is not the first time our team has been asked for a place to house additional identifying information for related resources, we will be looking into this more closely in the near future. Until now, the priority work on the schema has been focused on describing the resource at hand, with an identifier to locate related materials.

 

Sorry for any inconvenience this may have caused,

 

Lynne McAvoy

DataCite WG-1 Metadata

 

[lynne.mcavoy]

Hi Sarah,

At our team discussion this morning, we agreed that as an interim measure you should use the following approach which is an acceptable formatting within the current schema v 3.0:

             <description descriptionType="Other">

Thank you for your patience in this matter,

[wieb...@googlemail.com]

Hi,

I have a question regarding the dateType schema. For example: <date dateType="created">YYYY-MM-DD</date>
What if I don't know the exact date of creation, but only the year? How would I write that down correctly? For example a dataset was created last year (2013), what would I write?
<date dateType="created">2013-00-00</date>? Or would I suggest the first of january?

Thanks,
Wiebke

[Joan Starr]

Hi Wiebke,

Thank you for your question.

In the Schema documentation for the Date property (http://schema.datacite.org/meta/kernel-3/doc/DataCite-MetadataKernel_v3.0.pdf, p. 12), we say about format that you can use "YYYY,YYYY-MM-DD, YYYY-MM-DDThh:mm:ssTZD or any other format or level of granularity described in W3CDTF." This means you can supply the year only. Please let us know if this does not address your question.

Best,

Joan Starr

Chair, DataCite Metadata Working Group

[rja...@rci.rutgers.edu]

Joan,
I posted a question on the EZID list and Greg responded that my question relates to metadata.  We have a Roman Coins project underway in which we need to provide negative dates (e.g. -233 for 233 B.C.E) in the PublicationYear field for several reasons - sorting dates, citation, etc.  My understanding is that negative dates are permitted in the ISO 8601 standard.  It appears that EZID limits the date field to four digits (i.e. a minus sign is not accepted).  If this is correct, can it be changed so that we can input negative numbers?  Alternatively, we could possibly put the coin date locally in another field and put the current date of deposit in RUcore in the PublicationYear field.  This approach is less acceptable here locally.  Thanks for your help.

Ron Jantz
Digital Library Architect
Rutgers University Libraries

[Joan Starr]

Hi Ron,

Thanks for bringing the issue of BCE dates to the DataCite Metadata Group's attention. We will discuss this. Whether you want to put this in the Publication Year or in the Date field, I believe there will still be challenges, because from what I understand, the ISO standard is not actually all that helpful. Here is the relevant section: ISO. 2004-12-01. "3.5 Expansion ... By mutual agreement of the partners in information interchange, it is permitted to expand the component identifying the calendar year, which is otherwise limited to four digits. This enables reference to dates and times in calendar years outside the range supported by complete representations, i.e. before the start of the year [0000] or after the end of the year [9999]." This suggests that there exist two identified parties to the information exchange, rather than a situation of open data exchange.

Do you have different information from this? If so, please share it. Thank you,

Joan Starr

Chair, DataCite Metadata Working Group

[wieb...@googlemail.com]

Hi Joan,

thank your for your quick reply, that does answer my question and makes things easy for us.

Wish you a nice day,
Wiebke

[Jens Rasmussen]

Hi

 

I hope this is the right place to post these queries.

 

We're just starting to mint, and I was testing out XML generated from our internal catalogue on the DataCite test facility.

I came across a couple of errors during xml upload that confused me a little:

 

1. Validation fails when I have schemeURI on the subject fields. Here's a specific example of what failed:

 

    <subject subjectScheme="P031-SeaDataNet Agreed Parameter Groups" schemeURI="http://vocab.ndg.nerc.ac.uk/term/P031/20/D025">Water column temperature and salinity</subject>

 

- If i strip out the schemeURI, the record works.

But in the documentation (http://schema.datacite.org/meta/kernel-3/doc/DataCite-MetadataKernel_v3.0.pdf) schemeURI is litested as a valid for for subject (6.2 in Table 4)

 

2. Validation fails for description type Methods. Here's an example of the whole descriptions section of the xml:

 

(i shortened the Abstract as it was quite long and made it harder to view - but that section is ok on upload)

 

<descriptions>
    <description descriptionType="Abstract">DAFS charter - Fish survey. .....</description>
    <description descriptionType="Methods">Samples collected during cruise:
Water bottles for nutrient analysis in a continuous flow analyser
Hull Mounted ADCP for current profiling
MIKT net deployments to collect herring
LOCHNESS and ARIES samples fro zooplankton and herring larvae</description>
  </descriptions>

 

 

I can't see any immediate issues like malformed xml, but if i cut out the two sections mentioed above, the rest of the xml validates fine.

 

Kind reagrds,

Jens

[Rachael Kotarski]

Hi Jens,

 

Thanks for your questions, Frauke is looking into this for you.

 

Just for any other British Library DataCite clients who might read this, you can send similar questions to us at the British Library with the usual address in the first instance. We can then help you check it's not a problem with your XML. Others should send questions to the DataCite member they're working with. If it does turn out to be a problem with metadata schema documentation not matching MDS functionality, we can then request the documentation changes for you.

 

Thanks, Rachael K.

[Jens Rasmussen]

Thanks Rachael

 

Sorry perhaps I should have emailed it through instead. Happy to provide a full xml file example if needed.

 

Cheers,

Jens

[julian...@g.harvard.edu]

Hi Joan,

I have another DataCite metadata question. I'm investigating an issue a few users of Dataverse have when trying to publish datasets with DOIs assigned to them through DataCite (as opposed to through EZID). The gist of the problem and our hunch about what's happening is in the pasted comments below (from two comments in this thread in Dataverse's Google Groups forum):

A user using a Dataverse repository wrote:

I just got the same DataCite related error message again when trying to publish another dataset. After a lot of trial and failure I found out that the metadata field "Contact Name" has to be filled in in order for the dataset to be published. I don't know the reason for this - I couldn't find any information about this field to be obligatory in DataCite Metadata Scheme V 4.0. By default, the contact email address is required by Dataverse, but not the contact name. We have now added this field as obligatory in our Dataverses. Maybe the field should be required by Dataverse.

One of Dataverse's developers wrote that:

as far as I can tell, this issue affects people [Dataverse installations] who use DataCite for DOI registration rather than EZID.

He thinks that because another Dataverse repository, Harvard Dataverse, uses EZID, and it doesn't have this problem (it's able to publish datasets with and without contactName), the issue might lie with DataCite DOI registration.

Could you help me figure out if this is the case? Is it possible that EZID registers DOIs when that registration service gets dataset metadata that doesn't have a contactName, but DataCite requires a contactName?

Please let me know if anything is unclear, and thanks again for the help,

Julian Gautier

Product Research Specialist, Dataverse Project

On Monday, August 19, 2013 at 2:44:37 PM UTC-4, Joan Starr wrote:

[Joan Starr]

Hi Julian,
EZID doesn't do anything special with regard to contact names when it registers DOIs, so I think you have to ask your Dataverse contacts to look into this more deeply, or to--as you suggest--make contact name required.
Good luck,
Joan Starr

[julian...@g.harvard.edu]

Thank you, Joan!

Julian

[julian...@g.harvard.edu]

Hi,

Dataverse allows depositors to enter html in some of its metadata fields. We're wondering why Dataverse should keep that html in the XML that's sent to DataCite (escaping <, and > and other characters that aren't allowed as values in well-formed XML, instead of stripping all html from the XML). Are there strong opinions for or against doing this? Happy to clarify if needed.

Thanks!

Julian

Product Research Specialist, Dataverse

[Martin Fenner]

Julian,

this is info on this in the schema documentation, you find the latest version at http://schema.datacite.org/meta/kernel-4.0/. For the description field (which is probably most relevant here), we say "Use "<br>" to indicate a line break for improved rendering of multiple paragraphs, but otherwise no html markup.".

When DataCite processes the DataCite XML, e.g. for display in DataCite Search, we are a little bit more flexible and allow the following tags: "strong em b i code pre sub sup br".

Best,

Martin

—

Martin Fenner

DataCite Technical Director

http://orcid.org/0000-0003-1419-2405

--
You received this message because you are subscribed to the Google Groups "DataCite Metadata" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datacite-metad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[julian...@g.harvard.edu]

Hi Martin,

Thank you for the quick reply and info.

Julian

[Matthias Töwe]

Dear colleagues

Currently, DataCite can only be referred to in METS with the MDTYPE Attribute "OTHER". Are there plans to register the DataCite Metadata Schema officially as an external METS-Schema (http://www.loc.gov/standards/mets/mets-extenders.html)?
I understand from my colleagues who asked this that they do not have a technical issue with it, but they would prefer having the explicit reference in the METS. (In Addition, this could increase visibility and usage of the Schema, I guess.)

Thank you and best regards
Matthias Töwe

ETH Library

ETH Zurich

Am Montag, 19. August 2013 20:44:37 UTC+2 schrieb Joan Starr:

[Barton, Amy J]

Hello Matthias,

 

Thank you for the question. The Metadata Working Group is finalizing the metadata documentation and schema for version 4.1. Once released we turn out attention to version 4.2, and am now collecting suggestions such as this to consider implementing in the next version. Metadata extensibility is one of the topics we will discuss.

 

All the best!

Amy

Co-Chair

DataCite Metadata Working Group

Amy J. Barton, MLS

Assistant Professor of Library Science, Metadata Specialist

Purdue University Libraries, Research Data

(765) 494-6333​

hat...@purdue.edu

---

From: datacite...@googlegroups.com <datacite...@googlegroups.com> on behalf of Matthias Töwe <matthia...@library.ethz.ch>
Sent: Tuesday, September 19, 2017 5:06 AM
To: DataCite Metadata
Subject: Re: Do you have any questions related to DataCite's metadata or metadata schema? Please details.

 

[Jessica Parland-von Essen]

Dear all,

We're working with our national application profile in Finland for our long term preservation etc services (the profile can be found here if you are interested https://tietomallit.suomi.fi/model/mrd/CatalogRecord/ - still under construction .... )

What has come up working closely with some research projects is the need for allocating PIDs for cumulative datasets (we currently use URN, so we can easily do this), but we have gathered that this is a separate type of dataset, which needs a different citation guideline. We will probably implement this so that is technically possible to to only ONE type of change i e adding a file. Once a dataset is "closed" = made static, it will not be possible to change it any more, at all without a new version and new PID will be created. I've always liked to consider DOI as ensuring very safe, precise and simple citing (i e dataset is always exactly the same and there is no need for dating download etc)

We also found a quite good description on this case by CEOS (links below). 

What I would like to ask is, whether you see there is -- or should be -- a way in DataCite to express this specific type of dataset (cumulative with the specific restrictions and guidelines below)? 

Personally, I think it is important to be able to advice users to cite data correctly to ensure reproducibility, but we would not like to mint and allocate PIDs in too large numbers. The cumulative dataset could be one way to do this for measurement data etc. It would also support our data classification effort, that has gained a positive response from both data archives, research institutions and researchers in Finland - described here: https://www.linkedin.com/pulse/research-data-many-kinds-jessica-parland-von-essen/ - The model has been welcomed as a tool to plan research data management.

Happy to hear your thoughts on this.

best regards,

Jessica Parland-von Essen

CSC, Finland

Sources:

http://ceos.org/ourwork/workinggroups/wgiss/documents/

http://ceos.org/document_management/Working_Groups/WGISS/Documents/WGISS%20Best%20Practices/CEOS%20Persistent%20Identifier%20Best%20Practices_v1.2.pdf

On Monday, August 19, 2013 at 9:44:37 PM UTC+3, Joan Starr wrote:

[Hatfield Hart, Amy J]

Hello Jessica,

Thank you for your question. Dynamic datasets is something the DataCite Metadata Working Group has recently addressed.

From the DataCite Metadata documentation (https://schema.datacite.org/meta/kernel-4.1/doc/DataCite-MetadataKernel_v4.1.pdf  p. 12):

"A special note regarding citation of dynamic datasets: For datasets that are continuously and rapidly updated, there are special challenges both in citation and preservation. For citation, four approaches are possible:

a) Cite a specific slice or subset (the set of updates to the dataset made during a particular period of time or to a particular area of the dataset); Example: Data Request T.Jansen; SAHFOS; Work published 2014 via SAHFOS ; Area Def: 54-65°N, 0-45°W. Temporal Def: 1980-2012 (April-August) Taxonomic Def: All zooplankton; (dataset). https://doi.org/10.7487/2014.15.1.1

b) Cite a specific snap-shot (a copy of the entire dataset made at a specific time); Example: König-Langlo, G., & Sieger, R. (2010). BSRN snapshot 2010-01 as ISO image file (3.75 GB) [Data set]. PANGAEA - Data Publisher for Earth & Environmental Science. (dataset). https://doi.org/10.1594/pangaea.833424

c) Cite the continuously updated dataset6 , but add an Access Date and Time to the citation. Example: Doe, J. and R. Roe. 2001. The FOO Data Set. Version 2.3. The FOO Data Center. (dataset). https://doi.org/10.xxxx/notfoo.547983. Accessed 1 May 2011.

d) Cite a query , time-stamped for re-execution against a versioned database. The RDA recommended citation for this approach is: R. Roe. 2017. "The Moo Data Query" created at 2017-07-21 10:25:30 PID https://doi.org/10.xxxx/notmoo.857988. Subset of Moo Database (dataset). PID https://doi.org/10.xxxx/bigmoo.360873.

Notes: The “slice,” “snap‐shot” and "query" options require unique identifiers. Be aware that the third option (c) necessarily means that following the citation does not result in access to the resource as cited. This limits reproducibility of the work that uses this form of citation. In addition, please note that access date and time may be combined with the first (a), second (b) and fourth (d) options, but it must be used with the third option (c).

The fourth option (d) may shift more work onto repositories to store database versions for all the queries, so not all repositories will be able to support this alternative."

Also, one of our WG members shared her practice. We offer her suggestion as an example that may be something to consider.

"In our data archive we provide DOI’s at different hierarchical levels of the data collection.

An example is the time series collection of the radar measurements:

 

Collection: Atmospheric observations Cabauw

        Dataset: IDRA weather radar measurements – all data  https://doi.org/10.4121/uuid:5f3bcaa2-a456-4a66-a67b-1eec928cae6d

               Dataset: IDRA weather radar measurements – month YYYY-MM   example: https://doi.org/10.4121/uuid:4e602365-a20c-4e81-86f8-bee280daecad

        Dataset: IDRA weather radar measurements – day YYYY-MM-DD   example: https://doi.org/10.4121/uuid:378d68f4-e3dc-4441-b8ac-f8c90b887934

 

The hierarchical relationship between the ‘parent’ and the ‘child’ is described in the respective metadata of each dataset.

The choice on which level of detail a DOI is assigned, is depending on what level is likely to be cited."

I hope this information is helpful. Please do respond if you have more questions or comments.

All the best!

Amy

Co-Chair DataCite Metadata Working Group

Amy J. Hatfield Hart, MLS

Assistant Professor of Library Science, Metadata Specialist

Purdue University Libraries, Research Data​

hat...@purdue.edu

---

From: datacite...@googlegroups.com <datacite...@googlegroups.com> on behalf of Jessica Parland-von Essen <jessi...@gmail.com>
Sent: Monday, March 19, 2018 10:28 AM

To: DataCite Metadata
Subject: Re: Do you have any questions related to DataCite's metadata or metadata schema? Please details.

[Jessica Parland-von Essen]

Thank you, Amy, this was helpful, the classification and description is good. This perspective is the important one, the one of citing data and the quality of research. I'm looking at this from a bit of a different angle, the point of view of of he producer of generic research data and the curation and publishing of this data, in which managing persistent identifiers and creating metadata need to be done as efficiently as possible. I think I will try to think some more about this.

:)

Jessica

/CSC

---

From: datacite-metadata@googlegroups.com <datacite-metadata@googlegroups.com> on behalf of Jessica Parland-von Essen <jessi...@gmail.com>

Sent: Monday, March 19, 2018 10:28 AM
To: DataCite Metadata
Subject: Re: Do you have any questions related to DataCite's metadata or metadata schema? Please details.

Dear all,

We're working with our national application profile in Finland for our long term preservation etc services (the profile can be found here if you are interested https://tietomallit.suomi.fi/model/mrd/CatalogRecord/ - still under construction .... )

What has come up working closely with some research projects is the need for allocating PIDs for cumulative datasets (we currently use URN, so we can easily do this), but we have gathered that this is a separate type of dataset, which needs a different citation guideline. We will probably implement this so that is technically possible to to only ONE type of change i e adding a file. Once a dataset is "closed" = made static, it will not be possible to change it any more, at all without a new version and new PID will be created. I've always liked to consider DOI as ensuring very safe, precise and simple citing (i e dataset is always exactly the same and there is no need for dating download etc)

We also found a quite good description on this case by CEOS (links below). 

What I would like to ask is, whether you see there is -- or should be -- a way in DataCite to express this specific type of dataset (cumulative with the specific restrictions and guidelines below)? 

Personally, I think it is important to be able to advice users to cite data correctly to ensure reproducibility, but we would not like to mint and allocate PIDs in too large numbers. The cumulative dataset could be one way to do this for measurement data etc. It would also support our data classification effort, that has gained a positive response from both data archives, research institutions and researchers in Finland - described here: https://www.linkedin.com/pulse/research-data-many-kinds-jessica-parland-von-essen/ - The model has been welcomed as a tool to plan research data management.

Happy to hear your thoughts on this.

best regards,

Jessica Parland-von Essen

CSC, Finland

Sources:

http://ceos.org/ourwork/workinggroups/wgiss/documents/

http://ceos.org/document_management/Working_Groups/WGISS/Documents/WGISS%20Best%20Practices/CEOS%20Persistent%20Identifier%20Best%20Practices_v1.2.pdf

On Monday, August 19, 2013 at 9:44:37 PM UTC+3, Joan Starr wrote:

--
You received this message because you are subscribed to the Google Groups "DataCite Metadata" group.

To unsubscribe from this group and stop receiving emails from it, send an email to datacite-metadata+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jessica Parland-von Essen



Mobil +358 50 501 2543



Min blogg Essetter
Mitt Twitterkonto JPvE

[Mary Rose de Vega]

i'm going to asked the same thing i'm clueless can you guide me i've got my own schema since i was on web development i came from network architecture IETF 

[Mary Rose de Vega]

ICAN'T tell when i work in web component i usually accept all those required software for the used of operating system and i'll do the update too i put a color from the Adobe and work with the digital media server MPEG 

On Monday, October 14, 2013 at 7:29:10 PM UTC+8, Stefan Jakobsson wrote:

Hi,

I have a question regarding the geoLocationBox element. The specification says that the first latitude-longitude pair specifies the lower corner, and the second specifies the upper corner. It does not say whether it's the south-west and north-east corner, or the north-west and south-east corner that should be specified. Can someone clarify this?

An alternative way to describe a bounding box would be to specify the west longitude, east longitude, north latitude and south latitude as separate elements under geoLocationBox. That way the ordering is unimportant. DDI, for example, uses this method, see http://www.ddialliance.org/Specification/DDI-Lifecycle/3.1/XMLSchema/FieldLevelDocumentation/reusable_xsd/complexTypes/BoundingBoxType.html.

Thanks,

Stefan Jakobsson

Systems Developer

Swedish National Data Service

On Monday, August 19, 2013 8:44:37 PM UTC+2, Joan Starr wrote:

[Mary Rose de Vega]

i've got my own work at schema.org maybe yuo want guys tyo work with me there ??

On Monday, October 14, 2013 at 8:39:23 PM UTC+8, Frauke Ziedorn wrote:

The updated documentation is now online avaiable at http://schema.datacite.org/meta/kernel-3/index.html

On Monday, October 14, 2013 1:40:55 PM UTC+2, frauke.ziedorn wrote:

Hello Stefan,

Thank you for your comment. I clearified the description of GeoLocation Box in our documentation and also corrected the example. It now reads:

A box contains two white space separated latitude-longitude pairs, with each pair separated by whitespace. The first pair is the lower corner (normally south west), the second is the upper corner (normally north east).

Example:<geoLocationBox>41.090 -71.032  42.893 -68.211 </geoLocationBox>

I hope this clears things up.
It may take some time before the changes are online as our admin is currently out of office.

Best regards
Frauke Ziedorn

---