The 5th Dublin Core Metadata Workshop

The National Art Library also contributed draft DC metadata examples for the report of the Visual Arts Data Service workshop held in Edinburgh in March 1997. The NAL's records describe the Library's HTML pages relating to Charles Dickens.

Activities in the Field of Electronic Information Management and Meta-Data in Physics

Activities on this field:
The goal is to build up a distributed electronic information system in physics. The first version of this system is Harvest-based. A link-list of (hopefully) all European Physics Departments EuroPhysDep underlies a Harvest-Search-Machine. The only longterm possibility (from our point of view) to produce complete, correct, and readable search-results is a common basis of Meta-Tags on the Web-Pages of the participant departments. To make it as simple as possible for the authors to produce a complete and correct set of Meta-Tags, the MMM authoring-tool was developed.

DC-Meta-Data is also used in the EPRINT-project to combine the global preprint-database xxx and the distributed preprints on the local webservers (EuroPhysDoc). A common search-interface for both types of preprints is planned to be set up. One of the big questions is how to force the authors to publish their articles with Meta-Tags on the local webserver. One solution is developed with a Web-Upload-Form-Interface (coming soon).

Implementations in DC:
Implementing DC into EuroPhysNet, xxx, and EPRINT indicates that still some changes and additions into DC should be done:

• Meta-Meta-Data:
  for dissertations it is essentialy important to know who produced the Meta-Tags. To allow this, Meta-Information about the Meta-Information has to be archived. One idea to implement this:

  	<!-- MetaCreatorDate="Mrs. Author, 03061997"-->
  	<META NAME="DC.creator" CONTENT="(TYPE=name)Mr. Author">
  	<META NAME="DC.subject" CONTENT="Keyword.Author1, Keyword.Author2, ...">
  	...
  	<!-- /MetaCreatorDate="Mrs. Author, 03061997"-->
  	<!-- MetaCreatorDate="library, 04091997"-->
  	<META NAME="DC.subject" CONTENT="Keyword.Library1, Keyword.Lirary2, ...">
  	<!-- /MetaCreatorDate="library, 04091997"-->
  

• DC.Type:
  the Type Unpublished is too general. Most of the authors of (still) unpublished documents want to stress the state of the publication-process. There should be additional types as: "tobepulished", "accepted" with an additional required field e.g. journal.

• DC.Format:
  in this field a mixture of the document-format and the archiving-format is very common. If you want to describe a z-compressed tar-archive that contains a mixture of document-formats, what to do? One solution could be, to separate the archiving-format (tar, gz-compressed, ... uncompressed) and the data-format (text/html, application/pdf, ... multi).

• DC-Implementation:
  how should DC be used in other than HTML-Files? There should be a safe binding between the Meta-Information and the described file. To optimize this, DC-Tags should be implemented directly into the file. But, how to do this in GIF-Images, PNG-Images, PDF-Texts, ...?

19. Australian Geodynamics Cooperative Research Centre

The Australian Geodynamics Cooperative Research Centre (AGCRC) - a collaboration between two public research organisations and two universities - is using the WWW as a primary delivery system for the results of its research. The results are composed of a variety of material presented as a number of different resource types. In particular

1. a substantial document archive has been established comprising at least the abstracts of all reports and publications - currently stored as complete HTML documents
2. a number of numeric datasets are available for visualisation and modelling using interactive web-based tools - currently these are mainly stored in a GIS (GRASS) database.

The primary discovery mechanisms for these resources consist of

1. an index and search engine, based on AltaVista software customised for (optionally) searching on particular elements within documents and also to use geographic information included in documents
2. the menus comprising the entry point into the visualisation and modelling application

These use two different metadata systems:

1. the publications include embedded metadata, using the <META ...> element in the HTML header, - with semantics following Dublin Core extended with the ANZLIC standard for geospatial information, and local (AGCRC) terms for more specialised information
2. numeric data are "published" to the system through small description files placed in a special directory, including information about the format and location of the dataset, some keywords, and links to associated text-based descriptions, thumbnail and preview images, etc. - these currently use a locally developed extensible attribute=value syntax which we call "GIX".

A crude link has been made between these two systems by allowing maps produced by the visualisation tool to act as an interface onto the document search system, with key-words chosen from names of the map-layers selected. However, we would like to unify the system properly, in order deliver targetted information regarding Australian Geodynamics to the client regardless of what type of resource it is.

Constraints on implementation include:

• items are provided by AGCRC staff in a variety of formats - so a method for providing metadata externally (ie detached from the data) is needed
• information may be used by clients in a variety of ways, and additional modelling resources will be provided by the AGCRC in due course - so the system must be extensible, and provide the abilit
• information providers currently have limited motivation or ability for either re-formatting or careful abstracting - so the system must be simple

The intention is to move to a system based on

• external description files for most resources, including text
• semantics will include the union of the existing systems - they will be stored using locally developed terms, and tools and mappings developed so that these can be provided to clients by the server according to external systems (eg - DC, ANZLIC) on demand
• encoding will use XML/RDF
• a single description can point to multiple respresentations of a resource (as in the GIX example) which may be used either alternately or in combination when the resource is presented to a client
• resources will be stored using the file system, not a DBMS
• text resources will most likely be stored as HTML body fragments, which are assembled into a complete HTML document by the server using additional information indicated by the description (as an example - the dataset description pages displayed from the visualisation tool currently operate in this way, with thumbnails linked to previews included in the served page).

This approach introduces a few challenges.

• the primary issue concerns the integrity of such a system, in particular maintaining links between resources and their descriptions - including back links whenever the resource format allows this
• it will still be desirable to include the full text of text resources in the index for unstructured searching, so the description files will not be the only source of indexing material for resource discovery.

20. Interconnect Technologies Corp. projects

A. Project Description:

Project Name:

(Example) Aviation Safety Digital Library

Institutional Affiliation:

Interconnect Technologies Corp.

Contact Person (persons) and email:

Mike Raugh, raugh@interconnect.com;
Diane Hillmann, dih1@cornell.edu

URL(s) if publically available:

Not available yet

B. Information System Summary:

(Example) R&D website containing selected information primarily for general aviation

2. Projected Collection Size (number of records)

First year: 1,000 (subset subject to DC cataloging)
Third year: 10,000 (subset subject to DC cataloging)

3. Type of data, formats:

Primarily text documents, in PDF, HTML or ASCII.

C. Metadata:

• _X_ Management of the collection
• _X_ Enhanced searchability
• _X_ Interoperability
• _X_ Value-added services
• _X_ Other: Promote appreciation and use of standards among clients

2. Who is creating the metadata? What training and support are provided?
Most created by Diane Hillmann, under contract. Guidelines being written so some can be provided by others.

3. Which metadata scheme is used?

Minimal Dublin Core + Additional Module (e.g., specialized metadata for aviation safety information)

4. Encoding strategy:

• _X_ external database
• _X_ auxiliary HTML files (not embedded in resource)
• __ metadata embedded in resource

We would like to embed in resource at some point, if possible. We do create sample datasets for clients demonstrating the benefits of embedding.

5. Granularity of the description:

• _X_ individual documents
• __ groups of documents
• __ collections

We are debating whether to catalog individual documents of large collections (order of 500,000 structured records) or to merely catalog the collections

6. Dublin Core strengths and weaknesses encountered in deployment

Simplicity both strength and weakness

Some elements still a bit ambiguous, need to be better defined both in general and within this project

7. Which DC fields are used/not used?

Elements used:

1. title
2. creator
3. subject
4. description
5. publisher
6. contributors
7. date
8. type
9. format
10. identifier (both qualified and unqualified)
11. source

Elements not used

1. language
2. relation
3. coverage
4. rights

8. Have additional local fields been added?

No.

9. Which qualifiers are used/needed?, at what level of detail?

Have qualified "identifier" to use with URL and also used unqualified for other identifying numbers on documents.

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?

Haven't yet but are considering several options, including term lists.

D. Tools (provide URLs if freely available):

2. Metadata creator tools:

Template for DC

3. Automatic metadata extraction tools

4. Discovery tools (directory/browsing type):

Browsing of catalog records via index hierarchies, with final links to resource

5. Indexing and search tools:

Searching, with optional filtering on metadata

6. Other tools:

Display of metadata

7. Help system, tutorials etc.

8. Is the metadata indexed, browsable, searchable, through a local or external service?

We provide both local services and client-based services.

E. Experiences from the planning and production phases:

1. Describe problems and accomplishments from both phases

Many of our problems have been related to the DATE element, primarily because of its limitations in its present form. Not only did we need more than one kind of date, we were concerned about being too restrictive about format.

