Jennifer Bowen | 3 May 15:55 2006
Picon

University of Rochester eXtensible Catalog (XC) project

With apologies for duplicate postings...

University of Rochester Receives Mellon Grant 
for eXtensible Catalog (XC)

The University of Rochester’s River Campus Libraries have received a 
$283,000 grant from the Andrew W. Mellon Foundation to begin planning and 
requirements analysis for the development of an open-source online system 
to unify access to traditional and digital library resources. The new 
system, known as eXtensible Catalog (XC), has the potential to allow future 
library users to get more out of academic library collections, and to give 
academic libraries more control over how best to help library users gather 
information. 

The first phase of the analysis will produce a plan that will include:

§	A survey of related projects that will assess the feasibility of 
bringing together and building upon work being done at other institutions 
§	An analysis of freely-available source code that could be 
incorporated into the development of XC 
§	Outreach to other academic institutions doing similar work at 
libraries 
§	Recommendations for the metadata requirements of the new system, 
informed by data models that focus on how metadata helps people gather and 
understand information 
§	An analysis of existing user studies and recommendations for 
additional studies of user practices to guide the development of XC 
§	An analysis of needs for the XC system within academic libraries

The complete press release for the project is available at: 
(Continue reading)

John Banning | 10 May 22:37 2006
Picon

<coordinate> examples