The other major problems had not much to do with the Dublin Core,but with the dysfunctional practices of the web sites we were working with. They tended to change URLs, and as one moved to frames, we lost the ability to relate our metadata to a specific item.

2. Do you have estimates of the costs and benefits for the creation or use of metadata?

3. What measures (or expectations) of service improvement through metadata usage do you have?

21. University of Michigan Digital Library Registry Database

A. Project Description:

Project Name:

UM Gateway/UM Library Digital Registry

Institutional Affiliation:

University of Michigan Library

Contact Person (persons) and email:

Lynn Marko (lfmarko@umich.edu)
David Richtmyer (dlrichtm@umich.edu)

URL(s) if publicly available:

UM Gateway (http://www.umich.edu)
UM Library Digital Registry (http://dns.hti.umich.edu/registry/)

B. Information System Summary:

1. Domain of Content

Electronically accessible scholarly resources used in support of campus research and instructional programs and/or resources of institutional value. Resources included in the Digital Library collection are variously purchased, leased, locally created, or recommended as worthwhile sites hosted elsewhere but readily accessible to U-M users. As with collections in other formats, selection of an individual resource is based upon a judgment of the scholarly quality, relevance, and organization of the content as well as the contribution its inclusion makes to the scope and balance of the collection as whole.

2. Projected Collection Size

First year:

1,000 records

Third year:

10,000 records

3. Type of data, formats

a. Type of data:

Bibliographic metadata

b. Formats:

SGML, HTML

C. Metadata:

1. What are the intended functions of the metadata used?

X Management of the collection
X Enhanced searchability
X Interoperability
X Value-added services


2. Who is creating the metadata? What training and support are provided?

The UM Digital Registry database is made up of metadata records created collaboratively between those 'registering' a site and professional catalogers in the Original Cataloging Dept. of Technical Services, Harlan Hatcher Graduate Library. Site registrars are variously UM Subject Selector librarians and Web site creators that desire to have their site embedded within the UM Gateway homepage. A forms page is provided that allows for these registrars to complete metadata element content without the need of specialized knowledge. Help aids, embedded in this page as links, are available to support the user in the metadata creation. The completed form is then reviewed and enhanced (e.g., names are standardized, controlled subject vocabulary is added to the registrar-supplied uncontrolled subject vocabulary, site subject content analysis is provided through classification, etc.) by UM professional catalogers.

3. Which metadata scheme is used?

After review of relevant bibliographic metadata systems, we chose a scheme devised by David Richtmyer. All fields used are USMARC compliant, so that cross-formatting is possible.

4. Encoding strategy:

X external database
__ auxiliary HTML files (not embedded in resource)
__ metadata embedded in resource


5. Granularity of the description:

X individual documents
X groups of documents
X collections


6. Dublin Core strengths and weaknesses encountered in deployment

Not applicable, but see no. 7 below.

7. Which DC fields are used/not used?

For descriptions of the elements, see Metadata Element Definitions and their MARC Equivalents. Many of the fields are identical (albeit with different descriptor names) to those found in DC; however some have been concatenated together, others separated and elaborated upon, while others are not used at all. For example, Content Provider (DC=Creator) is subdivided into Individual Provider and Organizational Provider. Subject Keywords (uncontrolled vocabulary) and Subject Headings (controlled vocabulary) are provided with separate fields and our registrars can look at lists of either when deciding upon subject access. Similarly, the DC field Rights Management is subdivided into Availability and Constraint areas. Due to the vagaries of the various Web authors, we provide fields for both Title and for Other Titles. As it happened, DC fields Source and Relation are subsumed into the Abstract field; which is fully indexed.

8. Have additional local fields been added?

We have many local fields used for internal bookkeeping purposes that are not included in DC; see, for example, the last nine fields in the document Metadata Element Definitions.

9. Which qualifiers are used/needed?, at what level of detail?

Not applicable.

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?

We provide both controlled (LC) and uncontrolled vocabulary; Subject searches index both kinds of vocabulary. In addition, other thesauri of controlled language are used; e.g. MeSH. Finally, we classify all Registry records with multiple LC classification numbers.

D. Tools:

1. Conversion tools

We are currently working on a script that will convert USMARC to Registry Record and vice-versa.

2. Metadata creator tools

Gateway Registry Submission Form
Library Selector Submission Form
Cataloger Record Submission Form
ISO8859-1 Table Memory Aid
List of Uncontrolled Keywords


3. Automatic metadata extraction tools

We are looking into the use of Harvest for this purpose, but have not implemented it yet.

4. Discovery tools

Our interface features both a browse and search functionality. We use SGML for the markup of our metadata records, UNIX for our OS, and OpenText's PAT search engine.

5. Indexing and search tools

OpenText's PAT fully indexes the entirety of our metadata records.

6. Other tools

See above.

7. Help system, tutorials, etc.

Currently we have no help screens instituted, but are working on them.

8. Is the metadata indexed, browsable, searchable, through a local or external service?

All of the above, through our local service.

E. Experiences from the planning and production phases:

1. Describe problems and accomplishments from both phases

When Registry Database was first conceived of it was assumed that our site selectors and registrars would be inputting roughly 90% of the information, and that the other 10% would be supplied by our cadre of professional catalogers. We found, however, a great reluctance on the part of our contributors to step into the breech of what was once only the province of the professional cataloger. As a consequence, we pared down the number of elements that we asked our registrars to fill out to a minimal set of metadata elements. For example, none of the current set of classification schemes (e.g., BSO, Dewey, LC, etc.) are really easy enough for a lay individual to use with any kind of precision. Were we to do this project again, we would definitely reduce the number of elements to a much smaller set.

Another problem encountered was the great (roughly 20%) number of links that become broken, either by the time that the registrar's record reaches our catalogers, or after an item has been cataloged and placed in the Registry Database. This problem was solved partially by a script that tests all links when the database is indexed (roughly once a week), and then reports back to our cataloging staff whether the link is dead or has moved. If a link is found broken the script automatically removes the record from the active database and places it in repository file for manual resolution by the cataloging staff. Still, the maintenance of this problem is largely manual, and therefore costly.

Because the planning and implementation of this project included people from diverse backgrounds in the information field (i.e., catalogers, public services librarians, programmers), pitfalls that would normally ensue from a project narrowly directed were avoided. For example, when 'View Details' is chosen for a record, the order and placement of the metadata fields was determined not by a preordained set of rules but by what was found to be what the typical user most often looked for in a record. Thus, the Providers field was placed not a the top of the record as is found in regular AACR2/MARC records, but rather further down in the body of information. Why? Because it was found that, unlike printed books, most users did not remember a site by its creator, but rather by its title.

2. Have you estimated the costs and benefits of the creation or use of metadata?

We have found that it takes roughly the same amount of time for our catalogers to complete a Registry Database record as it does them to do Brief Record Cataloging of a printed monograph. Although the time varies from individual to individual and the quality and quantity of metadata content provided by the registrar, three to four records per hour are about the maximum an individual can do. Why? Because we are still providing the kinds of metadata content standardization that provides accurate and reliable retrieval: authority work, classification, and subject analysis. Though this cost is high, the benefits are obvious: reliable retrieval of information.

3. What measures (or expectations) of service improvement through metadata usage do you have?

The improvement in service for users trying to locate electronic resources of high quality is roughly comparable to users trying to locate printed resources of high quality: when you have millions of items in a collection, precise retrieval is directly correlated to the precision of the metadata used to describe an item. For example, formerly within the Library, the only listing of selector-approved sites were the various bibliographic pages that our Subject Selectors maintained. There are about 50 Subject Selectors within the University Library system, so:
• Unless a patron was familiar with the selectors in his or her area, and hence the addresses of their lists of approved links, the chances of discovering these lists were slim
• As staff changed jobs or responsibilities, individuals responsible for selection in a particular discipline changed, resulting in further difficulty in locating the right person/address
• The large number of people involved meant that continuity of link checking was often problematical, resulting in lists with many broken links.

The advent of the Registry Database solved all of these retrieval problems.

22. INDOREG : INternet DOcument REGistration

Danish Library Centre

Reported by Randi Diget Hansen

In recognition of the fact that national information and cultural heritage are not only conveyed in the form of printed matter, the Danish Library Centre (DBC) and the Royal Library decided in 1995 to propose to the National Bibliographic Council and the Danish Ministry of Culture that the national bibliography should also include electronic documents, although only those found in a physical state in the form of diskettes and CD-ROMs. Such documents have been included in the Danish book list and Danish periodical list since 1996.

At the same time, developments in the form of Web publication on the Internet were moving so fast that DBC decided to launch a project to find out whether net publications could and should be subject to bibliographic control in the same way as printed and electronic publications in fixed physical form. The reason for this was that we felt the existing search engines on the net suffered from the general problem of searching in unqualified data and generally replying with excessive amounts of data. We also felt that the information contained in net publications did not basically differ from the information in publications in fixed physical form. If net-borne publications are excluded from bibliographic control, there is a risk that many people will find it difficult to gain access to an increasing amount of the information citizens need, as opposed to the information stored in products in fixed physical form. The ultimate target was that registration should be in DanBib (the joint superstructure system for the complete Danish library system) alongside the national bibliography and the total list of publications at Danish libraries. DanBib should also be used to make direct linking to documents possible.

In addition, a new Legal Deposit Act was pending (and was passed during the project period). It covers all electronic documents on the net which are deemed likely to be available as independent units in a final form. The Act requires that a general standpoint should be taken in terms of national bibliographic registration.

In the autumn of 1996 the Danish National Library Authority (Statens Bibliotekstjeneste, or SBT) decided to provide joint funding of the project. At the same time the principle of national bibliographic registration of electronic documents on the Internet was presented to the National Bibliographic Council, who expressed their agreement. In this connection the project's ultimate target was altered to include not only evaluation of bibliographic control in general, but also proposals as to how the work involved in national bibliography should be performed.

In order to obtain a model for a national bibliographic registration system that includes net publications, the project has focused on the following areas in particular.

Inclusion criteria

Proposed principles for national bibliographic inclusion criteria have been drawn up. They operate with the concepts of static and dynamic publications - with homepages as an independent category under dynamic publications. These principles reflect the criteria that exist for publications in fixed physical form, since there are formal requirements with regard to both size and (to a certain extent) content. For instance, it is proposed that publications of a commercial, internal, highly local or private nature should not be included.

Registration method

The proposed registration method seeks to cover the special needs of net publications in terms of description and format. The problems of describing static and dynamic publications vary. The level of registration has not been finalised yet; for one thing, the new cataloguing rules drawn up in parallel to the project by one of the project participants will have to be tested in practice before the levels in the national bibliography generally are recommended to SBT in the autumn of 1997.

Self-registration by authors/publishers using metadata is regarded as a necessary supplement if very large amounts of information are to be registered.

For this purpose there is produced a modified version of the Dublin Core Template as used in the Nordic Metadata Project to allow for Danish conditions.

Tracing and maintenance

To ensure the constant validity of addresses (URLs), a PURL server has been established which functions as a central exchange. If an international number system is adopted like the ISBN system, it must of course be used. But a solution is required immediately. The further development of automatic tools to check publications is needed. In addition, we feel that the current collaboration between national bibliography and legal deposits should continue. Finally, concentrated efforts are needed to persuade authors/publishers of net publications to regard such publications in the same way as printed publications.

Storage in DanBib

The DanBib base will be given a Web interface in the autumn of 1997, making it possible to link from registration to net publications.

A project report is available at http://www.purl.dk/rapport/html.uk/

23. Metadata Project of State Library of Queensland

Institutional Affiliation:
State Library of Queensland

Contact Person (persons) and email:
Jennie Thornely; J.Thornely@slq.qld.gov.au

B. Information System Summary:

1. Domain of Content :
Gov

2. Projected Collection Size (number of records)
First year: 450
Third year: 650

3. Type of data, formats
html; text; jpeg; gif

C. Metadata:

1. What are the intended functions of the metadata used?
_y_ Management of the collection
_y_ Enhanced searchability
_y_ Interoperability
_y_ Value-added services
__ Other:
provides linkage for opac in the near future

2. Who is creating the metadata? What training and support are provided?
The Project is managed by Manager, Technical Services and Senior Librarian, Internet Services Unit.
The project is intended to be finished by Technical Services.

3. Which metadata scheme is used?
Dublin Core

4. Encoding strategy:
_N_ external database
_N_ auxiliary HTML files (not embedded in resource)
_Y_ metadata embedded in resource

5. Granularity of the description:
_Y_ individual documents
_N_ groups of documents
_N_ collections

6. Dublin Core strengths and weaknesses encountered in deployment
Flexiblity, easy to use and understand;
Still evolving.

7. Which DC fields are used/not used?
We decided to use two levels of complexity, ie, for simple (contents) files we use title/creator/date/description/rights; for the more complicated (contents) files, we apply all the appropriated elements.

8. Have additional local fields been added?
No.

9. Which qualifiers are used/needed?, at what level of detail?
We use type and scheme, eg. LC Name authority; LCSH.

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?
No.

D. Tools (provide URLs if freely available):

1. Conversion tools (eg., MARC -> DC)
No

2. Metadata creator tools
No

3. Automatic metadata extraction tools
No

4. Discovery tools (directory/browsing type)
No

5. Indexing and search tools
will develop

6. Other tools
No

7. Help system, tutorials etc.
Working on a local procedure/manual

8. Is the metadata indexed, browsable, searchable, through a local or external service?
Yes

E. Experiences from the planning and production phases:

1. Describe problems and accomplishments from both phases
a. Took awhile for different Divisions to agree for their staff to deploy metadata when they creat the Divisional Web pages.
b. Difficult to discuss problems relating to Dublin Core (locally), as there are not many 'experienced metadata deployers' around.
c. Have to change the syntax a few times when new information was received via meta2.

2. Do you estimates of the costs and benefits for the creation or use of metadata?
cost in $$$ - No
benefits - Yes, as discussed by many people.

3. What measures (or expectations) of service improvement through metadata usage do you have?
We are still in the process of deploying metadata on Web pages.
We would like to see the increase usage of State Library's Website in the near future

MedExplore & Dublin Core generation

Reported by Jacques DUCLOY

CRIN - CNRS & INRIA Lorraine

Preliminary Version

1 - The MedExplore Project

The aim of MedExplore is to give a group of experts confronted with an unforeseen situation the mastery of its terminological resources and a synthetic and deeper knowledge of the state of the art. This will be achieved by the creation of a system of investigation.

Such a system allows an user to navigate through concept graphs and to manipulate conjointly various pieces of information (large international databases, local source documents, raw information from the INTERNET such as news-groups), written in different languages. We have chosen to begin on biomedical fields due to the large amount of what we call "structuring" funds (such as MEDLINE, EMBASE or PASCAL which possess an homogeneous indexing and, with some associated projects like UMLS, a quasi knowledge based representation).

Our project deals with Metadata with two complementary aspects. First one is "how to improve our retrieval on the INTERNET".

The second one sounds like an indirect but very interesting effect. As we could know the main contents which allow to retrieve a set of relevant documents, we are able to use them for producing the good metadata allowing an information to be well retrieved by the search-engines. We are beginning to experiment the generation of Dublin Core metadata from an existing set of local information

2 - The DILIB Workbench

The engineering techniques used for MedExplore rest upon the generalisation of SGML codification allowing the use of SGML toolboxes and linguistic modules libraries. We have developed DILIB, an SGML workbench which contains a set of basic components for building Information Retrieval Systems

2.1 - SGML, homogenisation of information

We use to convert all information in an SGML markup whose structure is very close to original one. For instance a downloaded record issued from MEDLINE such as:

 AN : 96081277
 TI : Orthotopic pulmonary valve replacement with a homograft.
 AU : Saha K,Iyer KS, Sharma R, Bhan A, Airan B, Venugopal P
 CS : Department of Cardiothoracic and Vascular Surgery, All India Institute of Medical Science
 JN : J Heart Valve Dis CP : (ENGLAND)
 PY : Mar 1995
 VO : 4 (2) p187-91
 SN : 0966-8519
 LA : ENGLISH ...

becomes:

<medline>
   <AN>96081277</AN>
   <TI>Orthotopic pulmonary valve replacement with a homograft.</TI>
   <AU><e>Saha K</e><e>Iyer KS</e><e>Sharma R</e><e>Bhan A</e><e>Airan B</e><e>Venugopal P</e></AU>
   <CS>Department of Cardiothoracic and Vascular Surgery, All India Institute of Medical Sciences, New Delhi, India.</CS>
   <JN>J Heart Valve Dis</JN>
   <CP>(ENGLAND)</CP>
   <PY>Mar 1995</PY>

We can do that for traditional MARC formats (ISO 2707), and a CCF (UNESCO) record like:

-- header position 7 = s
001 157028
020 00@BISDS 
022 11@A19880120 
101 00@A0253-021X 
201 00@ALegisLative study - Food and ... Agriculture
210 00@AEtudes législatives - ... Agriculture @Lfre
400 00@ARome@BFood and Agriculture Organization of the United Nations

can be marked as:

<record h7="s">
<f001>157028</f001>
<f020 ind="00"><sB>ISDS</sB></f020>
<f022 ind="20"><sA>198880120</sA></f021>
<f201 ind="00"><sA>Legislative study - Food and ... Agriculture
<f210 ind="00"><sA>Etudes Legislatives ... Agriculture</sA>

               <sL>fre</sL>...
</record>

We may remark that only two filters are required to convert all king of MARC format in that way.

In some case, it may be interesting to proceed little transformation on a set of data. For instance, we need to handle multilingual information coming from UMLS whose records look like:

   C0017379|ENG|P|L0017379|PF|S0022690|Carriers, Genetic|
   C0017379|ENG|P|L0017379|VW|S0044411|Genetic Carriers|
   C0017379|ENG|P|L0017379|VWS|S0022684|Carrier, Genetic|
   C0017379|ENG|P|L0017379|VWS|S0044407|Genetic Carrier|
   C0017379|POR|P|L0436728|PF|S0561010|TRANSPORTADORES GENETICOS|
   C0017379|SPA|P|L0447330|PF|S0571612|PORTADORES GENETICOS|

C0017379 identifies a "unique concept" which gets an English prefered form (Carriers, Genetic), various usual forms and some translations.

This information is available in a table format. In an SGML context, it is more convenient to group all information dealing with a particular concept into one record like:

<mrcon>
   <CUI>C0017379</CUI>
   <TP><PF>Carriers, Genetic</PF>
      <VW>Genetic Carriers</VW>
      <VWS>Carrier, Genetic</VWS>
      <VWS>Genetic Carrier</VWS></TP>
   <VL l="POR">
      <TP><PF>TRANSPORTADORES GENETICOS</PF></TP>
   </VL>
   <VL l="SPA"><TP><PF>PORTADORES GENETICOS</PF>
      </TP></VL>
</mrcon>

2.2 - Handling SGML information with DILIB

DILIB provides a set of tools for handling SGML or XML elements. They are available at different programming level.

For instance, if we want to add the key-word "AIDS" as an element tagged with <e> to an SGML element which is pointed by "kw" variable in a C program, we have to write:

   SgmlAddChild (kw, SgmlCreateLeaf("e", AIDS));

In the same way, we can use shell commands to handle some set of records. We have introduced a "path pattern mechanism" to specify a set of elements into a given documents. For instance, if we want to select records which contain "AIDS" as part of key-words and print the corresponding title, we just have to write:

SgmlSelect -g medline/KW/e#AIDS -g medline/TI -p @g2

(where "-g" is used by analogy with grep and @g2 identifies the 2th "g" sub-command)

As HTML and Dublin Core strongly deals with SGML, it becomes very easy to generate metadata in a programming environment. For instance, the following program:

   SgmlNode *meta;
   meta= SgmlCreateEmptyMark("META");
   SgmlSetAtt(meta, "name", "DC.subject");
   SgmlSetAtt(meta, "content", "AIDS");

will produce:

  <META name="DC.subject" content="AIDS">

2.3 Information analysis with MedExplore/DILIB

In that way, DILIB contains also a set of basic components in order to build customised information retrieval systems (in which internal data like inverted files are also coded on an SGML basis). These tools allow a global analysis of large set of information. At the present time, our tools mainly deal with combination of associations of terms.

For people who are not familiar with these techniques, an elementary way of analysing a set of records consist in printing a sorted list of terms with their number of occurences in a given corpus. For instance, if I know nothing about "Wallerian Degeneration", reading the following result:

     [393] Rats
     [268] *Nerve Degeneration
     [247] Wallerian Degeneration
     [241] Microscopy, Electron
     [215] *Wallerian Degeneration
     [184] Time Factors
     [128] Middle Age
     [121] Mice
     [120] Rats, Inbred Strains
     [115] Adult
     [76] Nerve Degeneration 

In this previous sample, knowing nothing about Wallerian degeneration, we can deduce that it deals with nervous system.

     [166] *Wallerian Degeneration - *Nerve Degeneration
     [119] Rats, Inbred Strains - Rats
     [109] Rats - *Nerve Degeneration
     [101] Rats - Microscopy, Electron
     [88] Rats - *Wallerian Degeneration
     [86] Wallerian Degeneration - Rats
     [80] Time Factors - Rats
     [75] Microscopy, Electron - *Nerve Degeneration 

But the better results will be obtained by clustering the associations which get some common terms. Below you will find a sample of cluster in which an expert could see a real convergence of relevant topics.

    List of Key-Words
     [34] Rats, Sprague-Dawley
     [62] *Nerve Regeneration
     [51] Nerve Crush
     [27] Sciatic Nerve_Injuries_IN
     [34] Sciatic Nerve_Physiology--PH
     [17] *Peripheral Nerves_Injuries_IN
     [38] *Sciatic Nerve_Physiology--PH
   Internal Relationships
     [7] Rats, Sprague-Dawley - Nerve Crush
     [11] Sciatic Nerve_Injuries_IN - Nerve Crush
     [10] Sciatic Nerve_Physiology--PH - Nerve Crush
     [10] Nerve Crush - *Nerve Regeneration
     [8] Sciatic Nerve_Injuries_IN - *Peripheral Nerves_Injuries_IN
     [7] Sciatic Nerve_Physiology--PH - *Nerve Regeneration
     [7] Nerve Crush - *Sciatic Nerve_Physiology--PH
     [6] Sciatic Nerve_Injuries_IN - Rats, Sprague-Dawley 

For a given field, the list of clusters gives the main thematic lines, for instance:

    *Wallerian Degeneration - *Nerve Degeneration
    Middle Age - Adult
    Mice, Inbred C57BL - Mice
    Rats, Sprague-Dawley - *Nerve Regeneration
    Immunohistochemistry - Wallerian Degeneration_Physiology--PH
    Nerve Regeneration - Nerve Degeneration
    Sciatic Nerve_Metabolism--ME - *Peripheral Nerves_Metabolism--ME
    Neural Conduction - Action Potentials 

(each cluster is identified by its more weighted association)

Applying these techniques on the authors allow the identification of the main teams (i.d. group of persons who use to publish together).

  Levine RA - Weyman AE
  List of Authors
     [5] Levine RA
     [5] Weyman AE
     [9] Lethor JP
     [4] Siu SC
     [4] Rivera JM
     [4] Handschumacher MD
     [3] Picard MH
     [2] Juilliere Y
  Internal Relationships
     [5] Levine RA - Weyman AE
     [5] Lethor JP - Weyman AE
     [5] Lethor JP - Levine RA
     [4] Siu SC - Weyman AE
   ...
     [3] Lethor JP - Picard MH
     [3] Handschumacher MD - Picard MH
     [2] Juilliere Y - Lethor JP

The traditional area of this set of techniques deals with technical or scientific surveys. In the framework of MedExplore project we use them to search through the INTERNET. Some search engines like AltaVista, with the "live topics facilities", give now the same kind of facilities.

3 - Using MedExplore to search information from the INTERNET

In other words, we have to solve the different level of inter-operability between heterogeneous data. SGML/XML brings us a good answer for the "cofidication - structuration level". Now we have to deal with more semantic levels. As we work in specialised area, we have chosen to simplify this problem by defining a kernel vocabulary which contain a limited number of terms (between 100 and 300). Such a lexicon can be generated by automatic tools (for instance cluterization) and, in a second step, improved by a specialist.

For the extraction of documents from the INTERNET, we are testing an approach which gives us some first and "no so bad" results. The principle consist in associating to each term of the kernel vocabulary an histogram of the more frequent word which are founded in the abstracts of corresponding MEDLINE records.

For instance, for the key-word "Newborn, Infant", in a local base dealing with "cardiology", the associated histogram looks like:

   [59] patient
   [42] pulmonary
   [37] tetralogy
   [33] fallot
   [29] infant
   [27] heart
   [25] artery
   [24] defect
   [19] month
   [19] outflow
   [19] ventricular 

Now, we just have to send a query on Altavista, using this set of words.

If we use the same kind of techniques for an author, we obtain interesting results too. Here is the vocabulary associated to Pr. JP Lethor from its bibliography on MEDLINE:

   [35] ventricular
   [31] volume
   [27] left
   [26] dimensional
   [20] coronary
   [19] three
   [16] method
   [15] patient
   [13] defect
   [13] image
   [12] excised
   [11] doppler
   [10] artery
   [10] echocardiography
   [10] tau
   [9]  pressure

We are also implementing multilingual queries by using multilingual bibliographic data bases such as PASCAL.

4 - Generating Dublin Core Metadata

For instance, we are working on the generation of a server allowing browsing through a collection of Medical Images. Each image is described in French with a little set of information such as:

<doc>
  <id>lethor/007_001
  <auteur><e>Lethor JP
  <specialite>Cardiologie infantile
  <tech><e>Radiographie
  <acquis><e>
  <organe><e>Coeur
     Poumon
  <patho><e>Tétralogie de Fallot
  <motif>rupture de patch infundibulaire
  <age>12 ans
  <cr><e>rupture de patch infundibulaire après correction chirurgicale de tétralogie de Fallot
  <resultat>tétralogie de Fallot

<meta name="DC.title" lang="fr"
      content="Image : tétralogie de Fallot">
<meta name="DC.creator" content="Lethor JP">
<meta name="DC.subject" lang="fr"
      content="Coeur, COEUR (RADIOGRAPHIE ), Poumon, POUMON (RADIOGRAPHIE ), Radiographie, Tétralogie de Fallot">
<meta name="DC.subject"
      content=" Heart, Heart_Radiography, Lung, Lung_Radiography, Radiography, Tetralogy of Fallot">
<meta name="DC.subject" scheme="MESH"
      content=" Heart, Lung, Radiography, Tetralogy of Fallot">

5 - Conclusion: improving MetaData extraction and generation

At the present time, we have not yet implemented a real utilisation of Metadata. The previous sample was just done for feasibility reasons. For the next future we are investigating two ways:

• improve the linguistic performances (extraction of nominal groups...)
• by statistical techniques, detect the more discriminant terms (an more the more frequent) in a given corpus
• analyse the first set of INTERNET documents with very close techniques in order to identify some better Metadata to send.

Once these Metadata are identified, we have shown that we can use them to produce a good set of relevant Metadata to be used by an organisation working on a particular medical topic to see its documents well retrieved on the INTERNET.

An interesting feature of the Dublin Core deals with the generation of several set of contents with they various scheme. We will also work on the use and generation of some other specific elements, for instance, in a set of medical images, the implementation of the coverage element related to the ages of the patients.

25. UC Berkeley Digital Library Catalog

A. Project Description:

Project Name:

Digital Library Catalog

Institutional Affiliation:

The Library, University of California, Berkeley

Contact Person (persons) and email:

Roy Tennant
rtennant@library.berkeley.edu

URL(s) if publically available:

<URL:http://sunsite.berkeley.edu/Catalog/>

B. Information System Summary:

1. Domain of Content

Presently, all digital objects of intellectual significance on the Berkeley Digital Library SunSITE. The site has a more complete collection description.

2. Projected Collection Size (number of records)

First year:

Presently around 20,000 records, could grow beyond 30,000 by year's end.

Third year:

No idea.

3. Type of data, formats

Items being described include books, essays, speeches, and other textual material in HTML, technical reports (in various formats), photographs, engravings and other visual materials, and video and sound clips.

C. Metadata:

1. What are the intended functions of the metadata used?

__ Management of the collection

X_ Enhanced searchability

X_ Interoperability

__ Value-added services

__ Other:

2. Who is creating the metadata? What training and support are provided?

Project is being prototyped by a library assistant and a professional librarian, with no special training or support. This will change when/if the project goes beyond a prototype.

3. Which metadata scheme is used?

Dublin Core and two additional elements for local use.

4. Encoding strategy:

__ external database

X_ auxiliary HTML files (not embedded in resource)

__ metadata embedded in resource

Presently working with external HTML files, but will likely migrate to an external database after the prototype phase.

5. Granularity of the description:

X_ individual documents

__ groups of documents

__ collections

Where "documents" includes photographs, movies, sound clips, etc.

6. Dublin Core strengths and weaknesses encountered in deployment

Strengths: A ready made minimal set, a de facto standard with international support. Flexible, extensible.
Weaknesses: Lack of definition regarding what should be in each element and how it should be encoded.

7. Which DC fields are used/not used?

We provide for the user of all Dublin Core elements, and most records use most of them. The fields most unused are probably COVERAGE and CONTRIBUTOR.

8. Have additional local fields been added?

Yes, "UCB.Notes" and "UCB.Version".

9. Which qualifiers are used/needed?, at what level of detail?

In DC.subject, we use "(SCHEME=LCSH)" for Library of Congress subject headings.

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?

Yes, we have provisions for using Library of Congress Subject Headings (LCSH) as well as uncontrolled subject keywords.

D. Tools (provide URLs if freely available):

1. Conversion tools (eg., MARC -> DC)

2. Metadata creator tools

Locally-produced Web form and Perl scripts, see
<URL:http://sunsite.berkeley.edu/Catalog/behind.html/> for screen-shots; the system itself is not publically available.

3. Automatic metadata extraction tools

Locally produced Perl programs, that are tailored to specific input streams.

4. Discovery tools (directory/browsing type)

-

5. Indexing and search tools

We are using SWISH-Enhanced, which can limit searches to META tags (thus searches can be limited to specific DC fields)
<URL:
http://sunsite.berkeley.edu/SWISH-E/
>

6. Other tools

-

7. Help system, tutorials etc.

None yet.

8. Is the metadata indexed, browsable, searchable, through a local or external service?

Yes, at
<URL:
http://sunsite.berkeley.edu/Catalog/
>

E. Experiences from the planning and production phases:

1. Describe problems and accomplishments from both phases

-

2. Do you estimates of the costs and benefits for the creation or use of metadata?

We estimate the cost of manual record creation at $2-$2.40 US per record. We do not have an estimate for the cost of creating records by software translation, but it is clearly pennies apiece.

3. What measures (or expectations) of service improvement through metadata usage do you have?

We do not yet have any measures of service improvement, but we expect our users to have a much easier time of locating digital objects on our server, as well as serendipitous discovery of related objects from separate collections. We also anticipate service improvements from our ability to share our object records with others through cooperative projects.

26. EdNA

Description for Dublin Core 5 Workshop

This document contains a description of the EdNA Directory Service and its use of metadata prepared for participants at the DC5 workshop in Helsinki, October 1997. It is structured based on the Dublin Core Project Summary Questionnaire v 1.0 970911 prepared for that workshop.

Contents

A. Project Description

1. Project Name
   
2. Institutional Affiliation
   
3. Contacts and email
   
4. URL(s)

B. Information System Summary

1. Domain of Content
2. Projected Collection Size
3. Type of data, formats

C. Metadata

1. What are the intended functions of the metadata used?
2. Who is creating the metadata? What training and support are provided?
3. Which metadata scheme is used?
4. Encoding strategy
5. Granularity of the description
6. Dublin Core strengths and weaknesses encountered in deployment
7. Which DC fields are used/not used?
8. Have additional local fields been added?
9. Which qualifiers are used/needed?, at what level of detail?
10. Do you provide any subject description support?

D. Tools

1. Conversion tools
2. Metadata creator tools
3. Automatic metadata extraction tools
4. Discovery tools (directory/browsing type)
5. Indexing and search tools
6. Other tools
7. Help system, tutorials etc.
8. Is the metadata indexed, browsable, searchable, through a local or external service?

E. Experiences from the planning and production phases

1. Problems and accomplishments from both phases
2. Estimates of the costs and benefits for the creation or use of metadata?
3. What measures (or expectations) of service improvement through metadata usage do you have?

A. Project Description

1. Project Name

EdNA (Education Network Australia)

2. Institutional Affiliation

EdNA is a collaborative project between all Australian States and Territories and all sectors of education and training; schools, vocational education and training (which include TAFE - technical and further education), adult community education, and higher education (universities). More details are available by selecting the "About EdNA" option from the home page of the EdNA web site. The "EdNA Directory Service" refers to the services provided at the web site http://www.edna.edu.au. "EdNA" is a broader process of collaboration of which the EdNA Directory Service is one product.

The EdNA Directory Service is managed by the Open Learning Technology Corporation (OLTC: http://www.oltc.edu.au).

3. Contacts and email

Email addressed to webdesk@edna.edu.au will be distributed to a range of people associated with the management of EdNA.

4. URL(s)

The EdNA Directory Service is at: http://www.edna.edu.au

The EdNA Metadata Standard is at:
http://www.edna.edu.au/edna/owa/info.getpage?sp=auto&pagecode=5210

B. Information System Summary

1. Domain of Content

Web based resources relevant to any sector of education and training in Australia, subject to various quality assurance procedures. Listed resources can be divided into two main types (although these are not treated differently in any fundamental way by the EdNA Directory Service).

A) Internal resources. Internet resources created by organisations involved in education and training in Australia. For example, a school home page, course material available online, research reports, course directories.

B) External resources. Internet resources created outside the education system but identified as being a relevant resource by some organisation within the EdNA structure. For example the " Dictionary of Gamilaraay/Kamilaroi" (an aboriginal language) or "The NASA Homepage".

In the initial identification of resources, the schools sector have concentrated on external resources and the vocational education and training and higher education sectors have concentrated on internal resources.

2. Projected Collection Size

There are currently over 3,700 individually identified URLs in the EdNA Database. However the EdNA search facility provides access to a much wider collection of resources because as well as indexing the actual pages in the Database, some URLs are tagged as sites or link pages and links on these pages are followed and indexed. As the EdNA Directory Service has not been formally launched yet, it is virtually impossible to predict the range of resources which might be identified over the next few years once EdNA is widely used throughout the Australian education and training systems.

3. Type of data, formats

The EdNA software allow for any URL type, but the overwhelming majority of resources identified are web pages, with a sprinkling of ftp: and gopher: resources.

C. Metadata

1. What are the intended functions of the metadata used?

The intended functions of metadata in EdNA are to:

• Assist with user searches by allowing a more detailed specification of the type of material being sought (rather than the current search which is basically a free text search).

• Weight search results so that words in metadata fields are given priority over words in the text of a document. (This should increase the chance of finding relevant resources even if the user does not explicitly search on a metadata field.)

• Automatically allocate items to categories in the EdNA directory structure.

• Assist with management of EdNA Directory content.

• Provide general cataloguing information which can enable documents in the EdNA database to be searched by other catalogues (for example to allow education documents entered in EdNA to be searched by libraries).

2. Who is creating the metadata? What training and support are provided?

While a first draft of the EdNA Metadata Standard has been agreed, there has not been any substantial implementation of metadata to date as the tools to assist with its creation and entry are still being developed.

3. Which metadata scheme is used?

The EdNA Metadata Standard is based on Dublin Core with the addition of:

• Some EdNA specific fields.

• EdNA specific schemes for some DC and EdNA specific fields.

• Documentation of existing cataloguing schemes and thesauruses used in Australian education and training for use as schemes within the DC.subject field.

4. Encoding strategy

The ultimate location of metadata about items in the EdNA Directory will be in the EdNA database. There are five major ways in which item information gets into the EdNA database:

• Items are suggested by users and reviewed and approved by an organisation which is part of the EdNA administration system.

• Some organisations are approved to directly create items in the EdNA database using secure web based forms.

• Items are identified for searching by following links from selected sites.

• Existing listings of Internet resources identified by other education organisation are transferred to the EdNA database by 'bulk upload' using a defined format for delimited text files.

• Once agreed quality assurance procedures are in place, approved sites will be visited by the EdNA robot and items with EdNA metadata will be automatically indexed and added to (or updated in) the EdNA database.

For 'internal' resources (ie those created by education organisations in Australia), the intention is that item owners will use the EdNA metadata wizard currently under development to embed metadata in their HTML.

Where items are not owned within the education system, EdNA will still recognise basic Dublin Core metadata. The entry of items directly into the database via the bulk uploads or the administration system creates metadata which is not stored in the original documents.

5. Granularity of the description:

Resources in EdNA are indexed at the individual URL level.

6. Dublin Core strengths and weaknesses encountered in deployment

The use of Dublin Core has saved EdNA from having to create a metadata system from scratch and provides a range of additional benefits:

• Resources created in the Australian education system with embedded metadata will be recognised and more easily found by other search engines which recognise Dublin Core fields.

• It is anticipated that software tools developed to support Dublin Core will assist with the creation and management of metadata records.

7. Which DC fields are used/not used?

The following DC fields are not actively supported in the EdNA Metadata Standard, however if users create them they will be stored in the EdNA Database and will be searchable:

DC.relation

DC.contributor

DC.source

8. Have additional local fields been added?

The following additional fields are defined:

EDNA.entered: Date item was entered (used for management purposes)

EDNA.approver: Email of person or organisation approving the item for inclusion in EdNA.

EDNA.reassessment: Number of months until resource should be reassessed.

EDNA.userlevel: Typical level of user for which the content would be most appropriate.

EDNA.categories: Numbers representing categories in the EdNA Directory in which the resource is either suggested for inclusion, or in the case of approved organisations, is automatically included.

EDNA.indexlevel: How many levels should the EdNA search engine follow links from this page?

EDNA.indexsites: When the EdNA search engine follows links from this page (as controlled by the INDEXLEVEL field), how many web servers are to be accessed?

EDNA.review: A third party review of the resource.

NB: All these fields are metadata in the sense that they are information about resources. However some of these fields are generated by the management of resources within EdNA. Depending on the nature of the field and future policy decisions:

• the contents of the fields may or may not be visible to users of EdNA.

• the content of the field may sometimes be stored in Web documents or may only be stored in the EdNA server.

9. Which qualifiers are used/needed? At what level of detail?

It is intended to support the language qualifier but no work has been done on this to date. See other sections and the EdNA Metadata Standard for details of schemes supported.

10. Do you provide any subject description support?

Not at the moment but negotiations are underway with the owners of thesaurus used in education and training in Australia to make documentation of these available online to support the cataloguing of resources in EdNA.

D. Tools

1. Conversion tools

None are currently implemented but details of web resources are currently being imported into EdNA from a range of other databases ("bulk upload"). At the moment this includes just title and description plus EdNA categories. Future versions may include other metadata.

2. Metadata creator tools

A "metadata Wizard" is currently under development to assist users to generate EdNA metadata for inclusion in web pages they own. It will be announced on the meta2 list when it is available.

3. Automatic metadata extraction tools

Details not available.

4. Discovery tools (directory/browsing type)

None.

5. Indexing and search tools

Not developed yet.

6. Other tools

None.

7. Help system, tutorials etc.

None yet except for instructions in the EdNA Metadata Standard.

8. Is the metadata indexed, browsable, searchable, through a local or external service?

The ways in which Dublin Core and EdNA metadata will be used in searching is still being defined. The field EDNA.categories will be used to allocate items to the EdNA Directory allowing browsing of items.

E. Experiences from the planning and production phases

1. Problems and accomplishments from both phases

2. Estimates of the costs and benefits for the creation or use of metadata

No cost benefit analysis has been conducted.

3. Expectation of service improvement through metadata usage

As EdNA is a decentralised system where resources are identified and managed by a wide range of organisations, the use of metadata created and maintained in a decentralised ways is seen as the only practical way of cataloguing resources.

Disclaimer

This brief description of EdNA and it use of metadata was developed by Jack Gilding specifically for the benefit of attendees at the DC5 workshop in Helsinki. While other stakeholders in the EdNA project have been requested to comment, due to time constraints in this process it should not be regarded as an 'official' document.

Last updated: 2 October 1997.
Contact: Jack Gilding j.gilding@c031.aone.net.au

27. Netpublikationer

Danish Government Publications on WWW

Reported by: Ulrik Andersen, ua@si.dk, Danish State Information Service
Date: October 3, 1997

In Denmark we have implemented most of the Dublin Core metadata elements in the Government WWW-publications published from 1997.

Background

In order to make public information material accessible on WWW and to make the distribution of public information material more efficient, all new publications issued by Danish ministries, government offices and agencies shall be published on WWW, in parallel with the printed editions, from 1997.

A common format including metadata

To insure a common format for the WWW-publications, The Danish Ministry of Research and Information Technology and The Danish State Information Service have worked out a standard describing how the publications shall be encoded. Technically, the standard is based on the official HTML 3.2 specifications.

The standard, called Netpublikationer, contains a series of requirements and recommendations. The standard is available at http://www.fsk.dk/fsk/publ/online-pub/.

One of the requirements is that the publications shall contain metadata of a common scheme. This scheme is based on the Dublin Core elements, but is extended in order to insure the additional metainformation required in the database in The Danish State Information Service. The database contains information about all Danish government publications - in print and on WWW.

Dublin Core elements

The DC elements we have implemented are:

1. Title
2. Creator
3. Subject
4. Description
5. Publisher
6. Contributors
7. Date
9. Format
10. Identifier
11. Source
12. Language
13. Relation

Netpublikationer is not available in English. But chapter 4.2 gives an impression of the metadata scheme and syntax used.

Tools

In order to make it as easy - and cheap - as possible for the civil servants and the web-companies to produce WWW-publications, we are developing an application (freeware), which can convert "raw" and incorrect HTML-documents into documents, that are formatted correct. This conversion includes the creating of a correct set of metadata. The software is expected to be released in November 1997.

Additional information

Netpublikationer is a part of the overall government policy on the use of information technology in modern society. These matters can be studied in a number of publications (in English) at The Danish Ministry of Researchand Information Technology.

The PANDORA Project

For more information, see: http://www.nla.gov.au/policy/pandje97.html.

The National Library of Australia (NLA) is developing an electronic archive called PANDORA to provide long term access to significant Australian online publications. A dedicated online archive will be established in the first instance. Publications contained in it will be updated on an ongoing basis and converted to new formats as technology demands.

The PANDORA project has, as its main objective, to:

capture, archive and provide long term access to significant Australian online publications selected for national preservation.

As part of this the PANDORA project will implement a system of describing archived documents based on the Dublin Core attributes, to make online searching for information more efficient.

There are four prongs in the PANDORA project's approach to the diverse subject of metadata that will offer long-term, integrated searching across all of the Library's search systems.

1. Tools for encouraging publishers to generate Dublin Core metadata have been tested and it has been found that metadata forms (similar to the Nordic template) are preferable to the automatic generation of Dublin Core metadata by tools such as 'DC.dot'

   The PANDORA project plans to encourage publishers to provide Dublin Core metadata, either with or within their publications.

2. The PANDORA project is currently in the process of considering screen designs and workflows for the archive management facility. As part of this process, online help text is being drafted, which will have two flow-on effects:
   • each data element will be defined according to ISO standard 11179
   • clear definitions of the metadata will be created to expidite its use in a national archive model context

3. The ISO 11179 standard covers "Information technology - Specification and standardization of data elements' and contains guidelines for the description of data elements in a Logical Data Model. In part 6, the standard provides a framework for the registration and management of data elements when they are used by a broad group of managers. For example, in a national archive model context, if all State libraries were to use the same metadata as the PANDORA archive, then changes to any one data element could be managed through the infrastructure provided by Part 6.

   For more information on this approach see http://www.ariadne.ac.uk/issue11/metadata/, which gives examples of metadata registries that might be affected by the use of ISO11179.

4. PANDORA-Dublin Core crosswalk. In the Logical Data Model for the PANDORA archive database, a cross-walk between the archive and the Dublin Core elements has been provided. When provision is made to utilise pure Dublin Core elements for searching, PANDORA will be poised to take advantage of this development, either by extracting the Elements and placing them in a metadata repository, or by utilising the Dublin Core elements embedded in the publications by publishers.

For further information contact:

Debbie Campbell
PANDORA project officer
National Library of Australia
PARKES ACT 2600

phone: 06 262 1622
fax: 06 257 1703
dcampbel@nla.gov.au

29. Scout Report Signpost

Project Name: Scout Report Signpost

Institutional Affiliation: Internet Scout Project/UW-Madison Computer Sciences Department

Contact Person (persons) and email:
Amy Tracy Wells (awells@cs.wisc.edu)
Aimee Glassel (aglassel@cs.wisc.edu)

URL(s) if publically available: http://www.signpost.org/signpost/index.html

1. Domain of Content:

2. Projected Collection Size (number of records):
   
   • First year: 2700 records
   • Third year: (still in first year)

3. Type of data, formats:
   • Animation/Video
   • Audio
   • Bibliography
   • Chart/Table
   • Conference/Solicitation
   • Database
   • Dictionary/Encyclopedia
   • Directory
   • Document
   • Educational Materials
   • FAQ
   • Graphics
   • Journal/Newspaper
   • Library Catalog
   • Mailing List/Newsgroup
   • Meta-site
   • Software

1. What are the intended functions of the metadata used?
   x__ Management of the collection
   x__ Enhanced searchability
   x__ Interoperability
   x__ Value-added services
   x__ Other:____________________________________________

2. Who is creating the metadata? What training and support are provided?
   Professional catalogers who hold Master's degrees in Library and Information Science. The Library of Congress' Subject Cataloging Manual and Classification Plus are the primary tools along with AACR2.

3. Which metadata scheme is used?
   A modified version of the Dublin Core.

4. Encoding strategy:
   x__ external database
   __ auxiliary HTML files (not embedded in resource)
   __ metadata embedded in resource

5. Granularity of the description:
   x__ individual documents
   x__ groups of documents
   x__ collections

6. Dublin Core strengths and weaknesses encountered in deployment.
   The literature surrounding the DC has appeared to indicate different uses for the "language" field and there appears to have also been a shift from "Object Type" to "Resource Type" which was not well documented. In general, while there has been much written on the DC, perhaps changes to the Core could be explicitly documented. The use of "Creator" and "Contributor" seemed less concrete (although conceptually they are well-founded) than perhaps the average end-user might intuitively grasp. "Resource Type", of course, requires development and concensus. "Date" is perhaps the most difficult field, not on a syntactic level, rather because it is dynamic and also difficult to define.

7. Which DC fields are used/not used?
   Used: Title (Site Title and Alternate Title), Creator (Author), Contributor, Publisher, Resource Type, Subject, (Library of Congress Subject Headings and Library of Congress Classifications), Description (Summary), Language, Date (not viewable to users), and Identifier.
   Not used: Format, Source, Relation, Coverage and Rights Management.

8. Have additional local fields been added?
   Yes, we have additional local fields which include Alternate Title, Date URL Last Verified, LC Classification and Resource Location which we use to identify a source's domain. We repeat certain fields such as Subject (Library of Congress Classification as many as five times and LC Classification as many as two times for a given record.)

9. Which qualifiers are used/needed?, at what level of detail?

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?
    Up to five Library of Congress Subject Headings are applied and up to two Library of Congress Classes are assigned.

1. Conversion tools (eg., MARC -> DC)
   N/A.

2. Metadata creator tools
   No.

3. Automatic metadata extraction tools
   No.

4. Discovery tools (directory/browsing type)
   Scout Reports (http://scout.cs.wisc.edu/scout/report/index.html
   )

5. Indexing and search tools

6. Other tools
   See C2 above.

7. Help system, tutorials etc.
   Signpost Help!

8. Is the metadata indexed, browsable, searchable, through a local or external service?
   Indexed, browseable and searchable at Signpost ( http://www.signpost.org/signpost/)

1. Describe problems and accomplishments from both phases
   For problems see C6 above.
   Accomplishments include the creation of a non-MARC system to effectively catalog the contents of the Scout Report and subsequent subject-specific Scout Reports all of which are Internet-based resources.

2. Do you estimates of the costs and benefits for the creation or use of metadata?

3. What measures (or expectations) of service improvement through metadata usage do you have?
   We expect (and hope!) that we can aid the U.S. higher education community in locating effective internet-based publications, tools and etc. to enhance their research.

   For more information, please contact us:
   Amy Tracy Wells (awells@cs.wisc.edu
   Aimee Glassel (aglassel@cs.wisc.edu)

GEM

A. Project Description: The Gateway to Educational Materials (GEM) is an initiative of the U.S. Department of Education and National Library of Education (NLE). NLE's goal is to improve the organization and accessibility of the substantial, but uncataloged, collections of educational materials which are already available on various federal, state, university, non-profit, and commercial Internet sites. In general, these valuable resources are difficult for most teachers to find in an efficient, effective manner. The goal of the Gateway to Educational Materials (GEM) project is to solve this resource discovery problem. For more information, see Proposal: DC-5 GEM Project Presentation

Project Name: Gateway to Educational Materials (GEM)

Institutional Affiliation: U.S. Department of Education, ERIC Clearinghouse on Information & Technology

Contact Person (persons) and email: Nancy A. Morgan, GEM Coordinator
nmorgan@ericir.syr.edu

URL(s) if publically available: http://geminfo.org/

B. Information System Summary:

1. Domain of Content: educational materials

2. Projected Collection Size (number of records)
First year: 10,000
Third year: 50,000

3. Type of data, formats: HTML files
Resource Types

C. Metadata:

1. What are the intended functions of the metadata used?

_X_ Management of the collection
_X_ Enhanced searchability
_X_ Interoperability
_X_ Value-added services
__ Other: ____________________________________________

2. Who is creating the metadata? A consortium of collection holders of educational materials, located on federal, state, university, non-profit, and commercial Internet sites.

What training and support are provided? Cataloging instructions, online help, listservs and technical support. The first group training session was help on September 18, 1997 in Washington, D.C.

3. Which metadata scheme is used?

4. Encoding strategy:

__ external database
_X_ auxiliary HTML files (not embedded in resource)
_X_ metadata embedded in resource

5. Granularity of the description:

_X_ individual documents
__ groups of documents
__ collections

6. Dublin Core strengths and weaknesses encountered in deployment. One "weakness" was the specificity of domain. GEM added 8 elements to the Dublin Core set and developed controlled vocabulary to improve description of education resources. One strength was that we were able to map to a large database of Marc records at Eisenhower National Clearinghouse.

7. Which DC fields are used/not used? All the DC fields were used.

8. Have additional local fields been added? Yes, 8 fields were added to better describe educational resources.

9. Which qualifiers are used/needed?, at what level of detail?

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)? Subject Controlled Vocabulary
See also Cataloging Instructions: Subject for use of the NICEM and ERIC Thesauri.

D. Tools (provide URLs if freely available):

1. Conversion tools (eg., MARC -> DC)

2. Metadata creator toolsGEMCat: a user-friendly, stand-alone program for cataloging Internet resources using the GEM element set and controlled vocabularies. Current version is for Windows 95 and Windows NT platforms. Under development is platform-independent web-based version of GEMCat.

3. Automatic metadata extraction tools

4. Discovery tools (directory/browsing type) Prototype search engines: PLWeb (Full-Text/Fielded Search Engine) and a Relational Database Management System Interface

5. Indexing and search tools Prototype search engines: PLWeb (Full-Text/Fielded Search Engine) and a Relational Database Management System Interface

6. Other tools: Metadata Harvesting Script: extracts GEM metadata from html-tagged documents located on UNIX servers. The harvest module is implemented in Perl. Currently under development is a cross-platform version.

7. Help system, tutorials etc. Cataloging instructions, online help, listservs and technical support. The first group training session was help on September 18, 1997 in Washington, D.C.

8. Is the metadata indexed, browsable, searchable, through a local or external service? Yes. See prototypes at: Prototype search engines: PLWeb (Full-Text/Fielded Search Engine) and a Relational Database Management System Interface. We envision competing interfaces to local and union catalogs as consortium members implement GEM.

E. Experiences from the planning and production phases:

1. Describe problems and accomplishments from both phases

2. Do you estimates of the costs and benefits for the creation or use of metadata?

3. What measures (or expectations) of service improvement through metadata usage do you have?

WWW.NIC.FUNET.FI Metadata interface

A. Project Description:

Institutional Affiliation: Center for Scientific Computing/Finnish University and Research Network

Contact Person (persons) and email: Harri K. Salminen
hks@nic.funet.fi

URL(s) if publically available: http://www.nic.funet.fi/

B. Information System Summary:

All kinds of freely distributable objects in the NIC.FUNET.FI archive.

2. Projected Collection Size (number of records)

First year:
50 000

Third year:
Over million

3. Type of data, formats

Major part of the collection consists currently of archived computer programs and text documents but the amount of all kinds of multimedia objects is growing. Formats include tar.gz, .zip, .exe, .sea, .hqx, .ps,.txt, .html, .gif, .jpeg, .mpeg, rtp etc. Most of them are listed in the ftp://ftp.funet.fi/README.FILETYPES

C. Metadata:

• X_ Management of the collection
• X_ Enhanced searchability
• X_ Interoperability
• __ Value-added services
• __ Other:

2. Who is creating the metadata? What training and support are provided?

Mostly volunteer archive admins and software authors in various fields as well as the CSC staff. Tools for semiautomatic creation and conversion of metadata are being developed so that for example author provided Linux Software Maps can be utilized.

3. Which metadata scheme is used?

Dublin Core with possible local extensions

4. Encoding strategy:

• X_ external database
• __ auxiliary HTML files (not embedded in resource)
• X_ metadata embedded in resource

The latter method will be used mostly for HTML pages maintained outside the metadata directory database.

5. Granularity of the description:

• X_ individual documents
• X_ groups of documents
• X_ collections

The goal is to describe individual objects but since we have over million files having metadata for groups and collections (directories and directory trees) is an important as well.

6. Dublin Core strengths and weaknesses encountered in deployment

DC is flexible and allows for multiple instances and many qualifiers but doesn't easily support hierarchical definitions and inheritance so information needs to be duplicated or described outside the DC format. E.g. We have currently implemented directory listings in another local format.

The format doesn't have currently support for special fields needed for file and multimedia objects like contents of an container (.zip, .tar, .rtp stream etc.), file size, requirements like os or program needed (mime type isn't enough), to use the file and amount of memory and disk space used after unpacked. For real time files there's need for the length in time, exact format descriptions (e.g. sdp) etc. possibly a url to external format dependent description might be enough.

These belong to the currently unresolved issues.

7. Which DC fields are used/not used?

We allow the use of all predefined DC fields

8. have additional local fields been added?

Not yet in DC. Our internal metadata format supports in additition a html version of the qualifiers that allows for images etc. and also the date and source of the last update for each field since there can be multiple sources for the same field.

9. Which qualifiers are used/needed?, at what level of detail?

In DC.subject, we plan to use scheme=foldoc (or x-foldoc) and we see the need for most of the other qualifiers as well as some new ones (see question 6). without qualifiers the dc format would be nearly useless to us.

10. Do you provide any subject description support (uncontrolled term lists, thesauri, classification systems)?

We have just started to provide the free online computing dictionary (foldoc) as a free controlled vocabulary suited to describe computer programs. we also have a taxonomical tree used currently to describe butterflies, plants etc. that is extended as needed. it has it's own www interface that is not yet dc compatible however.

If we can get from somewhere suitable free classification systems that suit our needs we'd like to offer that in our user interface. most seem to be copyrighted and without uptodate and granular enough classification for our needs.

Currently the only feasible way to classify computer files seems to be inventing your own classification scheme or just use such ad hoc hieararchies as is used in the directory trees.

D. Tools (provide URLs if freely available):

lsm -> dc being developed

2. Metadata creator tools

Web form is to be done. Some experiments with the DC creator have been done. Possibly a simple linemode tool is needed as well.

3. Automatic metadata extraction tools

Local perl programs

4. Discovery tools (directory/browsing type)

nicdir module for the Apache server that produces directory listings and also metadata descriptions for the local files. It uses an internal metadb shadow tree with internal metadata formats that contain the DC information as well as data needed for efficiently creating the HTML output with metadata on the fly in various formats. It requires the use of our local ls command and ftp server as well. The old non meta ftpd and ls are available at ftp://ftp.funet.fi/pub/unix/local/ and we foresee publishing the metadata versions in the future as well. It has been implemented for Digital Unix 4.0.

5. Indexing and search tools

We currently use local locate and archie databases but for indexing the metadata we plan to use the Nordic Web Index server available in house (http://nwi.funet.fi).

6. Other tools

A tool to create various listings and a public locate database from the output of our special ls command. A need for producing timesorted lists of URLs recommended for indexing by robots is foreseen. Current robots will do lots of unnecessary work while trying to browse the multiple views to the same information or they will just give up...

7. Help system, tutorials etc.

Some documentation on the design, formats and files used.

Rest is mostly documented as C and perl source code. Not yet published, but will be with the source code.

8. Is the metadata indexed, browsable, searchable, through a local or external service?

Soon, at www.nic.funet.fi (current test version in port 8888).

E. Experiences from the planning and production phases:

There was multiple versions of the DC format online and it was sometimes difficult to find out if documents referred to the current or some other proposed format. Also the current DC seems to concentrate on describing traditional literary resources and HTML but not other kinds of media like computer programs and multimedia objects. Even the BibTeX derived type list didn't have relevant types for many objects but I hope it's just temporary. Most of the DC fields seem to be usable in our context although it needs some guessing which one to use. E.g. how to best describe the mirrors and mirroring frequency of files or multiple versions of the same object. We also haven't yet seen any freely available tools like DC parsers, checkers and converters which might speed the implementation.

2. Do you have estimates of the costs and benefits for the creation or use of metadata?

We don't have cost estimates since most of it will be created part time by volunteers, authors and programs.

Main benefit should be easier searching and browsing of the over million files stored in the archive. Older methods allowed searches only on filenames which aren't in many cases descriptive enough to find the relevant files.

3. what measures (or expectations) of service improvement through metadata usage do you have?

We expect it to make finding the relevant files from our archive easier for the non-experienced WWW user who doesn't know the the right directory or file to look at making it less necessary to go overseas looking for the same files. System should also help in looking at different locations of the same files since we have large number of mirrors in addition to our local directory hierarchy we have multiple possible directory trees for the same category of files, bit like having multiple sublibraries inside a library with different classification system in each.

A common metadata format should make it also easier to offer tools and motivation for maintaining the metadata. Also people might not need to download files to just figure out if they really want it or not making the usage more efficient and users happier.

Dublin Core Metadata Use in Environment Australia

A. Project Description:

Institutional Affiliation: Environment Australia

Contact Person (persons) and email: Arthur D. Chapman

The project description is available at: http://www.environment.gov.au/www-standards/EA_DC.html
arthur@erin.gov.au