Hi all,
I was curious if anyone could provide examples of how geographic 
coordinates are being represented in MODS. I am specifically interested in 
representing bounding coordinates for maps. I read in the user guide that 
the information contained in this element is "equivalent to MARC 21 fields 
034 and 255" but wanted to know specifically if decimal degree 
(34.558889°, 16.253889°) or degree/minute/second (34° 33' 32.00", 16° 15' 
14.00") the preferred geographic representation?

Thanks in advance,
John Banning 

Picon

Re: <coordinate> examples

John --

See
http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#coordinates

------
<coordinates>
"coordinates" contains a statement of coordinates covered by the
resource. One or more statements may be supplied. If one is supplied, it
is a point (i.e., a single location); if two, it is a line; if more than
two, it is a n-sided polygon where n=number of coordinates assigned. No
three points should be co-linear, and coordinates should be supplied in
polygon-traversal order.
-------

We should correct this.

"statement of coordinates" was intended to represent a single point (i.e. a
single pair - latitude and longitude) and looking closely at it, it doesn't
(it seems that it represents a bounding box, i.e. 4-sided polygon).  So we
need to change the wording, so that:

" 'coordinates' contains a statement of coordinates covered by the
resource. One or more statements may be supplied."

should be replaced by something along these lines:

" 'coordinates' contains a pair of coordinate representing a single
geographic point.  It   is repeatable (so one or more points may be
specified)."
(Continue reading)

Laura Akerman | 11 May 01:22 2006

Re: <coordinate> examples

Ray,

We also have hoped that the method of expressing coordinates could become more standardized in MODS; while recognizing the need to accomodate mapped legacy "statement" data from MARC, we'd like to be able to describe the n-sided polygon and to specify the format of the coordinates in an attribute.

We've also wondered whether to go with decimal or degree-minute-second. Decimal can be expressed with available keyboard characters (if the degree symbol is omitted), that may be an advantage.   The format of the coordinate expression needs to incorporate hemisphere, otherwise hemisphere needs to be expressed another way in the element, perhaps as an attribute. 

Laura
--
Laura Akerman
Technology and Metadata Librarian
Robert W. Woodruff Library, Room 128
Emory University
Atlanta, Ga. 30322
phone (404) 727-6888
fax 404-727-0053

Ray Denenberg, Library of Congress wrote:
John -- See http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#coordinates ------ <coordinates> "coordinates" contains a statement of coordinates covered by the resource. One or more statements may be supplied. If one is supplied, it is a point (i.e., a single location); if two, it is a line; if more than two, it is a n-sided polygon where n=number of coordinates assigned. No three points should be co-linear, and coordinates should be supplied in polygon-traversal order. ------- We should correct this. "statement of coordinates" was intended to represent a single point (i.e. a single pair - latitude and longitude) and looking closely at it, it doesn't (it seems that it represents a bounding box, i.e. 4-sided polygon). So we need to change the wording, so that: " 'coordinates' contains a statement of coordinates covered by the resource. One or more statements may be supplied." should be replaced by something along these lines: " 'coordinates' contains a pair of coordinate representing a single geographic point. It is repeatable (so one or more points may be specified)." I take it that you want to represent a bounding polygon, arbitrary number of sides (i.e. not limited to a 4-sided polygon)? --Ray ----- Original Message ----- From: "John Banning" <jbanning-blo+y7B6FfY3r0Ub5QXD9Q@public.gmane.org> To: <MODS-0lvw86wZMd/ipf4q2MuE5g@public.gmane.org> Sent: Wednesday, May 10, 2006 4:37 PM Subject: [MODS] <coordinate> examples Hi all, I was curious if anyone could provide examples of how geographic coordinates are being represented in MODS. I am specifically interested in representing bounding coordinates for maps. I read in the user guide that the information contained in this element is "equivalent to MARC 21 fields 034 and 255" but wanted to know specifically if decimal degree (34.558889°, 16.253889°) or degree/minute/second (34° 33' 32.00", 16° 15' 14.00") the preferred geographic representation? Thanks in advance, John Banning



Ashley Sanders | 11 May 12:37 2006
Picon

[Fwd: An XML Schema for Holdings information]

Hello,

I am forwarding an email I sent to the JISC-DEVELOPMENT list as it
relates directly to Jan Ashton's email to this list back in
March. Apologies if you have already received this email from
other lists.

Ashley.

-------- Original Message --------
Subject: [JISC-DEVELOPMENT] An XML Schema for Holdings information
Date: Mon, 8 May 2006 15:37:53 +0100
From: Ashley Sanders <a.sanders@...>
Reply-To: Ashley Sanders <a.sanders@...>
To: JISC-DEVELOPMENT@...

Hello,

We are currently developing a new version of Copac that will be able to
deliver MODS XML records. As part of this development we required some
way of representing library holdings within a MODS record. We wanted
a simple schema and one that was relatively easy for a human to parse.
As a result we have developed our own Holdings Schema. This is
potentially of interest to other JISC services, and particularly those
(JISC or otherwise) which re-use Copac data. We have produced a web page
describing the schema at:

     http://copac.ac.uk/schemas/holdings/

We'd be pleased to receive feedback on the schema -- particularly
as this is our first attempt at one.

There is also a very simple keyword search interface of a (very
volatile and small) test database of Copac MODS records at:

     http://copac.ac.uk/test/mods.html

The CGI script called from the above web page only returns MODS
XML records. If your web browser can cope with XSLT, you should
get a fairly reasonable HTML display. A "View Source" should
reveal the MODS record with our holdings schema elements embedded
inside the MODS <extension> element.

Regards,

Ashley.
--

-- 
Ashley Sanders               a.sanders@...
Copac http://copac.ac.uk A MIMAS Service funded by JISC

Picon

xlink schema

(Note: this is addressed to METS with cc to MODS.)

A copy of the xlink schema is now at  http://www.loc.gov/standards/xlink.xsd

It is identical to those at:
http://www.loc.gov/standards/mods/xlink.xsd  and
http://www.loc.gov/standards/mets/xlink.xsd,
which are now identical to one another.

MODS will reference the new copy in its next version (3.2 - coming soon).

We recommend that METS also reference this new copy in its next version
(whenever).

This addresses a problem raised recently; when using the METS and MODS
schemas together there is a namespace conflict (same namespace, xlink, but
schema in two different places, won't validate).

(This problem remained unsolved for a few years because METS and MODS could
not reconcile different philosophies about the xlink namespace.  But I now
notice that the two schemas are identical, I'm not sure when the METS xlink
schema was changed, but apparently the philosophies are reconciled.)

Instead of asking METS to reference xlink from the MODS directory, or asking
MODS to reference xlink from the METS directory, we have put a copy in a
"neutral" directory and recommend that xlink be referenced from that
directory. The existing METS and MODS xlink schema copies will remain where
they are, so that older MODS and METS instances won't be affected.

--Ray Denenberg

Rebecca S. Guenther | 17 May 23:27 2006
Picon

MODS 3.2

We have a new version of MODS 3.2. We have incorporated a few suggestions
that were not in the previous version:

1. <url> attribute "access" now has the following enumerated values:
preview
raw object
object in context

They had been:
preview
metadata
object

2. Added attribute "usage" to <url> with one enumerated value: "primary
display".

3. Added  subelement <genre> under <subject>.

4. The schema location reference for xlink is changed to
http://www.loc.gov/standards/xlink.xsd.

We didn't have enough discussion on adding the attribute facet to
<subject>, so may need to put that on hold, unless someone wants to speak
up for including in this version. The question was whether it should go
just on the main element <subject> or also on any subelements (it was
suggested just on topic in addition to subject, but one could argue that
it's needed on all subelements).

Mods 3.2 draft is at:
http://www.loc.gov/standards/mods/v3/mods-3-2-draft-may-17.xsd

We hope to finalize it in about a week if there isn't any further
discussion. We do need to correct the problem of ID missing (see list of
changes at top of schema) as soon as possible.

Rebecca

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^  Rebecca S. Guenther                                   ^^
^^  Senior Networking and Standards Specialist            ^^
^^  Network Development and MARC Standards Office         ^^
^^  1st and Independence Ave. SE                          ^^
^^  Library of Congress                                   ^^
^^  Washington, DC 20540-4402                             ^^
^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
^^  rgue@...                                          ^^
^^                                                        ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Picon

Re: CQL Bilbiographic Searching Proposal (was: MODS search points)

 We've been working quietly for a few months on this, the (former) MODS
Search Points proposal, now the "CQL Bibliographic Searching Proposal".  The
original proposal has been significantly re-worked and the new proposal is
at:

  http://www.loc.gov/standards/sru/cql-bibliographic-searching.html

  This proposal is intended as a bluepring for further work.  At this point
we request comments both on the approach in general and the specific
details.

 We would like to form a working group of the SRU implementors to move this
along.  Please contact me directly if you are willing to participate.  We
seek bibliographic experts in particular, and we certainly need help from
the MODS community.

 --Ray

Edward Summers | 25 May 20:30 2006
Picon

Re: [Fwd: An XML Schema for Holdings information]

On May 11, 2006, at 5:37 AM, Ashley Sanders wrote:
> We are currently developing a new version of Copac that will be  
> able to
> deliver MODS XML records. As part of this development we required some
> way of representing library holdings within a MODS record. We wanted
> a simple schema and one that was relatively easy for a human to parse.
> As a result we have developed our own Holdings Schema.

Thanks for sending this Ashley--I'm not on the JISC list. I haven't  
had a chance to look in detail, but had you looked at the Universal  
Holdings Format [1] at all? Perhaps I'm mixing apples and oranges  
here...I'm just curious to know if the two schemas are related, and  
if you looked at it why you opted to roll your own. In fact, were  
there any other formats/schemas you considered?

//Ed

[1] http://www.openly.com/uhf/

Tony Hammond | 30 May 12:38 2006

Crosstown Traffic

Hi All:

In common with many other scholarly publishers Nature Publishing Group makes
citation level metadata available through its RSS feeds using the DC [1] and
PRISM [2] vocabularies, see

    http://www.nature.com/rss

It is also experimenting an SRU wrapper service into its search indexes
again exposing result records in DC and PRISM, see

    http://nurture.nature.com/search

Question: Would it be useful (or even helpful) to also expose this metadata
in MODS? As a complement to DC/PRISM? (And what about ONIX?) What is the
sweet spot for libraries/publishers? (We can't really do this without some
feedback from you guys. We may not have that level of imagination. Believe.
:~)

What do libraries want? What do end-users want? What can publishers do to
improve the overall situation? To make our metadata feeds more widely
useful?

Our general perception is that an open disclosure of our metadata records
will facilitate a third party service ecology which can only be of benefit
to all.

Looking for answers. Pretty, please.

Cheers,

Tony

--
Tony Hammond

New Technology, Nature Publishing Group
4 Crinan St., London N1 9XW, UK

tel:+44-20-7843-4659
mailto:t.hammond@...
--

[1] http://dublincore.org/

[2] http://prismstandard.org/

"The Publishing Requirements for Industry Standard Metadata (PRISM)
specification defines an XML metadata vocabulary for syndicating,
aggregating, post-processing and multi-purposing magazine, news, catalog,
book, and mainstream journal content. PRISM provides a framework for the
interchange and preservation of content and metadata, a collection of
elements to describe that content, and a set of controlled vocabularies
listing the values for those elements."

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


Gmane