http://wiki.metadataregistry.org/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=500&offset=&namespace=0&username=&tagfilter=Metadata-Registry - New pages [en]2024-03-28T15:47:35ZFrom Metadata-RegistryMediaWiki 1.22.6http://wiki.metadataregistry.org/Registry_Meeting_Notes,_DC-2010Registry Meeting Notes, DC-20102010-11-20T15:17:40Z<p>Diane: New page: '''Registry Community Meeting at DC-2010''' Wednesday, Oct. 20, 2010, Pittsburgh, PA Corey Harper (corey.harper@nyu.edu) began the session by reporting on a survey done last year as part...</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/SPARQL_EndpointSPARQL Endpoint2010-09-30T05:22:56Z<p>TomJohnson: /* SPARQL Endpoint */ reordered headers</p>
<hr />
<div>==SPARQL Resources==<br />
<br />
<br />
==Using the Endpoint==</div>TomJohnsonhttp://wiki.metadataregistry.org/Register_ConceptsRegister Concepts2010-09-22T18:10:12Z<p>Diane: Removing all content from page</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/Register_PropertiesRegister Properties2010-09-17T19:27:26Z<p>Diane: Removing all content from page</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/Open_Metadata_Registry_Step-By-Step_InstructionOpen Metadata Registry Step-By-Step Instruction2010-09-09T21:46:05Z<p>TomJohnson: /* SPARQL Queries */ Linking to an external SPARQL page (not yet created)</p>
<hr />
<div>The instructions below are intended to assist users to begin working effectively on the [[http://metadataregistry.org Open Metadata Registry]]. The same instructions apply for users of the [[http://sandbox.metadataregistry.org Open Metadata Registry Sandbox]].<br />
<br />
==User Management==<br />
<br />
===Register an Individual===<br />
<br />
On the upper right hand corner of every Registry page is a tab, which, for a user not signed in says:<br />
* sign in/register | about<br />
When clicked on '''sign in/register''', the following page appears:<br />
<br />
[[Image:UserRegStep1sm.jpg|700px]]<br />
<br />
A new user must register by clicking the box that says ''click here to create a new account'' which allows the user to fill in four boxes, all mandatory:<br />
* a login name<br />
* a password<br />
* a password confirmation<br />
* an email address<br />
<br />
The email address is used only for password retrieval, when a user forgets his or her password, is used for no other purpose, nor shared with any other service or individual.<br />
<br />
<br />
[[Image:UserRegStep2sm.jpg|700px]]<br />
<br />
Results: A new user account is created. The user should note the login name and password, as well as the email address entered at the time of new account registration.<br />
<br />
===Register an Agent===<br />
Now that you are logged in, you can add a resource owner. Every schema or vocabulary must be owned by a resource owning agent, which can be registered as either an individual or an organization.<br />
<br />
To register an agent, click on the '''(Add)''' link next to '''Resource Owners''' in the '''Browse''' box on the right side of the page and fill out the resulting form. '''Owner Name''' and '''Email''' are required fields. As with user registration, email addresses are kept private. When you register an agent, you become the registrar of that agent and an '''Agent Administrator''' for that organization or individual. Other users and administrators can be added later.<br />
<br />
[[Image:agent-registration.png|Agent Registration Page|700px]]<br />
<br />
<br />
'''DEFINITIONS:'''<br />
----<br />
<br />
An '''Agent Administrator''' is defined as: "One or more persons authorized to maintain one or more Agent records." This Agent Administrator is automatically the Vocabulary Administrator and Maintainer for all element sets or vocabularies owned by that Agent, and authorized to: <br />
* Edit/Delete Agent Records (an Agent can only be deleted by an Admin if there are no associated Vocabularies) <br />
* Designate other registered users as: <br />
** Agent Administrators for that Agent <br />
** Agent Contacts for that Agent (can receive notifications but has no explicit role in vocabulary development)<br />
** Vocabulary Administrator for individual Vocabularies owned by that Agent <br />
** Vocabulary Maintainers for individual Vocabularies owned by that Agent<br />
<br />
A '''Vocabulary Administrator''' is defined as: "One or more persons responsible for editorial functions related to one or more submitted vocabularies. The user who registers a Vocabulary becomes the Administrator for that Vocabulary." <br />
The Vocabulary Administrator is authorized to: <br />
* Act as Vocabulary Maintainer <br />
* Designate other registered users as Vocabulary Maintainers <br />
<br />
A '''Vocabulary Maintainer''' is defined as: "A registered user designated as responsible for maintaining a Vocabulary." <br />
The Vocabulary Maintainer is authorized to edit vocabulary properties and concepts.<br />
<br />
===Add Another Agent Administrator===<br />
<br />
<br />
===Add Another Vocabulary Administrator===<br />
<br />
<br />
===Add Another Maintainer===<br />
<br />
----<br />
<br />
<br />
==Register an Element Set (Properties or Classes)==<br />
<br />
<br />
In the context of these instructions, the term '''Element''' is used to refer to Properties or Classes when a distinction is unnecessary. When only one or the other is addressed, for instance when instructions refer only to Properties or only to Classes the distinction will be made in the instruction. <br />
<br />
We realize that the use of the term Element is not optimal, but until the software is revised we will continue to use it as needed in the instructions.<br />
<br />
<br />
===Register Property Vocabularies===<br />
<br />
A set of properties or classes (also called here an Element Set or an Element Vocabulary) starts with a description of the set or vocabulary as a collective whole. Once the Agent has been registered, a new vocabulary form can be invoked by clicking on the (Add) link showing after the '''Element Sets''' link on the right hand browse menu (note that the (Add) portion will not appear if the user is not logged in, and clicking on the Element Sets link will produce a link of already registered Element Sets). A basic template allowing a description of an Element Set will appear, divided into sections. In general, users should tab through the form to take best advantage of the Registry defaults.<br />
<br />
[[Image:Register property set.jpg]]<br />
<br />
'''DETAIL'''<br />
; Owner<br />
: User is provided with a drop-down list of all the agents for which the user is enabled to act. The user must choose one to be the owner of the vocabulary.<br />
; Label<br />
: The label is a human-readable descriptive label for the element set as a whole. This text will be displayed in lists of element sets and should be optimized for a human reader, preferably without combined words or camel case.<br />
<br />
'''NAMESPACE'''<br />
; Name<br />
: The user provides here unique token representing this particular element set. This will be used as the prefix identifying this URI in RDF or a qname in XML. This name should be terse and contain no spaces. Camel case is preferred.<br />
; URI<br />
: The URI assigned to this element set. By default this will be a concatenation of the Registry default domain and the element set Name. If another domain is desired for the Element Set and its individual properties, the desired namespace must be entered here manually, overriding the normal Registry default. The namespace designated here will then become the default for the registration of individual properties later on in the workflow. <br />
<br />
'''DOCUMENTATION'''<br />
; URL<br />
: A non-Registry URL that contains more information about this element set. This information is optional, but useful, if the vocabulary already has a presence on the web.<br />
; Note<br />
: A note about this element set. This is optional, and may contain any information that may be relevant to users of the vocabulary.<br />
; Tags<br />
: In this space may be entered free text tags identifying communities of practice for which this element set is intended. At present, it is not possible to use these tags to search for related vocabularies, but this functionality will be added later.<br />
<br />
'''DEFAULTS'''<br />
; Status<br />
: The drop down menu supplies a status that will serve as a default status for the properties of this element set as they are created. Once a vocabulary is registered, the statuses of individual properties must be changed individually--a change made to the vocabulary as a whole will not proliferate throughout the vocabulary. This allows each property to be maintained separately as part of a vocabulary development process.<br />
; Language<br />
: The drop down menu supplies a default language for the properties of this element set as the properties are created. When desired, individual property statements can be overridden with a non-default language, providing the capability for a multilingual property vocabulary.<br />
<br />
When the desired parts of the form are filled in, the user should click on the SAVE button at the bottom of the page.<br />
<br />
Elements will display in the order that they are entered. The display can be changed to Alphabetical or Reverse Alphabetical by clicking the 'Label' link on the blue section above the list. When the sort is changed a small arrow indicating the direction of the sort will appear.<br />
<br />
===Register Individual Properties===<br />
<br />
Once the top level vocabulary description is saved, it will appear with several tabs above the description: '''Detail''' (which displays the full description for the element vocabulary), '''Elements''' (which displays in list form all the elements in the vocabulary), '''History''' (which gives a full history of changes made), and '''Maintainers''' (which gives a full list of those approved to manage the vocabulary, and their roles). To add elements to the vocabulary, click on the '''Elements''' tab: if no elements are yet available in that vocabulary, the Registry will respond with that message, and below it will be a link to create an Element. If that link is invoked, a form will be returned:<br />
<br />
[[Image:RegisterIndividProp.jpg]]<br />
<br />
The form includes the following:<br />
<br />
; Type<br />
: A drop down menu allows the use of four types: class, subclass, property, and subproperty.<br />
; Label<br />
: This is a human-friendly label for this property and is required for every Property. The label should be optimized for human viewing and may have spaces. Combined words and camel case are not recommended.<br />
; Name<br />
: This is a machine-compatible label for this property and is required for every Property. Names should begin with lower case for properties/subproperties and upper case for classes/subclasses, and should not include spaces. Combined words and camel case ARE recommended for names.<br />
; URI<br />
: The URI is generated by the system, based on the default supplied in the vocabulary description created earlier, but it may be overridden by the user.<br />
; Description<br />
: A description of the property or class. In most cases the description should be a formal definition.<br />
; Comment<br />
: The comment may be an extension of the definition with examples of use, or a comment on the usage of the property in special cases.<br />
; Domain<br />
: Each property may be related to one or more classes by a ''has domain'' relationship. Where it is stated that a property has such a relationship with a class and the property is part of a property/value pair, it follows that the described resource is an instance of that class. (From the [[http://dublincore.org/documents/abstract-model/ Dublin Core Abstract Model]].)<br />
; Range<br />
: Each property may be related to one or more classes by a ''has range'' relationship. Where it is stated that a property has such a relationship with a class and the property is part of a property/value pair, it follows that the value is an instance of that class. [[http://dublincore.org/documents/abstract-model/ Dublin Core Abstract Model]].)<br />
; Status<br />
: This is the overall status of this Element. Individual elements of this property may have a different status.<br />
; Language<br />
: This is the default language for all statements of this element. If languages other than the default are desired for particular statements, the default language can be overridden.<br />
; Note<br />
: Notes for the application of particular statements or to reflect sources of definitions or other relevant human-readable purposes can be added here. <br />
<br />
Additional classes or properties needed for the element vocabulary can be added by repeating the process. <br />
<br />
Subclass and subproperty relationships should be added after the Classes and Properties have been completed. The Registry expects that when an element is a subclass or subproperty, the higher level is already present. When describing a subclass or subproperty, a drop down list presents all classes or properties available in the vocabulary, ensuring that only appropriate relationships are made, and that relationships are reciprocal.<br />
<br />
===Editing or Extending Existing Elements/Properties===<br />
<br />
When a set of elements/properties are initially registered, a number of maintenance actions are available to manage the vocabulary. Data can be edited (corrections, additions of text to definitions, deletions, etc.) or extended (statements added, relationships added).<br />
<br />
====Editing/Maintaining Existing Elements/Properties====<br />
<br />
Starting with a list of existing elements, either click the edit button to the right of the element, or go to the detail for the element itself by clicking on the name or URL from the list, and choosing the edit button from the bottom of the display. (If the edit button does not appear on the list or the detail display for the property, either the user is not signed in, or the user is not authorized to edit this particular element set.)<br />
<br />
<br />
[[Image:ElementList.jpg]]<br />
<br />
<br />
Once the edit screen is displayed, any visible data can be modified and any empty text boxes can be filled in. Note that when displaying the detail for a class or property, information on subclass or subproperty relationships does not display in this view and cannot be added or edited from the detail edit screen. See the instructions for Extending Existing Elements/Properties to add or edit those relationships.<br />
<br />
[[Image:ElementDetailEdit.jpg]]<br />
<br />
====Extending Existing Elements/Properties====<br />
<br />
An alternate approach to editing, which allows access to all the properties at a statement level (including subclass and subproperty relationships), starts from the list of Elements. Clicking on the element to be edited, and, when the detail is displayed, clicking on the Statements tab, provides a list of all property statements, with available actions in the right hand column.<br />
<br />
<br />
[[Image:ElementStatementDisplay.jpg]]<br />
<br />
<br />
From this view, the actions available for each statement are visible in the right hand column. Some statements can be edited, others can be deleted, and the defaults (which show no actions in the right hand column) show no actions; they must be changed using the detail edit screen shown above. At the bottom of the display, a button to invoke a form to add new statements can be clicked. This is one method available to add new hasSubproperty relationships from the property itself (the other method is to add a new 'parent' property to a subproperty). Because element properties can have multiple relationships, care should be taken to ensure that reciprocals are correct. Because existing relationships cannot be edited directly via the detail editing screen, relationships that require change must be deleted first, then added back in their changed version.<br />
<br />
[[Image:CreatingNewStatement.jpg]]<br />
<br />
<br />
Adding Property statements for elements identified as classes is more limited, because classes must have 'one-to-one' hierarchies. Therefore, the drop down list for element properties includes:<br />
<br />
* label<br />
* description<br />
* comment<br />
* subpropertyOf<br />
* note<br />
* domain<br />
* range<br />
<br />
While the drop down list for elements identified as classes includes:<br />
<br />
* label<br />
* description<br />
* comment<br />
* note<br />
<br />
==Register Concepts==<br />
<br />
See [http://wiki.metadataregistry.org/Thesaurus_Construction_Resources Vocabulary and Thesaurus Construction Resources] for general information on vocabulary development.<br />
<br />
The Open Metadata Registry uses the [[http://www.w3.org/2004/02/skos/ Simple Knowledge Organisation System (SKOS)]] as the basis for building concept vocabularies.<br />
<br />
===Register Concept Vocabularies===<br />
<br />
Building a set of concepts starts with a description of the vocabulary as a collective whole. Once the Agent has been registered, a new vocabulary form can be invoked by clicking on the (Add) link showing after the '''Vocabularies''' link on the right hand browse menu (note that the (Add) portion will not appear if the user is not logged in, and clicking on the Vocabularies link will produce a list of already registered Vocabularies). A basic template allowing a description of an Vocabulary will appear, divided into sections. In general, users should tab through the form to take best advantage of the Registry defaults.<br />
<br />
[[Image:CreateConceptVocab.jpg]]<br />
<br />
'''DETAIL'''<br />
; Owner<br />
: User is provided with a drop-down list of all the agents for which the user is enabled to act. The user must choose one to be the owner of the vocabulary.<br />
; Name<br />
: The name is a human-readable descriptive label for the element set as a whole. This text will be displayed in lists of vocabularies and should be optimized for a human reader, preferably without combined words or camel case.<br />
; URL<br />
: A non-Registry URL that contains more information about this vocabulary. This information is optional, but useful, if the vocabulary already has a presence on the web.<br />
; Note<br />
: A note about this element set. This is optional, and may contain any information that may be relevant to users of the vocabulary.<br />
; Community<br />
: In this space may be entered free text tags identifying communities of practice for which this element set is intended. At present, it is not possible to use these tags to search for related vocabularies, but this functionality will be added later.<br />
; Status<br />
: The drop down menu supplies a status that will serve as a default status for the properties of this element set as they are created. Once a vocabulary is registered, the statuses of individual properties must be changed individually--a change made to the vocabulary as a whole will not proliferate throughout the vocabulary. This allows each property to be maintained separately as part of a vocabulary development process.<br />
; Language<br />
: The drop down menu supplies a default language for the properties of this element set as the properties are created. When desired, individual property statements can be overridden with a non-default language, providing the capability for a multilingual property vocabulary.<br />
<br />
'''URI'''<br />
<br />
; Base Domain<br />
: The root of all URIs for this vocabulary and its terms. By default the Registry assigns the Registry domain, but this may be overridden by another Base Domain typed over the default by the Owner of this vocabulary.<br />
; Token<br />
: The user provides here unique token representing this particular vocabulary. This will be used as the prefix identifying this URI in RDF or a qname in XML. This name should be terse and contain no spaces. Camel case is preferred.<br />
; URI<br />
: The URI assigned to this element set. By default this will be a concatenation of the Registry default domain and the vocabulary Name. If a domain other than the Registry default is desired for the Vocabulary and its individual properties, the desired namespace must be entered here manually, overriding the normal Registry default. The URI designated here will then become the default for the registration of individual properties later on in the workflow. <br />
<br />
<br />
When the desired parts of the form are filled in, the user should click on the SAVE button at the bottom of the page.<br />
<br />
[[Image:CreatedConceptVocab.jpg]]<br />
<br />
===Register Individual Concepts===<br />
<br />
Once the top level vocabulary description is saved, it will appear with several tabs above the description: '''Detail''' (which displays the full description for the concept vocabulary), '''Concepts''' (which displays in list form all the concepts in the vocabulary), '''History''' (which gives a full history of changes made), '''Versions''' (which links to any defined versions of the vocabulary), and '''Maintainers''' (which gives a full list of those approved to manage the vocabulary, and their roles). To add Concepts to the vocabulary, click on the '''Concepts''' tab: if no elements are yet available in that vocabulary, the Registry will respond with that message, and below it will be a link to create an Element. If that link is invoked, a form will be returned:<br />
<br />
[[Image:CreatingNewConcept.jpg]]<br />
<br />
The form includes the following:<br />
<br />
; Preferred Label<br />
: This is the SKOS:prefLabel property of this Concept and is required for every Concept. This is intended to be a human-friendly label for this property and should be optimized for human viewing--it may have spaces. Combined words and camel case are not recommended.<br />
; URI<br />
: The URI is generated by the system, based on the default supplied in the vocabulary description created earlier, using a sequential number assigned by the the system to create a unique URI. Owners who prefer a non-numeric extension may override the default by typing in their preferred name.<br />
; Top Concept?<br />
: A check box is provided to allow identification of concepts at the top of a hierarchy of relationships.<br />
; Status<br />
: This is the overall status of this Concept. Individual concepts in this property may have different statuses.<br />
; Language<br />
: This is the default language for all concepts of this vocabulary, which will be extended to each concept. If a language other than the default are desired for particular concepts, the default language can be overridden by editing the Language at the statement level.<br />
<br />
Additional concepts needed for the vocabulary can be added by repeating the process. <br />
<br />
Relationships between concepts should be added after the initial registration of concepts themselves have been completed. The Registry expects that when a relationship is asserted, that both levels are already present. When building a relationships between concepts, a drop down list presents all concepts available in the vocabulary, ensuring that only appropriate relationships are made, and ensures that relationships are reciprocal.<br />
<br />
===Editing or Extending Existing Concepts===<br />
<br />
When a set of concepts are initially registered, a number of maintenance actions are available to manage the vocabulary. Data can be edited (corrections, additions of text to definitions, deletions, etc.) or extended (statements added, relationships added).<br />
<br />
Starting with a list of existing concepts, either click the edit button to the right of the concept, or go to the detail for the concept itself by clicking on the name or URL from the list.<br />
<br />
<br />
[[Image:ConceptList.jpg]]<br />
<br />
<br />
Choose the edit symbol from the actions list to the right of the concept to be edited, or select the concept itself to display, and click on the edit button from the bottom of the display. Both these actions allow the Detail block of properties to be edited. (If the edit button does not appear on the list or the detail display for the property, either the user is not signed in, or the user is not authorized to edit this particular element set.)<br />
<br />
[[Image:EditConcept.jpg]]<br />
<br />
<br />
Once the edit screen for the concept is displayed, any visible data in the Detail section can be modified and any empty text boxes can be filled in. <br />
<br />
[[Image:EditConcept2.jpg]]<br />
<br />
<br />
To edit the additional properties below the Detail box, either click on the edit button that appears to the right of the property, or choose the Properties tab and either click the edit symbol to the right of the property to be edited or select the display for that property to select the edit button under the display.<br />
<br />
<br />
[[Image:EditConcept3.jpg]]<br />
<br />
<br />
[[Image:EditConcept4.jpg]]<br />
<br />
Both these strategies present an "Add Property" button so that additional properties can be added as well as existing properties edited.<br />
<br />
==History and Versioning==<br />
<br />
==Registry Output==<br />
<br />
===RDF===<br />
<br />
===XML===<br />
<br />
===SPARQL Queries===<br />
<br />
The registry features a SPARQL endpoint, allowing queries of registered vocabularies and element sets. For an introduction to SPARQL and instructions for using the endpoint, read the [[SPARQL Endpoint|SPARQL]] page on this wiki.</div>Dianehttp://wiki.metadataregistry.org/Open_Metadata_RegistryOpen Metadata Registry2010-09-09T20:56:10Z<p>Diane: </p>
<hr />
<div>The [[http://metadataregistry.org Open Metadata Registry]] is the newly relaunched NSDL Metadata Registry.<br />
<br />
==Registry Redevelopment, 2010-2011==<br />
<br />
===Use and Business Cases===<br />
<br />
===Functional Requirements===<br />
<br />
===User Documentation===<br />
<br />
* [[Getting Started]] with the Registry<br />
<br />
* NSDL Registry [[Step-By-Step Instruction]] (Deprecated)<br />
<br />
* [[Open Metadata Registry Step-By-Step Instruction]]</div>Dianehttp://wiki.metadataregistry.org/Planning_an_ImplementationPlanning an Implementation2010-09-07T21:18:25Z<p>TomJohnson: Created page; added Diane's list of 'decisions'</p>
<hr />
<div></div>TomJohnsonhttp://wiki.metadataregistry.org/Example_WorkflowsExample Workflows2010-09-07T19:50:14Z<p>TomJohnson: Some more headers.</p>
<hr />
<div><br />
==A Simple, Single-User Workflow==<br />
<br />
<br />
==A Multi-User Workflow==<br />
<br />
<br />
==With Integrated Approval Cycle==<br />
[[Image:wkflow-with-approval.jpg|500px]]</div>TomJohnsonhttp://wiki.metadataregistry.org/Getting_StartedGetting Started2010-03-27T21:52:00Z<p>TomJohnson: /* Training Screencasts */</p>
<hr />
<div></div>TomJohnsonhttp://wiki.metadataregistry.org/Integration_with_RDA_OnlineIntegration with RDA Online2009-02-02T20:25:21Z<p>Diane: </p>
<hr />
<div>== Integration with RDA Online ==<br />
<br />
==== Application Profiles and RDA Online "workflows": are they interchangeable? ====<br />
<br />
'''Key aspects of Application Profiles:'''<br />
<br />
* Specific information on properties used, including URIs for each<br />
* Requires a model of some kind to support relationships?<br />
* Cardinality for each property<br />
* Usage specifications for each property, including controlled vocabularies to be applied<br />
* Registry will provide XML Schema for APs, to support record creation and validation?<br />
* Questions:<br />
** Will Registry be able to import Workflows as simple APs?<br />
<br />
'''Key aspects of RDA Workflows:'''<br />
<br />
* Allows selection of appropriate properties (question about whether FRBR relationships can be chosen as well? Or is there an assumption that the WEMI relationships are included as part of the property definition?)<br />
* Can be expressed in an XML schema, to support record creation and validation? What kind of XML schema is proposed?<br />
* Questions:<br />
** Do workflows include selection of controlled vocabularies, cardinality? <br />
** Do workflows carry information on the rules used? If so, how?<br />
** Will RDA Online support versioning of workflows? If so, will the registry support re-import?<br />
** Will RDA Online support human-readable descriptions of workflows, attribution/authorship, etc.?</div>Dianehttp://wiki.metadataregistry.org/Multi-lingual_vocabulariesMulti-lingual vocabularies2009-01-15T23:29:42Z<p>Jon: New page: == Multi-lingual vocabularies == We intend to support two types of multi-lingual vocabularies: * Single vocabularies with multi-lingual editing support and language-specific filters * Se...</p>
<hr />
<div>== Multi-lingual vocabularies ==<br />
<br />
We intend to support two types of multi-lingual vocabularies:<br />
<br />
* Single vocabularies with multi-lingual editing support and language-specific filters<br />
* Separate vocabularies, linked at the vocabulary level and mapped at the concept level<br />
<br />
Note that unless otherwise stated, when we say 'concept' we include schema properties and classes<br />
<br />
=== Single vocabularies ===<br />
<br />
We'll enable this first...<br />
<br />
* All languages would be represented in a single vocabulary<br />
* A language-specific representation of the vocabulary would be retrieved either through content-negotiation to determine the correct language to serve or by appending the appropriate language code, as defined in [http://www.rfc-editor.org/rfc/rfc4646.txt rfc4646] to the URI: <br />
All languages -- http://metadataregistry.org/uri/NSDLEdLvl/1001 <br />
English-US -- http://metadataregistry.org/uri/NSDLEdLvl/1001/en-US<br />
German-Swiss -- http://metadataregistry.org/uri/NSDLEdLvl/1001/de-CH<br />
English-US, with timeslice -- http://metadataregistry.org/uri/NSDLEdLvl/1001/en-US/ts/20080215221818<br />
* When a user registers with the registry, she will have the opportunity to select a default language to restrict viewing of vocabularies. This will default to no selection, which will display all available languages.<br />
* If a user selects a default viewing language, all lists, labels, definitions will be displayed in her default language. A selector will be provided to allow her to see the displayed data in the other available languages.<br />
* When a user is added to a vocabulary as a maintainer, she will have the opportunity to select a default language for editing that vocabulary. She may select other languages while editing, but the UI will always default to her selected language. This will be vocabulary-specific so she may have different defaults for different vocabularies.<br />
* We'll provide an interface that will show the user a matrix of all of the concepts in all of the languages in order to provide a quick check of missing properties in any language.<br />
<br />
=== Separate vocabularies ===<br />
<br />
* Each vocabulary would be language-specific.<br />
* After the first vocabulary had been entered, subsequent vocabularies would be linked to it when they are created<br />
* The user interface would be similar to the current UI, but each concept in a linked vocabulary would provide a selector to choose a related concept in the linked vocabulary (optional)<br />
* If a related concept was chosen by the user, a mapping statement would be created in each vocabulary to link the concepts together. We may use [http://www.w3.org/TR/skos-primer/#secmapping SKOS mappings] for this or create registry-specific mapping subproperties of them<br />
* Each vocabulary and its related concepts would have unique URIs<br />
<br />
The downside of this approach (to us at least) is the essentially stand-alone nature of the vocabularies. It makes management and maintenance much more difficult and presents challenges keeping the vocabularies in sync. The upside is that maintenance of each language can proceed independently.<br />
<br />
We're not recommending this approach for most vocabularies.</div>Jonhttp://wiki.metadataregistry.org/Inter-registry_functional_requirementsInter-registry functional requirements2008-08-27T16:13:39Z<p>Diane: New page: === Functional Requirements for Interactions Between Registries === [http://wiki.metadataregistry.org/DCMI_Registry_Community Back to Registry Community Front Page] This page is in some ...</p>
<hr />
<div>=== Functional Requirements for Interactions Between Registries ===<br />
<br />
[http://wiki.metadataregistry.org/DCMI_Registry_Community Back to Registry Community Front Page]<br />
<br />
This page is in some sense the "product" of our work, but should be considered a "work in progress" or "whiteboard," including our ideas of what functionality we envision and might consider supporting as we move towards a more distributed registry environment.<br />
<br />
==== Requirements for machine-based interactions between registries ====<br />
<br />
<br />
==== Requirements for human interactions between registries ====<br />
<br />
<br />
==== "Boundary" issues ====<br />
<br />
---------<br />
[http://wiki.metadataregistry.org/DCMI_Registry_Community Back to Registry Community Front Page]</div>Dianehttp://wiki.metadataregistry.org/Inter-registry_use_casesInter-registry use cases2008-08-27T16:04:46Z<p>Diane: /* NSDL Registry */</p>
<hr />
<div>=== Use Cases for Interactions Between Registries ===<br />
<br />
[http://wiki.metadataregistry.org/DCMI_Registry_Community Back to Registry Community Front Page]<br />
<br />
This page includes use cases (interpreted loosely) of the kinds of things registry projects see as helpful or essential in terms of interactions between their efforts and those of others. <br />
<br />
----------------<br />
<br />
===== NSDL Registry =====<br />
<br />
''External Service Interactions''<br />
<br />
#Possible external service relationships, with interactions:<br />
#*With other Registries:<br />
#**'Slurp' vocabulary terms for display (but not updating); may be accomplished via web services or harvesting, scheduled or on-demand<br />
#**'Metasearch'-style federated search of other registry data, for discovery, display, linking, etc. May include some interactions to enable other registries to note 'usage' of vocabularies by NSDL Registry users or relationships between vocabularies held in separate registries<br />
#*With Organizations:<br />
#**Harvest or 'slurp' appropriately encoded vocabularies from non-Registry systems held by Organizations. These interactions can be scheduled, manual on-demand, or initiated by the Organization based on their update transactions<br />
#**Notification of transactions on Organization-owned vocabularies<br />
#**Notification of use of Organization-owned vocabularies by external users, primarily via registration of Application Profiles<br />
<br />
[http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#External_Service_Interactions Link to Documentation]<br />
<br />
---------<br />
[http://wiki.metadataregistry.org/DCMI_Registry_Community Back to Registry Community Front Page]</div>Dianehttp://wiki.metadataregistry.org/Registry_ViewpointsRegistry Viewpoints2008-08-21T22:45:31Z<p>Diane: /* Definitions and viewpoints */</p>
<hr />
<div></div>Emmahttp://wiki.metadataregistry.org/Common_requirementsCommon requirements2008-08-21T21:10:31Z<p>Diane: /* Use Cases */</p>
<hr />
<div>== DCMI Registry Task Group ==<br />
<br />
------------------------<br />
Back to [http://wiki.metadataregistry.org/DCMI_Registry_Community#DCMI_Registry_Task_Group DCMI Registry Community Main Page]<br />
--------------------------<br />
<br />
'''GOAL:''' Develop a set of functional requirements common to current registries, based on the experience and findings of current registry implementers and stakeholders. As part of this, investigate the dissemination functionality considered desirable in a registry, and appropriate use cases associated with this functionality.<br />
<br />
=== Requirements ===<br />
<br />
==== Requirements Relating to Search & Discovery ====<br />
<br />
===== NSDL Registry =====<br />
<br />
#External users should be able to:<br />
#*Search the Registry to discover:<br />
#**Schemas, including those available in associated registries (<i>Description</i>)<br />
#**Relationships between schema elements in available schemas&#8212;intra-schema relationships (<i>Resource</i>)<br />
#***Relationships between the term of interest and other terms are a function of contextual browse<br />
#**Available vocabularies, based on topical coverage, owning organization and purpose (<i>Description</i>)<br />
#**Vocabulary terms: by preferred term, broader/narrower relationships&#8212;inter-schema relationships (<i>Resource</i>)<br />
#***Relationships between the term of interest and other terms are a function of contextual browse<br />
#**Keyword searches on concept and element description texts (<i>Resource</i>)<br />
#*Searches should be filterable by:<br />
#**Organization<br />
#**Status<br />
#**Usage<br />
#Search result display options should include:<br />
#*WordNet style tree display, with links<br />
#*Browse result set in visually oriented display (Naomi's browse?)<br />
#*Rank order by usage<br />
<br />
[http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#External_User_Interactions Link to Documentation]<br />
<br />
==== Requirements Relating to Data Entry ====<br />
<br />
===== NSDL Registry =====<br />
<br />
<b>Submitting, Creating and Editing Schemas, Schemes and Application Profiles</b><br />
<br />
#Add Organization description<br />
#Edit/Update Organization description<br />
#Deprecate Organization description<br />
#Add Element Set, Vocabulary or Application Profile description<br />
#Upload or Create elements, terms or AP specifications<br />
#*If element descriptions, vocabularies, or APs were created in an external tool, and available in approved XML schema, uploaded the set of elements into the registry [Note: Uploaded descriptions subject to validation.]<br />
#Edit/Update Element Set, Vocabulary or AP description<br />
#Deprecate Element Set, Vocabulary or AP description<br />
<br />
[http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#Requirements_for_User_Functions_and_Interfaces Link to Documentation]<br />
<br />
==== Requirements Relating to Versioning and History ====<br />
<br />
===== NSDL Registry =====<br />
<br />
General Assumptions on Versioning<br />
<br />
# URIs will remain stable so long as the semantics of the term do not change<br />
# URIs of individual term values won't contain version information<br />
# The Registry must be able to allow people/services to create dependencies on a 'versioned' snapshot of a particular SKOS/OWL representation of a vocabulary and it's relationships<br />
# A 'versioned snapshot' must include the version designation (either 'number' or 'date')<br />
# Individual values in a vocabulary may be created, updated, or deprecated, but not deleted<br />
# Namespaces of vocabulary schemas won't be versioned<br />
# Schema name versioning will only change if the version change would break backward compatibility<br />
<br />
Versioning has been implemented in the NSDL Registry, see Jon Phipps' Registry Blog post for [http://metadataregistry.org/blog/2008/03/26/timeslices-and-versions/ details].<br />
<br />
[http://wiki.metadataregistry.org/Versioning Link to Documentation]<br />
<br />
==== Requirements Relating to Authentication and User Management ====<br />
<br />
===== NSDL Registry =====<br />
<br />
Although [http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#User_Registration_and_Authentication planning documentation] for the current NSDL Registry User Management is available, these functions are being re-thought at the present time.<br />
<br />
-----------<br />
<br />
==== Requirements Relating to Services ====<br />
<br />
===== NSDL Registry =====<br />
<br />
The NSDL Registry services plan is described fully in this [http://hdl.handle.net/1813/9373 paper], from DC-2006. Basically services are aimed at Vocabulary Owners (management of vocabularies, schemas and APs), and users of various kinds (search, notification, URL resolution, etc). <br />
<br />
-------------------<br />
<br />
=== Use Cases ===<br />
<br />
===Use cases===<br />
<br />
"Two main ways to use a vocabulary: 1) Visible to the user. Can be browsed to find suitable search terms. 2) Behind the scenes: non-preferred terms mapped to preferred terms or synonyms expanded ... can include expansion to broader and narrower terms, or translated terms." -- Mike Taylor on the [http://www.slideshare.net/cetismdrsig/becta-vms Becta VMS]<br/><br/> <br />
<br />
"The services offered by a metadata schema registry may cover many different functions, and different metadata schema registries may provide different sets of functions depending on their purpose, scope and context; those functions might include:<br />
1. Disclosure/discovery of information about metadata terms<br />
2. Disclosure/discovery of relationships between metadata terms<br />
3. Mapping or inferencing services based on relationships between terms<br />
4. Verification of the provenance or status of metadata terms<br />
5. Disclosure/discovery of related resources (such as functional aggregations of terms, guidelines for use, bindings for metadata instances, etc)" -- [http://www.ariadne.ac.uk/issue43/johnston/ Pete Johnston] <br/> <br/><br />
<br />
==== General Use Cases ====<br />
<br />
Many general use cases are available on the [http://www.w3.org/TR/skos-ucr/ SKOS Use Cases and Requirements] page. <br />
<br />
==== Use Cases Relating to Search & Discovery ====<br />
<br />
<br />
==== Use Cases Relating to Data Entry ====<br />
<br />
===== NSDL Registry =====<br />
<br />
The NSDL Registry has a number of use cases defined for entering data for Vocabularies, Schemas, and APs. The [http://wiki.metadataregistry.org/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29 Vocabularies use cases] include the following: <br />
<br />
* 1.1 Use Case 1: A Visitor wishes to register an Organization<br />
* 1.2 Use Case 2: Maintainer Enters a Full Vocabulary Description<br />
* 1.3 Use Case 2a: Maintainer Enters a Description of a Top-Level Vocabulary Only<br />
* 1.4 Use Case 3: Maintainer Registers Terms with a Vocabulary<br />
* 1.5 Use Case 4: Maintainer Uploads Vocabulary Terms to the Registry<br />
* 1.6 Use Case 4a: Maintainer Uploads non-Hosted Vocabulary Terms to the Registry<br />
* 1.7 Use Case 5: Maintainer Adds Information to Registered Term<br />
* 1.8 Use Case 6: Maintainer Changes Semantics of Term<br />
* 1.9 Use Case 7: Maintainer Changes Status of Term<br />
* 1.10 Use Case 8: User registers as a Maintainer associated with a Vocabulary<br />
<br />
These are very specific and were created for the purpose of developing the NSDL Registry software.<br />
<br />
---------- <br />
<br />
<br />
==== Use Cases Relating to Versioning and History ====<br />
<br />
<br />
==== Use Cases Relating to Authentication and User Management ====<br />
<br />
<br />
==== Use Cases Relating to Services ====<br />
<br />
<br />
--------------<br />
<br />
Back to [http://wiki.metadataregistry.org/DCMI_Registry_Community#DCMI_Registry_Task_Group DCMI Registry Community Main Page]</div>Dianehttp://wiki.metadataregistry.org/Registry_listRegistry list2008-05-29T12:31:18Z<p>Emma: </p>
<hr />
<div>{{Dcbox <br />
}}<br />
<br />
===Registries===<br />
<br />
====Purpose of this page====<br />
<br />
This page contains a list of "registry-like" developments that may arguably be considered metadata schema, terminology or ontology registries. Please add to it according to the guidelines described below.<br />
<br />
====Guidelines====<br />
<br />
At minimum, put the name of the planned development/a little descriptive text and if possible a link to further information. Other information that you may wish to add (the organisation behind the development, for example) is welcome. Any information such as project reports that might help to describe the capabilities and intended uses of software, or the perceived nature of the problem that the project intends to solve, is particularly useful. <br />
<br />
=====Software=====<br />
<br />
Becta Vocabulary Management Service<br/><br />
Introduction: http://www.slideshare.net/cetismdrsig/becta-vms<br/><br />
Standards used: Public(?) interface using [http://zthes.z3950.org | Zthes] over SRU ('REST-like'). <br />
<br />
DCMI Registry<br/><br />
The Dublin Core Metadata Initiative's (DCMI) Metadata Registry is designed to promote the discovery and reuse of exiting metadata definitions. It provides users, and applications, with an authoritative source of information about the Dublin Core element set and related vocabularies. This simplifies the discovery of terms and related definitions, and illustrates the relationship between terms.<br/><br />
Description: http://jodi.tamu.edu/Articles/v06/i02/Wagner/DCMI-Registry-final.pdf<br/><br />
http://purl.org/dcregistry/<br />
<br />
DART Metadata Schema Registry<br /><br />
For the purposes of this project, a metadata schema registry is defined as an online electronic repository of schema or application profiles that describe the structure and/or semantics of scientific data for recording and exchange. These registries can be used by researchers to format scientific data sets to improve interoperability and ensure that data can be easily disseminated to researchers within their discipline.<br/><br />
http://www.itee.uq.edu.au/~eresearch/projects/dart/outcomes/metadataschemareg.php<br/><br />
The DART software can be downloaded from: <br/><br />
http://www.itee.uq.edu.au/~eresearch/projects/dart/outcomes/installdmsr.php<br />
<br />
Global Digital Format Registry<br/><br />
http://hul.harvard.edu/gdfr/ <br/><br />
Papers on the topic:<br/><br />
http://www.ifla.org/IV/ifla69/papers/128e-Abrams_Seaman.pdf <br/><br />
http://hul.harvard.edu/gdfr/news/Workshop-2003-03-26.rtf (Minutes, some interesting discussion)<br/><br />
http://muse.jhu.edu/demo/library_trends/v054/54.1abrams.html - includes a useful set of use cases: <br/> <br />
* Identification: "I have a content stream; what format is it?"<br />
* Validation: "I have a content stream that purports to be of format F; is it?"<br />
* Characterization: "I have a formatted content stream of format F; what are its significant properties?"<br />
* Processing: "I have a formatted content stream; how can I transform (or edit, sample, compress, de-skew, render, etc.) it?"<br />
* Risk assessment: "I have a formatted content stream; is it at risk of obsolescence?"<br />
<br/><br />
<br />
HILT, the high level thesaurus project<br/><br />
Problems relating to disparate terminology use have been an impediment to information retrieval for many years, but the growth of Web, associated heterogeneous digital repositories, and the need for distributed cross-searching within multi-scheme information environments has recently drawn the issue into sharp focus. The HILT project, which is now in phase IV, aims to research, investigate and develop pilot solutions for problems pertaining to cross-searching multi-subject scheme information environments, as well as providing a variety of other terminological searching aids.<br/><br />
http://hilt.cdlr.strath.ac.uk/<br />
<br />
IESR<br /><br />
Information Environment Service Registry<br /><br />
http://iesr.ac.uk/<br />
<br />
IEMSR<br /><br />
Information Environment Metadata Schema Registry<br /><br />
http://www.ukoln.ac.uk/projects/iemsr/<br />
<br />
myOntology<br /><br />
A prototype platform for collaborative ontology engineering<br /><br />
http://lists.w3.org/Archives/Public/semantic-web/2008Jul/0101.html<br />
<br />
Museumsvokabular<br/><br />
http://museum.zib.de/museumsvokabular/<br />
<br />
NHS metadata registry<br/><br />
"The National Knowledge Service Metadata Registry (NKS-MDR) is designed to promote the discovery and reuse of metadata and vocabulary definitions that will be used within the National Knowledge Service and the National Library for Health." <br/><br />
http://schemas.library.nhs.uk/<br />
<br />
Open Ontology Repository<br /><br />
Press release describing a planned Open Ontology Repository<br/><br />
http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008_Communique<br />
<br />
PRONOM<br/><br />
"PRONOM is a web-based technical registry to support digital preservation services, developed by The National Archives of the United Kingdom." - It contains file formats.<br/><br />
http://en.wikipedia.org/wiki/PRONOM_technical_registry<br />
<br />
Scottish Enterprise Standards Registry<br/><br />
The home of all Scottish Enterprise Information Standards - includes metadata regitry functionality but is also much wider <br/><br />
http://schemas.scottish-enterprise.com/<br />
Contact is Mandy.Bell@scotent.co.uk <br/><br />
<br />
=====Reports/Documentation =====<br />
<br />
JISC Pedagogical Vocabularies Project<br /><br />
An inventory of existing pedagogical vocabularies - demonstrates that there is a perceived need to inventory these resources.<br /><br />
http://www.jisc.ac.uk/elp_vocabularies.html<br />
<br />
MDA Terminology Bank<br/><br />
Terminology bank containing vocabularies of relevance to cultural heritage<br/><br />
http://www.mda.org.uk/spectrum-terminology/termbank<br />
<br />
The European Library Metadata Registry<br/><br />
This site provides terms, crosswalks, guidance for the user about metadata creation and use...<br/><br />
http://www.theeuropeanlibrary.org/handbook/mdregistry.php<br/><br />
<br />
=====Commercial=====<br />
Factiva/Taxonomy Warehouse<br /><br />
"the only site on the Internet dedicated to taxonomies for corporations".<br /><br />
http://www.taxonomywarehouse.com/<br />
<br />
<br />
<br />
==== 'Sandbox' - A list of as yet unclassified names and vague notes ====<br />
<br />
Half-formed thoughts and vague leads go here.<br />
<br />
<pre><br />
> > <br />
> ><br />
> > TASI<br />
> ><br />
> > Species 2000<br />
> ><br />
> > Text Mining Centre - biomedical ontologies<br />
> ><br />
> > Middletons controlled vocabulary list<br />
> ><br />
> > Univ of British Columbia Indexing Resources<br />
> ><br />
> > Dexter Clarkes review of taxonomies in the public sector<br />
> ><br />
> > Univ of Toronto Subject Analysis Systems collection<br />
> ><br />
> ><br />
> > Ockham<br />
> ><br />
> > Grimoires<br />
> ><br />
> > Metadata Swtich Project OCLC<br />
> ><br />
> ><br />
> > Talis, Ex Libris: commercial, bibliographic services<br />
> ><br />
> ><br />
> > DCC registry for curating experimental data sets<br />
> ><br />
> > Inscription<br />
> ><br />
> > WordHoard<br />
> ><br />
> > OCLC terminology services<br />
> ><br />
> > OCLC Name Authority Service for Dspace<br />
> ><br />
> > LAF (LC Name Authority File)<br />
> ><br />
> > CalEDLN<br />
> ><br />
> > MelvilSoap<br />
</pre></div>Emmahttp://wiki.metadataregistry.org/DCMI_Registry_CommunityDCMI Registry Community2008-05-19T01:37:08Z<p>CoreyHarper: /* DCMI Registry Task Group */</p>
<hr />
<div>{{Dcbox <br />
}}<br />
<br />
==DCMI Registry Community/Task Group meeting 2010==<br />
<br />
At the upcoming Dublin Core conference DC-2010, to be held 20-22 October 2010 in Pittsburgh, there will be a meeting of the DCMI Registry Community and Task Group.<br />
<br />
The meeting will take place on Wednesday 20 October, 9:00am-12:30pm.<br />
<br />
Agenda:<br />
<br />
This meeting is intended to be accessible to all, including those who have not previously attended DCMI events. The schedule below is provisional. If you would like to propose additional items for the meeting, please contact the organisers. We will send out an updated schedule nearer to the time.<br />
<br />
# Short status reports relating to ongoing activity in the registry area.<br />
# Presentation and discussion: Registries in a Linked Data context.<br />
# Landscape review: the distributed registry -- Diane Hillmann.<br />
# Further items TBC<br />
<br />
If you have any immediate questions about the meeting, please contact Emma Tonkin (e.tonkin@ukoln.ac.uk) or Diane Hillmann (metadata.maven@gmail.com).<br />
<br />
[[Registry Meeting Notes, DC-2010]]<br />
<br />
==DCMI Registry Community Projects==<br />
<br />
===DCMI Registry Task Group===<br />
<br />
'''Preamble:'''<br />
<br />
There are now many metadata registry projects in existence, under the aegis of groups such as the DCMI, TEL, NSDL, DART, and UKOLN, each of which has explored various aspects of registry development and use. Partially as a result of this work, there is renewed interest in learning from existing registry developments, and moving some aspects of the work forward together. For example, projects such as the Terminology Registry Scoping Study (TRSS) [http://www.ukoln.ac.uk/projects/trss/] aim to gain an overview of existing developments in this area and define common interests. It is felt that the DCMI Registry community is an important forum for this discussion.<br />
<br />
This work is primarily designed to support knowledge sharing between initiatives with an interest in metadata schema registry work, and to address communication between established registries. This work focuses on metadata schema, vocabulary, and terminology registries.<br />
<br />
[[Registry Viewpoints]]<br />
<br />
'''Goals:'''<br />
<br />
The DCMI Registry Task Group will:<br />
<br />
*Develop a set of functional requirements common to current registries, based on the experience and findings of current registry implementers and stakeholders. As part of this, investigate the dissemination functionality considered desirable in a registry, and appropriate use cases associated with this functionality; [[common requirements]]<br />
*Draft a set of use cases for inter-registry interactions, taking into consideration interoperability concerns (reporting, notification, versioning, etc.) between registries and other applications sharing related goals; [[inter-registry use cases]]<br />
*Draft a set of functional requirements related to the inter-registry transfer language or languages, including interoperability concerns related to sharing information between registries and with other applications such as vocabulary management applications that share related aims. [[inter-registry functional requirements]]<br />
<br />
'''Workplan:'''<br />
<br />
#March-April 2008: Recruit/select Task Group members<br />
#April 2008: Review existing Registry documentation<br />
#May-July 2008: Data collection regarding use cases, first draft of functional requirements.<br />
#Late Summer 2008(DC/ECDL/NKOS): Reporting back with findings, and gathering comments from implementers. At DC-2008 determine dissemination and publication of findings and recommendations, or further activity required prior to publication. Consultation with possible standards bodies will be explored as well.<br />
<br />
Reports on TG activities and findings will be presented to the community via the Registry Community Wiki at the end of each phase of activity. Full discussion of the work and its further development will be planned for the DC-2008 meeting of the Community.<br />
<br />
'''Current status: (Winter 2009)'''<br />
<br />
Corey Harper is working with us on the Registry Task Group work, and has<br />
recently completed a survey of the area, which he is now writing up into<br />
a report. We have also made good progress on the specific subject of interoperability,<br />
having successfully implemented a 'rough and ready' three-way transform<br />
between DCMI Registry, NSDL Registry and IEMSR RDF formats. <br />
<br />
In the next period we hope to look at the practical proposals that have<br />
been brought up both by the recent survey and by participants at the<br />
York event (http://www.ukoln.ac.uk/events/rcw-2009/), in order to use<br />
them as use cases for practical development based on the work that has<br />
recently been completed.<br />
<br />
<div id="2011"></div><br />
'''2011 Workplan:'''<br />
<br />
The following work plan for the DCMI Registries Task Group is based on discussions at the DC2010 meeting in Pittsburgh as well as other conversations.<br />
<br />
#December-February: Complete report from survey of Registry developers, administrators and end users (Corey). Versions of report to be prepared for both publication and posting on JISC/DCMI Web Sites.<br />
#January-April: Review current Use Case and Functional Requirements documents. [1,2,3] Invite discussion on Task Group and Community Lists as to how to move these documents forward. Consider separating general functional requirements and use cases from documents specific to NSDL Registry (now Open Metadata Registry). Instead, focus on general functional requirements as determined in survey results and DC2010 face-to-face meeting in Pittsburgh. [4] Additionally, identify most desirable inter-registry interoperability functions such as automatic cross-registry updates and metadata schema / value vocabulary harvesting (Corey, Diane, Emma, Jon).<br />
#March-July: Begin planning for test implementations of inter-registry interoperability functionality. Initially, focus testing on interoperability between the Open Metadata Registry and the JISC IEMSR. As work wraps up on the Metadata Information Infrastructure Project at Infocom and University of Tsukuba, extend testing to Dublin Core Registry and Japanese Metadata Infrastructure Project Registry (Corey, Emma, Jon, Mitsuharu). Most pre-DC2011 work will be test planning, with testing continuing into 2012.<br />
#August-September: Before DC2011, invite additional participants to interoperability testing through follow-up with Survey Respondents and via Community & Task Group listserves.<br />
<br />
Two to three conference calls should be held in the spring for planning and assessment of tasks 2 and 3.<br />
<br />
[1]http://wiki.metadataregistry.org/Inter-registry_use_cases<br /><br />
[2]http://wiki.metadataregistry.org/Common_requirements<br /><br />
[3]http://wiki.metadataregistry.org/Inter-registry_functional_requirements<br /><br />
[4]http://wiki.metadataregistry.org/Registry_Meeting_Notes%2C_DC-2010<br /><br />
<br />
'''Chairs:''' [mailto:e.tonkin@ukoln.ac.uk Emma Tonkin] and [mailto:metadata.maven@gmail.com Diane Hillmann].<br />
<br />
'''Members: '''<br />
<br />
[mailto:Adrian.Dale@creatifica.com Adrian Dale] of Creatifica <br /><br />
[mailto:C.Frodl@d-nb.de Christine Frodl] of the Deutsche Nationalbibliothek<br /><br />
[mailto:nagamori@slis.tsukuba.ac.jp Mitsuharu Nagamori] of the University of Tsukuba<br /><br />
[mailto:andrew.kitchen@becta.org.uk Andrew Kitchen] on behalf of BECTA<br /><br />
[mailto:kg249@ukoln.ac.uk Kora Golub] / [mailto:dstudhope@glam.ac.uk Doug Tudhope] of the TRSS project<br /><br />
[mailto:Sally.Chambers@KB.nl Sally Chambers] of the KB/The European Library<br /><br />
[mailto:jane@itee.uq.edu.au Jane Hunter] of the University of Queensland<br /><br />
[mailto:ian.mckinnell@institute.nhs.uk Ian McKinnell] of the NHS<br /><br />
<br />
<br />
'''Working pages'''<br />
<br />
[[Registry list]] - A list of developments that may arguably be considered metadata schema, terminology or ontology registries</div>Dianehttp://wiki.metadataregistry.org/Registry/GEM_Exchange/GEM_Subject_Vocabulary/ArtsRegistry/GEM Exchange/GEM Subject Vocabulary/Arts2008-01-18T20:17:08Z<p>Jon: New page: ==== Notes for Registry Pages ==== * [http://metadataregistry.org/concept/show/id/188.html Registry HTML] * [http://metadataregistry.org/concept/show/id/188.rdf Registry RDF] ==== Notes =...</p>
<hr />
<div>==== Notes for Registry Pages ====<br />
* [http://metadataregistry.org/concept/show/id/188.html Registry HTML]<br />
* [http://metadataregistry.org/concept/show/id/188.rdf Registry RDF]<br />
<br />
==== Notes ====</div>Jonhttp://wiki.metadataregistry.org/Dec._17,_2007Dec. 17, 20072007-12-17T15:38:31Z<p>Diane: </p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/HUB_Use_CasesHUB Use Cases2007-12-12T22:44:31Z<p>Diane: /* XC HUB Use Cases */</p>
<hr />
<div>==== This page is no longer available ====</div>Dianehttp://wiki.metadataregistry.org/Archive_PageArchive Page2007-12-12T13:36:53Z<p>Diane: /* XC Planning Archive Page */</p>
<hr />
<div>==== This page is no longer available ====</div>Dianehttp://wiki.metadataregistry.org/Dec._10,_2007Dec. 10, 20072007-12-10T15:29:48Z<p>Diane: </p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/Nov._26,_2007Nov. 26, 20072007-11-20T18:59:19Z<p>Diane: /* Telecon Agenda & Notes, Monday, Nov. 26, 2007 */</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/Nov._12,_2007Nov. 12, 20072007-11-11T15:34:38Z<p>Diane: /* Telecon Agenda & Notes, Monday, Nov. 12, 2007 */</p>
<hr />
<div>=== Telecon Agenda & Notes, Monday, Nov. 12, 2007 ===<br />
<br />
#News from the NSDL Annual Meeting (Jon & Stuart)<br />
#*Jon talked to Dean K. and reported that they were getting bridge funding until the solicitation for continuing funding is out. The Asst. Dir. for Education for NSF did one of the programs, and said that they had a TF evaluating "next steps" for the NSF digital library activities. She thought initially that this would be a small focused TF, but the Cyberinfrastructure people came in on the TF, and things got complicated. They still are working on a charge for this group. [Jon will continue these notes.] <br />
#*DLESE is defunct, and it's not clear what will continue of their work. Jon sat with some of the people working on their continuing standards efforts and passed on some of what he heard about their ASN criticisms. Queries return the path up from that leaf, but not down (partly so that others could not reconstruct the entire database). Discussion indicated that there apparently seemed to be much continuing misunderstanding of ASN and its goals. Jon reported that the projects were complaining about having to download all the data, but Stuart reported that they all wanted to do it despite ASN's concerns.<br />
#*There's now a new cataloging system based on DLESE's cataloging tool, replacing the Collection Registration System, but has been completely rewritten, using the NSR as its data source. The guy who rewrote the DLESE system was unaware of iVia, GEMCat, DC-Dot. The new interface only understands qualified DC (the NSDL flavor), others are stored as blobs. They are now using the "new" vocabularies designed by Katy & Co.<br />
#*Stuart said that Diny asked about why they weren't using the Registry, and Katy said that they had long term plans to do so ("cold spell in hell").<br />
#*Jon said that the presentation on "Using the NDR" was packed, and there was a lot of discussion on the new tools, and teachers submitting data (via a UCAR project with the Denver school district). He talked to one of the developers about using the Registry for the "new" NSDL schema (either as a schema or AP), to Katy on registering the new vocabularies and encouraging other NSDL projects in the same direction. <br />
#*Jon had a conversation with Tim about the new NDR, which doesn't ingest or output RDF, and can't use URIs because they're set to use strings only.<br />
#*Stuart reported on Diny's conversation with Lee, which focused on the ASN (which is no longer being funded by NSDL). Lee was following up with NSF staff, looking for a way forward. Stuart will be talking to her again today and will report back. <br />
#Request for feedback on SKOS proposal (Jon)<br />
#*Jon asks for more feedback on his proposal, before discussion is pushed on the SKOS list.</div>Dianehttp://wiki.metadataregistry.org/Oct._29,_2007Oct. 29, 20072007-10-29T02:11:32Z<p>Diane: </p>
<hr />
<div>===Telecon Agenda & Notes, Oct. 29, 2007===<br />
<br />
#The state of the Registry and upcoming improvements (Jon)<br />
#*What will Stuart's class need to know? Are there any requirements we should consider for that kind of use?<br />
#**The students have a specific assignment, and Stuart has taken some new screen shots which he will add to the documentation. <br />
#*Can we get some structured feedback from the students?<br />
#**Stuart will ask the students for some feedback, probably through a short survey.<br />
#First grant final report (Diane)<br />
#*Though we have gotten confirmation that the non-funded extension has been approved, it'd be good to get started on the report<br />
#**'''Action Item:''' Stuart will start a Google Doc so we can start the report<br />
#Upshot of conversation with Kate Wittenberg (Diane)<br />
#*Jon will talk to her in Washington, in hopes of getting her to discuss some of our concerns with Lee<br />
#*'''Action Item:''' Diane will follow up with Kate after the AM<br />
#Upcoming work with the University of Rochester eXtensible Catalog Project<br />
#*We will need to do some additional requirements drafting to work with their [yet to be hired] developers</div>Dianehttp://wiki.metadataregistry.org/Oct._22,_2007Oct. 22, 20072007-10-23T13:56:12Z<p>Diane: </p>
<hr />
<div>==Teleconference Agenda and Notes, Oct. 23, 2007==<br />
<br />
#Report of Amsterdam meeting of W3C SWDWG (Jon)<br />
#*Jon is concerned that some of the more recent decisions will not be useful for us as implementers. Many of the issues are holdovers from the previous working group, with opinions split between theoreticians and practical implementers. The alternatives proposed by the theoreticians seem much more complex than the one Jon was supporting. Much of the concern lies with the issue of accommodating existing vocabularies that are problematic in SKOS but can already be expressed in RDF. <br />
#*Example is when we look at a label as a term rather than a label, and we attach notes about where it comes from, these notes are as much about the term as the concept. This allows more than one person to relate a term with a concept, by allowing relationships to be "owned" and managed. Ergo, nobody owns the concepts, but the descriptions, labels, etc. can be managed as vocabularies.<br />
#*Because there's a relationship between terms and concepts, what's used when describing resources can be either, depending on whether you use URIs for the term or the concept. This approach gives us more flexibility but still compliant with SKOS.<br />
#*Jon is also concerned that they are intending to deprecate "skos:inScheme" as a way to avoid 'containment'. This came up at the end of the meeting but didn't get into the meeting notes. There hasn't been much discussion about it, and Jon will suggest that some other RDF collection property should be used. <br />
#Upcoming NSDL Annual Meeting<br />
#*Stuart will not be going to the meeting though he will be doing a poster and slides for others. <br />
#*'''ACTION ITEM:''' Diane will contact Kate to tell her that she won't be attending, will try and query about what's up<br />
#*'''ACTION ITEM:''' Stuart will craft an email to Lee about the state of NSDL metadata<br />
#DC Registry Community TF<br />
#*Diane reported on Emma's proposal to the AB, which will be going out soon<br />
#Joe and Stuart's article will be showing up in the January issue ASIST.<br />
#Jon reported briefly on the state of the DCMI website and documentation tenders</div>Dianehttp://wiki.metadataregistry.org/University_of_Rochester_eXtensible_Catalog_ProjectUniversity of Rochester eXtensible Catalog Project2007-10-16T15:15:46Z<p>Diane: /* University of Rochester eXtensible Catalog Project */</p>
<hr />
<div>== HUB Project ==<br />
<br />
==== This page is no longer available ====</div>Dianehttp://wiki.metadataregistry.org/Sept._10,_2007Sept. 10, 20072007-09-06T20:41:03Z<p>Diane: /* Agenda & Notes, September 10, 2007 */</p>
<hr />
<div>===Agenda & Notes, September 10, 2007===<br />
<br />
#Rollover of funds between the ending Registry Project to the new funding. The Accounting folks at Cornell are getting very anxious about this--they want to make sure that decisions are made before I go on disability to ensure that Jon and I continue to get paychecks over the transition. Ergo, they need an okay from Lee on rolling over the funds and/or something that assures them that the funding is really coming on the extension. How can we do this, and also address some other issues with Lee, re: the NSDL metadata planning? For the rollover issue, we need to get assurances from Lee that we can do the following:<br />
#* Fund Jon to go to Amsterdam for the SWD WG meeting<br />
#* Use leftover computer services money for new laptops<br />
#** Stuart suggests firing off an email to Lee, assuming that everything is going okay with the work for the extension, given my need for paperwork before going on disability. Add a sentence of explanation for Jon's trip.<br />
#** For the NSDL Metadata issues, Stuart would like to send Lee an email identifying some of the issues, given the proposal that didn't get funded. Stuart is basically operating on no funding (their stuff wasn't funded in this round), and needs to figure out what his role is in all this. He would like to approach Lee about the long term issue around how broken it is concerning metadata. <br />
#Final report to NSF on the first two years<br />
#* Stuart will send the PDF document that says what is needed for the final report.<br />
#Licenses: NLB interested in installing, need to determine what licenses to use. See [http://www.opensource.org/licenses/category Open Source Licenses by Category] and [http://developer.kde.org/documentation/licensing/licenses_summary.html Open Source Licenses] for some useful information for discussion.<br />
#* We agreed that we wanted a license that required feeding back core development even for commercial uses. Jon will narrow down the possibilities and suggest some options. <br />
#Singapore De-Briefing<br />
#* Conference Papers: Is the OAI server registered on the [http://gita.grainger.uiuc.edu/registry/searchform.asp UIUC OAI Registry]? If not, it should be ...<br />
#** Stuart will go into the UIUC Registry and add the conference papers site. He will also start some conversations with on the DC Conference lists about the issues that have come up since Singapore.<br />
#* RDA/DCMI Effort: Implications for the Registry<br />
#** Timetable--Critical to get schemas registered, and upload enabled<br />
#** Gordon mentioned that the JSC is pushing to get the FRBR Entities registered<br />
#** Registry may have an issue with registering the RDA/ONIX vocabularies (see [http://dlib.org/dlib/january07/dunsire/01dunsire.html Gordon's article]). I sat with him and showed him how to use the Sandbox and he was very interested in using it for that vocabulary. Jon and I will work to identify the issues for the SWD WG meeting in early Oct. <br />
#*** Stuart will be teaching a metadata course, Sam Oh is teaching a metadata schema/RDF schema course. Stuart's course will be built around Application Profiles. He wants them to declare some vocabularies, and to use the sandbox to finish their project. He suggested that we can promote the sandbox as a teaching mechanism. <br />
#* DC Registries Community<br />
#** Tsukuba announced that they're going to work to register APs!<br />
#** Community seems interested in participating with blogging (Jon will send message to the list about how to get signed up)<br />
#** Community tasks for coming year: <br />
#*** 1) Coming up with an updated set of functional requirements for a registry, based on the experiences and findings of registry developments.<br />
#*** 2) A draft set of functional requirements related to the inter-registry transfer language or languages - interoperability concerns related to sharing info between registries and with other applications such as vocab management that share related aims.<br />
#*** 3) To investigate the dissemination functionality desirable in a registry (& appropriate use cases). That is - appropriate forms of human-readable report, notification of changes, and so forth.<br />
#* NSDL Registry as Vocabulary Management Software <br />
#** Tom tired of text editing, approached Diane about using the Registry to create the files <br />
#** Diane thinks he wants to update the DCMI Registry (which will reside in Tsukuba), but will also want to generate the DC terms web pages as well<br />
#** Tom will contact Jon about his requirements<br />
#Bug fixes and testing report (Jon)</div>Dianehttp://wiki.metadataregistry.org/BibliographyBibliography2007-09-06T20:08:29Z<p>Diane: New page: <div class="header"> {| width="100%" bgcolor="#FF6600" | width="70" | [http://dublincore.org/index.shtml Dublin Core Metadata Initiative logo] | width="100%" height=...</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/GlossaryGlossary2007-09-06T20:05:55Z<p>Diane: New page: <div class="header"> {| width="100%" bgcolor="#FF6600" | width="70" | [http://dublincore.org/index.shtml Dublin Core Metadata Initiative logo] | width="100%" height=...</p>
<hr />
<div></div>Dianehttp://wiki.metadataregistry.org/Using_Dublin_Core_in_Semantic_MediaWikiUsing Dublin Core in Semantic MediaWiki2007-09-06T13:51:57Z<p>Diane: /* Refinement(s) for element: Identifier */</p>
<hr />
<div><div class="header"><br />
<br />
{| width="100%" bgcolor="#FF6600"<br />
| width="70" |<br />
[/index.shtml [[Image:logo_sm.gif|Dublin Core Metadata Initiative logo]]]<br />
| width="100%" height="70" align="right" valign="top" |<br />
{| width="328"<br />
| width="82" height="30" |<br />
[/about/ [[Image:about.gif|About the Initiative]]]<br />
| width="82" height="30" |<br />
[/documents/ [[Image:documents.gif|Documents]]]<br />
| width="82" height="30" |<br />
[/groups/ [[Image:groups.gif|Working Groups]]]<br />
| width="82" height="30" |<br />
[/resources/ [[Image:resources.gif|Resources]]]<br />
|-<br />
| width="82" height="30" |<br />
[/news/2007/ [[Image:news.gif|Dublin Core Metadata Initiative News]]]<br />
| width="82" height="30" |<br />
[/tools/ [[Image:tools.gif|Tools and Software]]]<br />
| width="82" height="30" |<br />
[/projects/ [[Image:projects.gif|Projects]]]<br />
| width="82" height="30" |<br />
[http://askdcmi.askvrd.org/ [[Image:askdcmi.gif|AskDCMI]]]<br />
|}<br />
|-<br />
| colspan="2" height="30" |<br />
[/index.shtml [[Image:dcmi_sm.gif|Dublin Core Metadata Initiative]]]<br />
|}<br />
<br />
{| width="100%" cellpadding="6"<br />
| class="crumb" |<br />
[http://dublincore.org/ Home] > [http://dublincore.org/documents/ Documents] > [http://dublincore.org/documents/usageguide/ Usageguide] ><br />
| align="right" |<br />
{| cellpadding="2"<br />
|}<br />
|}<br />
<br />
</div><div class="dcmiprint">[[Image:dcmi_logo_print.gif|Dublin Core Metadata Initiative]]</div><br />
<br />
=Using Dublin Core=<br />
<br />
{| class="docinfo"<br />
! Creator:<br />
|<br />
[mailto:dih1@cornell.edu Diane Hillmann]<br />
|-<br />
! Date Issued:<br />
| 2005-11-07<br />
|-<br />
! Identifier:<br />
|<br />
[/documents/2005/11/07/usageguide/ http://dublincore.org/documents/2005/11/07/usageguide/]<br />
|-<br />
! Replaces:<br />
|<br />
[/documents/2005/08/15/usageguide/ http://dublincore.org/documents/2005/08/15/usageguide/]<br />
|-<br />
! Is Replaced By:<br />
| Not applicable<br />
|-<br />
! Latest Version:<br />
|<br />
[/documents/usageguide/ http://dublincore.org/documents/usageguide/]<br />
|-<br />
! Translations:<br />
|<br />
[/resources/translations/ http://dublincore.org/resources/translations/]<br />
|-<br />
! Status of Document:<br />
|<br />
[/documents/#recommendedresources DCMI Recommended Resource]<br />
|-<br />
! Description of Document:<br />
| This document is intended as an entry point for users of Dublin Core. For non-specialists, it will assist them in creating simple descriptive records for information resources (for example, electronic documents). Specialists may find the document a useful point of reference to the documentation of Dublin Core, as it changes and grows.<br />
|}<br />
<br />
==Table of Contents==<br />
<br />
[/documents/usageguide/#introduction 1. Introduction]<br />
<br />
* [/documents/usageguide/#whatismetadata 1.1. What is Metadata?]<br />
* [/documents/usageguide/#whatis 1.2. What is the Dublin Core?]<br />
* [/documents/usageguide/#purpose 1.3. The Purpose and Scope of This Guide]<br />
<br />
[/documents/usageguide/#whichsyntax 2. Syntax, Storage and Maintenance Issues]<br />
<br />
* [/documents/usageguide/#html 2.1. HTML]<br />
* [/documents/usageguide/#rdfxml 2.2. RDF/XML]<br />
* [/documents/usageguide/#metadatacontained 2.3. Metadata Storage and Maintenance]<br />
<br />
[/documents/usageguide/#basicprinciples 3. Element Content and Controlled Vocabularies]<br />[/documents/usageguide/elements.shtml 4. The Elements]<br />[/documents/usageguide/qualifiers.shtml 5. Dublin Core Qualifiers]<br />[/documents/usageguide/appendix_roles.shtml 6. Appendix, Roles]<br />[/documents/usageguide/glossary.shtml 7. Glossary]<br />[/documents/usageguide/bibliography.shtml 8. Bibliography]<br />
<br />
==1. Introduction==<br />
<br />
===1.1. What is Metadata?===<br />
<br />
Metadata has been with us since the first librarian made a list of the items on a shelf of handwritten scrolls. The term "meta" comes from a Greek word that denotes "alongside, with, after, next." More recent Latin and English usage would employ "meta" to denote something transcendental, or beyond nature. Metadata, then, can be thought of as data about other data. It is the Internet-age term for information that librarians traditionally have put into catalogs, and it most commonly refers to descriptive information about Web resources.<br />
<br />
A metadata record consists of a set of attributes, or elements, necessary to describe the resource in question. For example, a metadata system common in libraries -- the library catalog -- contains a set of metadata records with elements that describe a book or other library item: author, title, date of creation or publication, subject coverage, and the call number specifying location of the item on the shelf.<br />
<br />
The linkage between a metadata record and the resource it describes may take one of two forms:<br />
<br />
# elements may be contained in a record separate from the item, as in the case of the library's catalog record; or<br />
# the metadata may be embedded in the resource itself.<br />
<br />
Examples of embedded metadata that is carried along with the resource itself include the Cataloging In Publication (CIP) data printed on the verso of a book's title page; or the TEI header in an electronic text. Many metadata standards in use today, including the Dublin Core standard, do not prescribe either type of linkage, leaving the decision to each particular implementation.<br />
<br />
Although the concept of metadata predates the Internet and the Web, worldwide interest in metadata standards and practices has exploded with the increase in electronic publishing and digital libraries, and the concomitant "information overload" resulting from vast quantities of undifferentiated digital data available online. Anyone who has attempted to find information online using one of today's popular Web search services has likely experienced the frustration of retrieving hundreds, if not thousands, of "hits" with limited ability to refine or make a more precise search. The wide scale adoption of descriptive standards and practices for electronic resources will improve retrieval of relevant resources in any venue where information retrieval is critical. As noted by Weibel and Lagoze, two leaders in the fields of metadata development and digital libraries:<br />
<br />
<blockquote><br />
<br />
"The association of standardized descriptive metadata with networked objects has the potential for substantially improving resource discovery capabilities by enabling field-based (e.g., author, title) searches, permitting indexing of non-textual objects, and allowing access to the surrogate content that is distinct from access to the content of the resource itself." (Weibel and Lagoze, 1997)<br />
<br />
</blockquote><br />
<br />
In the last years we have also seen an increase in the application of Dublin Core metadata in more closed environments. There are implementations where Dublin Core metadata is used to describe resources held, owned or produced by companies, governments and international organisations to supporting portal services or internal knowledge management. There are also implementations where Dublin Core metadata is used as a common exchange format supporting the aggregation of collections of metadata, such as the case of the Open Archive Initiative. In these cases, like in the open environment of the Web, the concept of standardized descriptive metadata provides a powerful mechanism to improve retrieval for specific applications and specific user communities. It is this need for "standardized descriptive metadata" that the Dublin Core addresses.<br />
<br />
===1.2. What is the Dublin Core?===<br />
<br />
The Dublin Core metadata standard is a simple yet effective element set for describing a wide range of networked resources. The Dublin Core standard includes two levels: Simple and Qualified. Simple Dublin Core comprises fifteen elements; Qualified Dublin Core includes three additional elements (Audience, Provenance and RightsHolder), as well as a group of element refinements (also called qualifiers) that refine the semantics of the elements in ways that may be useful in resource discovery. The semantics of Dublin Core have been established by an international, cross-disciplinary group of professionals from librarianship, computer science, text encoding, the museum community, and other related fields of scholarship and practice.<br />
<br />
Another way to look at Dublin Core is as a "small language for making a particular class of statements about resources". In this language, there are two classes of terms -- elements (nouns) and qualifiers (adjectives) -- which can be arranged into a simple pattern of statements. The resources themselves are the implied subjects in this language. (For additional discussion of Dublin Core Grammar, see [/usage/documents/principles/ "DCMI Grammatical Principles"]) In the diverse world of the Internet, Dublin Core can be seen as a "metadata pidgin for digital tourists": easily grasped, but not necessarily up to the task of expressing complex relationships or concepts.<br />
<br />
The Dublin Core basic element set is outlined in [/documents/usageguide/elements.shtml Section 4]. Each element is optional and may be repeated. Most elements also have a limited set of qualifiers or refinements, attributes that may be used to further refine (not extend) the meaning of the element. The Dublin Core Metadata Initiative (DCMI) has established standard ways to refine elements and encourage the use of encoding and vocabulary schemes. The full set of [/documents/dcmi-terms/ elements and element refinements] conforming to DCMI "best practice" is available, with a [/dcregistry/ formal registry] available as well.<br />
<br />
Three other Dublin Core principles bear mentioning here, as they are critical to understanding how to think about the relationship of metadata to the underlying resources they describe.<br />
<br />
<blockquote><br />
<br />
1. The One-to-One Principle. In general Dublin Core metadata describes one manifestation or version of a resource, rather than assuming that manifestations stand in for one another. For instance, a jpeg image of the Mona Lisa has much in common with the original painting, but it is not the same as the painting. As such the digital image should be described as itself, most likely with the creator of the digital image included as a Creator or Contributor, rather than just the painter of the original Mona Lisa. The relationship between the metadata for the original and the reproduction is part of the metadata description, and assists the user in determining whether he or she needs to go to the Louvre for the original, or whether his/her need can be met by a reproduction.<br />
<br />
</blockquote><blockquote><br />
<br />
2. The Dumb-down Principle. The qualification of Dublin Core properties is guided by a rule known colloquially as the Dumb-Down Principle. According to this rule, a client should be able to ignore any qualifier and use the value as if it were unqualified. While this may result in some loss of specificity, the remaining element value (minus the qualifier) must continue to be generally correct and useful for discovery. Qualification is therefore supposed only to refine, not extend the semantic scope of a property.<br />
<br />
</blockquote><blockquote><br />
<br />
3. Appropriate values. Best practice for a particular element or qualifier may vary by context, but in general an implementor cannot predict that the interpreter of the metadata will always be a machine. This may impose certain constraints on how metadata is constructed, but the requirement of usefulness for discovery should be kept in mind.<br />
<br />
Although the Dublin Core was originally developed with an eye to describing document-like objects (because traditional text resources are fairly well understood), DC metadata can be applied to other resources as well. Its suitability for use with particular non-document resources will depend to some extent on how closely their metadata resembles typical document metadata and also what purpose the metadata is intended to serve. (Implementors interested in using Dublin Core for diverse resources are encouraged to browse the [/projects/ Dublin Core Projects pages] for ideas on using Dublin Core metadata for their resources.)<br />
<br />
Dublin Core has as its goals:<br />
<br />
Simplicity of creation and maintenance<br />
<br />
<blockquote><br />
<br />
The Dublin Core element set has been kept as small and simple as possible to allow a non-specialist to create simple descriptive records for information resources easily and inexpensively, while providing for effective retrieval of those resources in the networked environment.<br />
<br />
</blockquote><br />
<br />
Commonly understood semantics<br />
<br />
<blockquote><br />
<br />
Discovery of information across the vast commons of the Internet is hindered by differences in terminology and descriptive practices from one field of knowledge to the next. The Dublin Core can help the "digital tourist" -- a non-specialist searcher -- find his or her way by supporting a common set of elements, the semantics of which are universally understood and supported. For example, scientists concerned with locating articles by a particular author, and art scholars interested in works by a particular artist, can agree on the importance of a "creator" element. Such convergence on a common, if slightly more generic, element set increases the visibility and accessibility of all resources, both within a given discipline and beyond.<br />
<br />
</blockquote><br />
<br />
International scope<br />
<br />
<blockquote><br />
<br />
The Dublin Core Element Set was originally developed in English, but versions are being created in [/resources/translations/ many other languages], including Finnish, Norwegian, Thai, Japanese, French, Portuguese, German, Greek, Indonesian, and Spanish. [/groups/languages/ The DCMI Localization and Internationalization Special Interest Group] is coordinating efforts to link these versions in a distributed registry.<br />
<br />
Although the technical challenges of internationalization on the World Wide Web have not been directly addressed by the Dublin Core development community, the involvement of representatives from virtually every continent has ensured that the development of the standard considers the multilingual and multicultural nature of the electronic information universe.<br />
<br />
</blockquote><br />
<br />
Extensibility<br />
<br />
<blockquote><br />
<br />
While balancing the needs for simplicity in describing digital resources with the need for precise retrieval, Dublin Core developers have recognized the importance of providing a mechanism for extending the DC element set for additional resource discovery needs. It is expected that other communities of metadata experts will create and administer additional metadata sets, specialized to the needs of their communities. Metadata elements from these sets could be used in conjunction with Dublin Core metadata to meet the need for interoperabilbility. The DCMI Usage Board is presently working on a model for accomplishing this in the context of "application profiles."<br />
<br />
Rachel Heery and Manjula Patel, in their article [http://www.ariadne.ac.uk/issue25/app-profiles/ "Application profiles: mixing and matching metadata schemas"] define an application profile as:<br />
<br />
<blockquote><br />
<br />
" ... schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application."<br />
<br />
</blockquote><br />
<br />
This model allows different communities to use the DC elements for core descriptive information, and allowing domain specific extensions which make sense within a more limited arena.<br />
<br />
</blockquote></blockquote><br />
<br />
===1.3. The Purpose and Scope of This Guide===<br />
<br />
This document is intended to be an entry point for users of Dublin Core. For non-specialists, it will assist in creating simple descriptive records for information resources (for example, electronic documents, JPEG images, video clips). Specialists may find the document a useful point of reference to the documentation of Dublin Core, as it changes and grows.<br />
<br />
"Using Dublin Core" will show in a non-technical fashion how Dublin Core metadata may be used by anyone to make their material more accessible. It discusses the principles, structure and content of Dublin Core metadata elements, how to use them in composing a complete Dublin Core metadata record, as well as how to qualify elements to support use by a wide variety of communities.<br />
<br />
Another important goal of this document is to promote "best practices" for describing resources using the Dublin Core element set. The Dublin Core community recognizes that consistency in creating metadata is an important key to achieving optimal retrieval and intelligible display across disparate sources of descriptive records. Inconsistent metadata effectively hides desired records, resulting in uneven, unpredictable or incomplete search results.<br />
<br />
As a general introduction, this document is necessarily brief, and cannot address all the issues implementors may encounter while planning their use of metadata. Several avenues remain for those who have additional questions beyond those addressed in this guide.<br />
<br />
# 1. Appended to this guide are references to relevant articles and other resources, including those with more technical guidance for implementors<br />
# The Dublin Core Website contains references to additional documents and resources of the DCMI community and ways for implementors to become involved in the DCMI<br />
# Specific questions can be addressed to [http://askdcmi.askvrd.org/ AskDCMI]. In addition to fielding questions, the AskDCMI service maintains a searchable archive of already answered questions and links to additional resources.<br />
<br />
===2. Syntax Issues===<br />
<br />
[/documents/abstract-model/ The Dublin Core Abstract Model] provides a reference model against which particular DC encoding guidelines can be compared, independent of any particular encoding syntax. Such a reference model allows implementors to gain a better understanding of the kinds of descriptions they are trying to encode and facilitates the development of better mappings and translations between different syntaxes. Although the document is primarily aimed at the developers of software applications that support Dublin Core metadata, anyone who is considering implementing Dublin Core -- particularly those contemplating extending DC in any way -- could usefully review the document. Those involved in developing new syntax encoding guidelines for Dublin Core metadata or developing metadata application profiles based on the Dublin Core should also become familiar with the DC Abstract Model.<br />
<br />
In this guide, we have chosen to represent Dublin Core examples in a "generic" form (Element="value"). Examples of other syntaxes, including: HTML or XHTML (the Web's Hypertext Markup Language format), RDF/XML (the Resource Description Framework using eXtensable Markup Language) and in plain XML can be found in syntax-specific [/resources/expressions/ documents available on the DCMI Website]. Some are also referenced within this document and in the [/documents/usageguide/bibliography.shtml Bibliography Section] of this guide.<br />
<br />
Syntax choices depend on a number of variables, and "one size fits all" prescriptions rarely apply. When considering an appropriate syntax, it is important to note that Dublin Core concepts and semantics are designed to be syntax independent, are equally applicable in a variety of contexts, as long as the metadata is in a form suitable for interpretation both by search engines and by human beings.<br />
<br />
===2.1. HTML and XHTML===<br />
<br />
HTML or XHTML can be used to express either simple or qualified Dublin Core, although there are limitations inherent in representing refinements in HTML. Specific instructions for expressing Dublin Core in HTML can be found in the following DCMI document:<br />
<br />
# [/documents/dcq-html/ Expressing Qualified Dublin Core in HTML/XHTML meta and link elements]<br />
<br />
===2.2. RDF/XML===<br />
<br />
RDF (Resource Description Framework) allows multiple metadata schemes to be read by humans as well as parsed by machines. It uses XML (EXtensible Markup Language) to express structure thereby allowing metadata communities to define the actual semantics. This decentralized approach recognizes that no one scheme is appropriate for all situations, and further that schemes need a linking mechanism independent of a central authority to aid description, identification, understanding, usability, and/or exchange.<br />
<br />
RDF allows multiple objects to be described without specifying the detail required. The underlying glue, XML, simply requires that all namespaces be defined and once defined, they can be used to the extent needed by the provider of the metadata.<br />
<br />
For example:<br />
<br />
<rdf:RDF <br />
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"<br />
xmlns:dc="http://purl.org/dc/elements/1.1/"><br />
<br />
<rdf:Description rdf:about="http://media.example.com/audio/guide.ra"><br />
<br />
<dc:creator>Rose Bush</dc:creator><br />
<br />
<dc:title>A Guide to Growing Roses</dc:title><br />
<dc:description>Describes process for planting and nurturing different kinds of rose bushes.</dc:description> <br />
<dc:date>2001-01-20</dc:date><br />
<br />
</rdf:Description> <br />
<br />
</rdf:RDF><br />
<br />
This simple example uses Dublin Core by itself to describe an audio recording of a guide to growing rose bushes. With XML or RDF/XML, Dublin Core can potentially be mixed with other metadata vocabularies. For example, the simple Dublin Core description above might be used alongside other vocabularies such as vCard that can describe the author's affiliation and contact information, or a more specialized "rose description" vocabulary that described the rose bushes in greater detail.<br />
<br />
DCMI has made available several recommendations specifically about using these syntaxes:<br />
<br />
# [/documents/dc-xml-guidelines/ Guidelines for Implementing Dublin Core in XML]<br />
# [/documents/dcmes-xml/ Expressing Simple Dublin Core in RDF/XML]<br />
# [/documents/dcq-rdf-xml/ Expressing Qualified Dublin Core in RDF/XML] (Proposed Recommendation)<br />
<br />
===2.3. Metadata Storage and Maintenance Issues===<br />
<br />
Some implementations using Dublin Core have chosen to embed their metadata within the resource itself. This approach is taken most often with documents encoded using HTML, but is also sometimes possible with other kinds of documents. Simple tools have been developed to make provision of Dublin Core metadata within HTML encoded pages fairly easy. One such tool, [http://www.ukoln.ac.uk/metadata/dcdot/ DC.dot], extracts metadata information from an HTML document, and formats it so that it can be edited, then cut and pasted back into the HTML header of the original document.<br />
<br />
On the other hand, metadata can be stored in any kind of database, and provide a link to the described resource rather than be embedded within it. This approach is likely to be most practical for many non-textual resources, and is increasingly used for text as well, primarily to support easier maintenance and sharing of metadata.<br />
<br />
Each of these approaches have their advantages and disadvantages, and the balance point changes as implementations become larger and more diverse, and also as the metadata ages over time.<br />
<br />
===3. Element Content and Controlled Vocabularies===<br />
<br />
Each Dublin Core element is optional and repeatable, and there is no defined order of elements. The ordering of multiple occurrences of the same element (e.g., Creator) may have a significance intended by the provider, but ordering is not guaranteed to be preserved in every user environment. Ordering or sequencing may be syntax dependent; for instance, RDF/XML supports ordering, but HTML does not.<br />
<br />
Content data for some elements may be selected from a "controlled vocabulary," which is a limited set of consistently used and carefully defined terms. This can dramatically improve search results because computers are good at matching words character by character but weak at understanding the way people refer to one concept using different words, i.e. synonyms. Without basic terminology control, inconsistent or incorrect metadata can profoundly degrade the quality of search results. For example, without a controlled vocabulary, "candy" and "sweet" might be used to refer to the same concept. Controlled vocabularies may also reduce the likelihood of spelling errors when recording metadata.<br />
<br />
One cost of a controlled vocabulary is the necessity for an administrative body to review, update and disseminate the vocabulary. For example, the US Library of Congress Subject Headings (LCSH) and the US National Library of Medicine Medical Subject Headings (MeSH) are formal vocabularies, indispensable for searching rigorously cataloged collections. However, both require significant support organizations. Another cost is having to train searchers and creators of metadata so that they know when using MeSH, for example, to enter "myocardial infarction" instead of the more colloquial "heart attack." More sophisticated implementations can make such tasks much easier, but the controlled vocabulary terms must be available for them to apply.<br />
<br />
Using controlled vocabularies can be done most effectively using [/documents/dcmi-terms/#H4 encoding schemes]. Without an encoding scheme specifically designated, a subject which might very well be carefully selected from a particular controlled vocabulary cannot be distinguished from a simple keyword.<br />
<br />
===4. [/documents/usageguide/elements.shtml The Elements]===<br />
<div class="header"><br />
<br />
{| width="100%" bgcolor="#FF6600"<br />
| width="70" |<br />
[http://dublincore.org/index.shtml [[Image:logo_sm.gif|Dublin Core Metadata Initiative logo]]]<br />
| width="100%" height="70" align="right" valign="top" |<br />
{| width="328"<br />
| width="82" height="30" |<br />
[http://dublincore.org/about/ [[Image:about.gif|About the Initiative]]]<br />
| width="82" height="30" |<br />
[http://dublincore.org/documents/ [[Image:documents.gif|Documents]]]<br />
| width="82" height="30" |<br />
[http://dublincore.org/groups/ [[Image:groups.gif|Working Groups]]]<br />
| width="82" height="30" |<br />
[http://dublincore.org/resources/ [[Image:resources.gif|Resources]]]<br />
|-<br />
| width="82" height="30" |<br />
[http://dublincore.org/news/2007/ [[Image:news.gif|Dublin Core Metadata Initiative News]]]<br />
| width="82" height="30" |<br />
[http://dublincore.org/tools/ [[Image:tools.gif|Tools and Software]]]<br />
| width="82" height="30" |<br />
[http://dublincore.org/projects/ [[Image:projects.gif|Projects]]]<br />
| width="82" height="30" |<br />
[http://askdcmi.askvrd.org/ [[Image:askdcmi.gif|AskDCMI]]]<br />
|}<br />
|-<br />
| colspan="2" height="30" |<br />
[http://dublincore.org/index.shtml [[Image:dcmi_sm.gif|Dublin Core Metadata Initiative]]]<br />
|}<br />
<br />
{| width="100%" cellpadding="6"<br />
| class="crumb" |<br />
[http://dublincore.org/ Home] > [http://dublincore.org/documents/ Documents] > [http://dublincore.org/documents/usageguide/ Usageguide] ><br />
| align="right" |<br />
{| cellpadding="2"<br />
|}<br />
|}<br />
<br />
</div><div class="dcmiprint">[[Image:dcmi_logo_print.gif|Dublin Core Metadata Initiative]]</div><br />
<br />
=Using Dublin Core - The Elements=<br />
<br />
==4. The Elements==<br />
<br />
This section lists each element by its full name and label. For each element there are guidelines to assist in creating metadata content, whether it is done "from scratch" or by converting an existing record in another format.<br />
<br />
In the element descriptions below, a formal single-word label is specified to make the syntactic specification of elements simpler for encoding schemes. Although some environments, such as HTML, are not case-sensitive, it is recommended best practice always to adhere to the case conventions in the element names given below to avoid conflicts in the event that the metadata is subsequently converted to a case-sensitive environment, such as XML.<br />
<br />
Some information may appear to belong in more than one metadata element. While there will normally be a clear preferred choice, there is potential semantic overlap between some elements. Consequently, there will occasionally be some judgment required from the person assigning the metadata.<br />
<br />
===4.1. Title===<br />
<br />
''Label: Title''<br />
<br />
''Element Description:'' The name given to the resource. Typically, a Title will be a name by which the resource is formally known.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If in doubt about what constitutes the title, repeat the Title element and include the variants in second and subsequent Title iterations. If the item is in HTML, view the source document and make sure that the title identified in the title header (if any) is also included as a Title.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Title="A Pilot's Guide to Aircraft Insurance"<br /> Title="The Sound of Music"<br /> Title="Green on Greens"<br /> Title="AOPA's Tips on Buying Used Aircraft"</blockquote><br />
<br />
===4.2. Subject===<br />
<br />
''Label: Subject and Keywords''<br />
<br />
''Element Description:'' The topic of the content of the resource. Typically, a Subject will be expressed as keywords or key phrases or classification codes that describe the topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Select subject keywords from the Title or Description information, or from within a text resource. If the subject of the item is a person or an organization, use the same form of the name as you would if the person or organization were a Creator or Contributor.<br />
<br />
In general, choose the most significant and unique words for keywords, avoiding those too general to describe a particular item. Subject might include classification data if it is available (for example, Library of Congress Classification Numbers or Dewey Decimal numbers) or controlled vocabularies (such as Medical Subject Headings or Art and Architecture Thesaurus descriptors) as well as keywords.<br />
<br />
When including terms from multiple vocabularies, use separate element iterations. If multiple vocabulary terms or keywords are used, either separate terms with semi-colons or use separate iterations of the Subject element.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Subject="Aircraft leasing and renting"<br /> Subject="Dogs"<br /> Subject="Olympic skiing"<br /> Subject="Street, Picabo"</blockquote><br />
<br />
===4.3. Description===<br />
<br />
''Label: Description''<br />
<br />
''Element Description:'' An account of the content of the resource. Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Since the Description field is a potentially rich source of indexable terms, care should be taken to provide this element when possible. Best practice recommendation for this element is to use full sentences, as description is often used to present information to users to assist in their selection of appropriate resources from a set of search results.<br />
<br />
Descriptive information can be copied or automatically extracted from the item if there is no abstract or other structured description available. Although the source of the description may be a web page or other structured text with presentation tags, it is generally not good practice to include HTML or other structural tags within the Description element. Applications vary considerably in their ability to interpret such tags, and their inclusion may negatively affect the interoperability of the metadata.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Description="Illustrated guide to airport markings and lighting signals, with particular reference to SMGCS (Surface Movement Guidance and Control System) for airports with low visibility conditions."<br /><br /> Description="Teachers Domain is a multimedia library for K-12 science educators, developed by WGBH through funding from the National Science Foundation as part of its National Science Digital Library initiative. The site offers a wealth of classroom-ready instructional resources, as well as online professional development materials and a set of tools which allows teachers to manage, annotate, and share the materials they use in classroom teaching."</blockquote><br />
<br />
===4.4. Type===<br />
<br />
''Label: Resource Type''<br />
<br />
''Element Description:'' The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the [http://dublincore.org/documents/dcmi-type-vocabulary/ DCMIType vocabulary] ). To describe the physical or digital manifestation of the resource, use the FORMAT element.<br />
<br />
''Guidelines for content creation:''<br />
<br />
If the resource is composed of multiple mixed types then multiple or repeated Type elements should be used to describe the main components.<br />
<br />
Because different communities or domains are expected to use a variety of type vocabularies, best practice to ensure interoperability is to include at least one general type term from the [http://dublincore.org/documents/dcmi-type-vocabulary/ DCMIType vocabulary] in addition to the domain specific type term(s), in separate Type element iterations.<br />
<br />
Examples:<br />
<br />
<blockquote>Type="Image"<br /> Type="Sound"<br /> Type="Text"<br /> Type="simulation"</blockquote><br />
<br />
'''Note:''' The first three values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.<br />
<br />
The item described is an ''Electronic art exhibition catalog:''<br />
<br />
<blockquote>Type="Image"<br /> Type="Text"<br /> Type="Exhibition catalog"</blockquote><br />
<br />
'''Note:''' The first two values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.<br />
<br />
The item described is a ''Multimedia educational program with interactive assignments:''<br />
<br />
<blockquote>Type="Image"<br /> Type="Text"<br /> Type="Software"<br /> Type="InteractiveResource"</blockquote><br />
<br />
'''Note:''' All values in this example are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary.<br />
<br />
===4.5. Source===<br />
<br />
''Label: Source''<br />
<br />
''Element Description:'' A Reference to a resource from which the present resource is derived. The present resource may be derived from the Source resource in whole or part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.<br />
<br />
''Guidelines for content creation:''<br />
<br />
In general, include in this area information about a resource that is related intellectually to the described resource but does not fit easily into a Relation element.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Source="RC607.A26W574 1996" [where "RC607.A26W574 1996" is the call number of the print version of the resource, from which the present version was scanned]<br /><br /> Source="Image from page 54 of the 1922 edition of Romeo and Juliet"</blockquote><br />
<br />
===4.6. Relation===<br />
<br />
''Label: Relation''<br />
<br />
''Element Description:'' A reference to a related resource. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Relationships may be expressed reciprocally (if the resources on both ends of the relationship are being described) or in one direction only, even when there is a refinement available to allow reciprocity. If text strings are used instead of identifying numbers, the reference should be appropriately specific. For instance, a formal bibliographic citation might be used to point users to a particular resource.<br />
<br />
Because the refined terms used with Relation provide significantly more information to a user than the unqualified use of Relation, implementers who are describing heavily interrelated resources might choose to use qualified Dublin Core.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Title="Reading Turgenev"<br /> Relation="Two Lives" [Resource is a collection of two novellas, one of which is "Reading Turgenev"]<br />''[Relationship described is '''IsPartOf'''.''</blockquote><br />
<br />
''[Part/Whole relations are those in which one resource is a physical or logical part of another]''<br />
<br />
<blockquote>Title="Candle in the Wind"<br /> Subject="Diana, Princess of Wales"<br /> Date="1997"<br /> Creator="John, Elton"<br /> Type="sound"<br /> Description="Tribute to a dead princess."<br /> Relation="Elton John's 1976 song Candle in the Wind"<br />''[Relationship described is '''IsVersionOf'''.''</blockquote><br />
<br />
''[Version relations are those in which one resource is an historical state or edition, of another resource by the same creator]''<br />
<br />
<blockquote>Title="Electronic AACR2"<br /> Relation="Anglo-American Cataloging Rules, 2nd edition"<br />''[Relationship described is '''IsFormatOf''']''</blockquote><blockquote>Title="Landsat TM dataset of Arnhemland, NT, Australia"<br /> Relation="arnhem.gif"<br /> [Relationship described is '''HasFormat''']</blockquote><br />
<br />
''[Format transformation relations are those in which one resource has been derived from another by a reproduction or reformatting technology which is not fundamentally an interpretation but intended to be a representation.]''<br />
<br />
<blockquote>Title="Morgan's Ancient Society"<br /> Relation="Engels' Origin of the Family, Private Property and the State"<br />''[Relationship described is '''IsReferencedBy''']''</blockquote><blockquote>Title="Nymphet Mania"<br /> Relation="References Adrian Lyne's 'Lolita'"<br />''[Relationship described is '''References''']''</blockquote><br />
<br />
''[Reference relations are those in which the author of one resource cites, acknowledges, disputes or otherwise make claims about another resource.]''<br />
<br />
<blockquote>Title="Peter Carey's novel Oscar and Lucinda"<br /> Relation="1998 movie Oscar and Lucinda"<br />''[Relationship described is '''IsBasisFor''']''</blockquote><blockquote>Title="The movie My Fair Lady"<br /> Relation="Shaw's play Pygmalion"<br />''[Relationship described is '''IsBasedOn''']''</blockquote><br />
<br />
''[Creative relations are those in which one resource is a performance, production, derivation, adaptation or interpretation of another resource.]''<br />
<br />
<blockquote>Title="Dead Ringer"<br /> Relation="Gemstar e-book"<br />''[Relationship described is '''Requires''']''</blockquote><br />
<br />
''[Dependency relations are those in which one resource requires another resource for its functioning, delivery, or content and cannot be used without the related resource being present.]''<br />
<br />
===4.7. Coverage===<br />
<br />
''Label: Coverage''<br />
<br />
''Element Description:'' The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic co-ordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [Getty Thesaurus of Geographic Names, [http://www.getty.edu/research/tools/vocabulary/tgn/ http://www. getty.edu/research/tools/vocabulary/tgn/]]). Where appropriate, named places or time periods should be used in preference to numeric identifiers such as sets of co-ordinates or date ranges.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Whether this element is used for spatial or temporal information, care should be taken to provide consistent information that can be interpreted by human users, particularly in order to provide interoperability in situations where sophisticated geographic or time-specific searching is not supported. For most simple applications, place names or coverage dates might be most useful. For more complex applications, consideration should be given to using an encoding scheme that supports appropriate specification of information, such as [http://dublincore.org/documents/dcmi-period/ DCMI Period], [http://dublincore.org/documents/dcmi-box/ DCMI Box] or [http://dublincore.org/documents/dcmi-point/ DCMI Point.]<br />
<br />
''Examples:''<br />
<br />
<blockquote>Coverage="1995-1996"<br /> Coverage="Boston, MA"<br /> Coverage="17th century"<br /> Coverage="Upstate New York"</blockquote><br />
<br />
===4.8. Creator===<br />
<br />
''Label: Creator''<br />
<br />
Element Description: An entity primarily responsible for making the content of the resource. Examples of a Creator include a person, an organization, or a service. Typically the name of the Creator should be used to indicate the entity.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Creators should be listed separately, preferably in the same order that they appear in the publication. Personal names should be listed surname or family name first, followed by forename or given name. When in doubt, give the name as it appears, and do not invert.<br />
<br />
In the case of organizations where there is clearly a hierarchy present, list the parts of the hierarchy from largest to smallest, separated by full stops and a space. If it is not clear whether there is a hierarchy present, or unclear which is the larger or smaller portion of the body, give the name as it appears in the item.<br />
<br />
If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser or ambiguous responsibility, other than creation, use Contributor.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Creator="Shakespeare, William"<br /> Creator="Wen Lee"<br /> Creator="Hubble Telescope"<br /> Creator="Internal Revenue Service. Customer Complaints Unit"</blockquote><br />
<br />
===4.9. Publisher===<br />
<br />
''Label: Publisher''<br />
<br />
''Element Description:'' The entity responsible for making the resource available. Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity.<br />
<br />
''Guidelines for content creation:''<br />
<br />
The intent of specifying this field is to identify the entity that provides access to the resource. If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of ambiguous responsibility, use Contributor.<br />
<br />
Examples:<br />
<br />
<blockquote>Publisher="University of South Where"<br /> Publisher="Funky Websites, Inc."<br /> Publisher="Carmen Miranda"</blockquote><br />
<br />
===4.10. Contributor===<br />
<br />
''Label: Contributor''<br />
<br />
''Element Description:'' An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person, an organization or a service. Typically, the name of a Contributor should be used to indicate the entity.<br />
<br />
''Guideline for content creation:''<br />
<br />
The same general guidelines for using names of persons or organizations as Creators apply here. Contributor is the most general of the elements used for "agents" responsible for the resource, so should be used when primary responsibility is unknown or irrelevant.<br />
<br />
===4.11. Rights===<br />
<br />
''Label: Rights Management''<br />
<br />
''Element Description:'' Information about rights held in and over the resource. Typically a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.<br />
<br />
''Guidelines for content creation:''<br />
<br />
The Rights element may be used for either a textual statement or a URL pointing to a rights statement, or a combination, when a brief statement and a more lengthy one are available.<br />
<br />
Examples:<br />
<br />
<blockquote>Rights="Access limited to members"<br /> Rights="http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Terms& quot;</blockquote><br />
<br />
===4.12. Date===<br />
<br />
''Label: Date''<br />
<br />
''Element Description:'' A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [Date and Time Formats, W3C Note, [http://www.w3.org/TR/NOTE-datetime http://www.w3.org/TR/NOTE- datetime]] and follows the YYYY-MM-DD format.<br />
<br />
Guidelines for content creation:<br />
<br />
If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) may be used. Many other schemes are possible, but if used, they may not be easily interpreted by users or software.<br />
<br />
Examples:<br />
<br />
<blockquote>Date="1998-02-16"<br /> Date="1998-02"<br /> Date="1998"</blockquote><br />
<br />
===4.13. Format===<br />
<br />
''Label: Format''<br />
<br />
''Element Description:'' The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource. Examples of dimensions include size and duration. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource.<br />
<br />
Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types [[http://www.iana.org/assignments/media-types/ http://www.iana.org/ assignments/media-types/]] defining computer media formats).<br />
<br />
''Guidelines for content creation:''<br />
<br />
In addition to the specific physical or electronic media format, information concerning the size of a resource may be included in the content of the Format element if available. In resource discovery size, extent or medium of the resource might be used as a criterion to select resources of interest, since a user may need to evaluate whether they can make use of the resource within the infrastructure available to them.<br />
<br />
When more than one category of format information is included in a single record, they should go in separate iterations of the element.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Title="Dublin Core icon"<br /> Identifier="http://purl.org/metadata/dublin_core/images/dc2.gif& quot;<br /> Type="Image"<br /> Format="image/gif"<br /> Format="4 kB"</blockquote><blockquote>Subject="Saturn"<br /> Type="Image"<br /> Format="image/gif 6"<br /> Format="40 x 512 pixels"<br /> Identifier="http://www.not.iac.es/newwww/photos/images/satnot.gif "</blockquote><blockquote>Title="The Bronco Buster"<br /> Creator="Frederic Remington"<br /> Type="Physical object"<br /> Format="bronze"<br /> Format="22 in."</blockquote><br />
<br />
===4.14. Identifier===<br />
<br />
''Label: Resource Identifier''<br />
<br />
''Element Description:'' An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Examples of formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).<br />
<br />
''Guidelines for content creation:''<br />
<br />
This element can also be used for local identifiers (e.g. ID numbers or call numbers) assigned by the Creator of the resource to apply to a particular item. It should not be used for identification of the metadata record itself.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Identifier="http://purl.oclc.org/metadata/dublin_core/& quot;<br /> Identifier="ISBN:0385424728"<br /> Identifier="H-A-X 5690B" [publisher number]</blockquote><br />
<br />
===4.15. Language===<br />
<br />
''Label: Language''<br />
<br />
''Element Description:'' A language of the intellectual content of the resource. Recommended best practice for the values of the Language element is defined by RFC 3066 [RFC 3066, [http://www.ietf.org/rfc/rfc3066.txt http://www.ietf.org/rfc/ rfc3066.txt]] which, in conjunction with ISO 639 [ISO 639, [http://www.oasis-open.org/cover/iso639a.html http://www.oasis- open.org/cover/iso639a.html]]), defines two- and three-letter primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Either a coded value or text string can be represented here. If the content is in more than one language, the element may be repeated.<br />
<br />
Examples:<br />
<br />
<blockquote>Language="en"<br /> Language="fr"<br /> Language="Primarily English, with some abstracts also in French."<br /> Language="en-US"</blockquote><br />
<br />
'''NOTE:''' Audience, Provenance and RightsHolder are elements, but not part of the Simple Dublin Core fifteen elements. Use Audience, Provenance and RightsHolder only when using Qualified Dublin Core.<br />
<br />
===4.16. Audience===<br />
<br />
''Label: Audience''<br />
<br />
''Element Description:'' A class of entity for whom the resource is intended or useful. A class of entity may be determined by the creator or the publisher or by a third party.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Audience terms are best utilized in the context of formal or informal controlled vocabularies. None are presently recommended or registered by DCMI, but several communities of interest are engaged in setting up audience vocabularies. In the absence of recommended controlled vocabularies, implementors are encouraged to develop local lists of values, and to use them consistently.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Audience="elementary school students"<br /> Audience="ESL teachers"<br /> Audience="deaf adults"</blockquote><br />
<br />
===4.17. Provenance===<br />
<br />
''Label: Provenance''<br />
<br />
''Element Description:'' A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity and interpretation. The statement may include a description of any changes successive custodians made to the resource.<br />
<br />
''Guidelines for content creation:''<br />
<br />
''Examples:''<br />
<br />
<blockquote>Provenance="This copy once owned by Benjamin Spock."<br /> Provenance="Estate of Hunter Thompson."<br /> Provenance="Stolen in 1999; recovered by the Museum in 2003."</blockquote><br />
<br />
===4.18. RightsHolder===<br />
<br />
''Label: Rights Holder''<br />
<br />
''Element Description:'' A person or organization owning or managing rights over the resource. Recommended best practice is to use the URI or name of the Rights Holder to indicate the entity.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Since, for the most part, people and organizations are not typically assigned URIs, a person or organization holding rights over a resource would be named using a text string. People and organizations sometimes have websites, but URLs for these are not generally appropriate for use in this context, since they are not clearly identifying the person or organization, but rather the location of a website about them.<br />
<br />
''Examples:''<br />
<br />
<blockquote>RightsHolder="Stuart Weibel"<br /> RightsHolder="University of Bath"</blockquote><br />
<br />
===4.19. InstructionalMethod===<br />
<br />
''Label: Instructional Method''<br />
<br />
''Element Description:'' A process, used to engender knowledge, attitudes and skills, that the resource is designed to support. Instructional Method will typically include ways of presenting instructional materials or conducting instructional activities, patterns of learner-to-learner and learner-to-instructor interactions, and mechanisms by which group and individual levels of learning are measured. Instructional methods include all aspects of the instruction and learning processes from planning and implementation through evaluation and feedback.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Best practice is to use terms from controlled vocabularies, whether developed for the use of a particular project or in general use in an educational context.<br />
<br />
''Examples:''<br />
<br />
<blockquote>InstructionalMethod="Experiential learning"<br /> InstructionalMethod="Observation"<br /> InstructionalMethod="Large Group instruction"</blockquote><br />
<br />
===4.20. AccrualMethod===<br />
<br />
''Label: Accrual Method''<br />
<br />
''Element Description:'' The method by which items are added to a collection. Recommended best practice is to use a value from a controlled vocabulary.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.<br />
<br />
''Examples:''<br />
<br />
<blockquote>AccrualMethod="Deposit"<br /> AccrualMethod="Purchase"</blockquote><br />
<br />
===4.21. AccrualPeriodicity===<br />
<br />
''Label: Accrual Periodicity''<br />
<br />
''Element Description:'' The frequency with which items are added to a collection. Recommended best practice is to use a value from a controlled vocabulary.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.<br />
<br />
''Examples:''<br />
<br />
<blockquote>AccrualPeriodicity="Annual"<br /> AccrualPeriodicity="Irregular"</blockquote><br />
<br />
===4.22. AccrualPolicy===<br />
<br />
''Label: Accrual Policy''<br />
<br />
''Element Description:'' The policy governing the addition of items to a collection. Recommended best practice is to use a value from a controlled vocabulary.<br />
<br />
''Guidelines for content creation:''<br />
<br />
Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.<br />
<br />
''Examples:''<br />
<br />
<blockquote>AccrualPolicy="Active"<br /> AccrualPolicy="Closed"</blockquote><br />
----<br />
<br />
<br />
Errata<br />
<br />
2006-02-07: Corrected spelling (s/Languge/Language/)<br />
2006-08-28, Errata: 'Type="Interactive Resource"' changed to 'Type="InteractiveResource"' in Section 4.4.<br />
<br />
----<br />
<br />
<br />
=Using Dublin Core - Dublin Core Qualifiers=<br />
<br />
==5. Dublin Core Qualifiers==<br />
<br />
This document presents in part the results of an ongoing process to develop exemplary terms extending or refining the original 15 elements of the Dublin Core Metadata Element Set ([http://dublincore.org/documents/dces/ DCMES]). The terms or "qualifiers" listed here were identified, generally in working groups of the Dublin Core Metadata Initiative, ([http://dublincore.org/ DCMI]) and judged by the [http://dublincore.org/usage/ DCMI Usage Board] to be in conformance with principles of good practice for the qualification of Dublin Core metadata elements.<br />
<br />
In determining the makeup of these qualifiers, preference was given to vocabularies, notations, and terms already maintained by established agencies. It should be emphasized that the list of externally-maintained vocabularies identified here is a preliminary list. There are many more controlled vocabularies or classification systems that are not on this list. Detail on currently recommended schemes are listed at: [http://dublincore.org/documents/dcmi-terms/#H4 DCMI Encoding Schemes - a current list]<br />
<br />
Inevitably, there will be situations where an agent or client will encounter DCMES descriptions that use unfamiliar qualifiers developed by implementors for specialized local or domain-specific needs. The useful interpretation of such a DCMES description will depend on the ability of an application to ignore the unknown qualifiers and fall back on the broader meaning of the element in its unqualified form. The guiding principle for the qualification of Dublin Core elements, colloquially known as the "Dumb-Down Principle," is that a client should be able to ignore any qualifier and use the information as if it were unqualified. While this may result in some loss of specificity, the remaining element value (without the qualifier) should continue to be generally correct and useful for discovery.<br />
<br />
It is expected that implementors will develop additional qualifiers for use within local applications or specific domains. Such qualifiers may not be understood by other applications. However, qualifiers that conform to the principles of qualification defined here are more likely to be reusable by other communities within the broader context of cross-domain discovery.<br />
<br />
At the time of the ratification of this document, the DCMI recognizes two broad classes of qualifiers:<br />
<br />
* '''Element Refinement.''' These qualifiers make the meaning of an element narrower or more specific. A refined element shares the meaning of the unqualified element, but with a more restricted scope. A client that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. The definitions of element refinement terms for qualifiers must be publicly available.<br />
* '''Encoding Scheme.''' These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value expressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., "2000-01-01" as the standard expression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. The definitive description of an encoding scheme for qualifiers must be clearly identified and available for public use.<br />
<br />
All of the qualifiers listed in this document fall into one of these two categories. Specific guidance is given below for element refinements. If a particular encoding scheme is available for the element and or/element refinement, its application is generally described either in this document or in documentation available with the encoding scheme itself. Audience, Provenance and RightsHolder, which are at the element level but not one of the original 15 elements, are described along with the other elements.<br />
<br />
Additional qualifier categories may evolve over time and with implementation experience. The qualifiers listed here do not constitute a closed set, designed to meet all of the descriptive needs of implementors. Rather, they form the foundation for a larger body of qualifiers that will evolve as additional qualifiers are developed by various communities, some of which may eventually be submitted to the DCMI Usage Board for review and approval. Implementors may deploy the qualifiers on these lists with confidence that they conform to the Dumb-Down Principle, and are encouraged to use these qualifiers as examples to guide development of local qualifiers for Dublin Core metadata elements.<br />
<br />
===Summary Refinement and Scheme Table===<br />
<br />
This summary of the element refinements and schemes is provided for the convenience of users. Terms in this summary may have the status of "recommended" or "conforming." The reference definitions and status indications may be found in [http://dublincore.org/documents/dcmi-terms/ DCMI Terms]. Click on the term to go directly to the reference definition for that term.<br />
<br />
{| class="border"<br />
! DCMES Element<br />
! Element Refinement(s)<br />
! Element Encoding Scheme(s)<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#title Title]<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#alternative Alternative]<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#creator Creator]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#subject Subject]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 LCSH]<br />[http://dublincore.org/documents/dcmi-terms/#H4 MeSH]<br />[http://dublincore.org/documents/dcmi-terms/#H4 DDC]<br />[http://dublincore.org/documents/dcmi-terms/#H4 LCC]<br />[http://dublincore.org/documents/dcmi-terms/#H4 UDC]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#description Description]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#tableOfContents Table Of Contents]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#abstract Abstract]<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#publisher Publisher]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#contributor Contributor]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#date Date]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#created Created]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#valid Valid]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#available Available]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#issued Issued]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#modified Modified]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#dateAccepted Date Accepted] [http://dublincore.org/documents/usageguide/qualifiers.shtml#dateCopyrighted Date Copyrighted]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#dateSubmitted Date Submitted]<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 DCMI Period]<br />[http://dublincore.org/documents/dcmi-terms/#H4 W3C-DTF]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#type Type]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-type-vocabulary/ DCMI Type Vocabulary]<br />
|-<br />
| rowspan="3" |<br />
[http://dublincore.org/documents/usageguide/elements.shtml#format Format]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 IMT]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#extent Extent]<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#medium Medium]<br />
| -<br />
|-<br />
| rowspan="2" |<br />
[http://dublincore.org/documents/usageguide/elements.shtml#identifier Identifier]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 URI]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#bibliographicCitation Bibliographic Citation]<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#source Source]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 URI]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#language Language]<br />
| -<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 ISO 639-2][http://dublincore.org/documents/dcmi-terms/#H4 RFC 3066]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#relation Relation]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#isVersionOf Is Version Of]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#hasVersion Has Version]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#isReplacedBy Is Replaced By]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#replaces Replaces]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#isRequiredBy Is Required By]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#requires Requires]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#isPartOf Is Part Of]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#hasPart Has Part]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#isReferencedBy Is Referenced By]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#references References]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#isFormatOf Is Format Of]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#hasFormat Has Format]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#conformsTo Conforms To]<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 URI]<br />
|-<br />
| rowspan="2" |<br />
[http://dublincore.org/documents/usageguide/elements.shtml#coverage Coverage]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#spatial Spatial]<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 DCMI Point]<br />[http://dublincore.org/documents/dcmi-terms/#H4 ISO 3166]<br />[http://dublincore.org/documents/dcmi-terms/#H4 DCMI Box]<br />[http://dublincore.org/documents/dcmi-terms/#H4 TGN]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#temporal Temporal]<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 DCMI Period]<br />[http://dublincore.org/documents/dcmi-terms/#H4 W3C-DTF]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#rights Rights]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#accessRights Access Rights]<br />
| -<br />
|-<br />
| <br /><br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#license License]<br />
|<br />
[http://dublincore.org/documents/dcmi-terms/#H4 URI]<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#audience Audience]<br />
|<br />
[http://dublincore.org/documents/usageguide/qualifiers.shtml#mediator Mediator]<br />[http://dublincore.org/documents/usageguide/qualifiers.shtml#educationLevel Education Level]<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#provenance Provenance]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#rightsHolder Rights Holder]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#instructionalMethod Instructional Method]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#accrualMethod Accrual Method]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#accrualPeriodicity Accrual Periodicity]<br />
| -<br />
| -<br />
|-<br />
|<br />
[http://dublincore.org/documents/usageguide/elements.shtml#accrualPolicy Accrual Policy]<br />
| -<br />
| -<br />
|}<br />
<br />
===Properties of Dublin Core Qualifiers===<br />
<br />
Dublin Core qualifiers have the following properties:<br />
<br />
* '''Name:''' The unique token assigned to the qualifier.<br />
* '''Label:''' The human-readable label assigned to the qualifier.<br />
* '''Definition:''' A statement that represents the concept and essential nature of the qualifier.<br />
* '''Comment:''' Additional information associated with the qualifier (if available).<br />
* '''See Also:''' A link to more information about the qualifier (if available).<br />
<br />
For the up-to-date specification of all metadata terms maintained by the Dublin Core Metadata Initiative, including elements, element refinements, encoding schemes, and vocabulary terms (the DCMI Type Vocabulary), see http://dublincore.org/documents/dcmi-terms/. In the listing below, the Name and Label attributes are the same as in the specification, but the Definition and Comment appear together as "Term Description", and guidance and examples are added.<br />
<br />
===Multiple Language Encodings of Dublin Core Entities===<br />
<br />
Dublin Core qualifiers will be expressed in languages other than English. A single invariant token assigned to each qualifier -- the Name property -- stands for a given qualifier concept irrespective of the language in which it is defined. This token can be incorporated into a URI to form a unique identifier for the qualifier. All other properties of a qualifier (Label, Definition, Comment, and aspects of See Also as appropriate) can be translated from English into any other language.<br />
<br />
All other properties of Dublin Core entities (Label, Definition, Comment, and aspects of See Also as appropriate) will be expressed in the language and character set of the translation.<br />
<br />
==Element Refinements==<br />
<br />
These element refinement terms are extensions to the "Simple Dublin Core" 15 elements or to the additional element terms Audience, Provenance and RightsHolder.<br />
<br />
===Refinement(s) for element: Title===<br />
<br />
'''Alternative'''<br />
<br />
''Label: Alternative''<br />
<br />
''Term description:'' Any form of the title used as a substitute or alternative to the formal title of the resource. This qualifier can include Title abbreviations as well as translations.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
An alternative title can be used to provide access to secondary titles, but should only be used when a value is present in the Title element.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Alternative="AMA newsletter" (Title="American Meteorological Association newsletter")<br />Alternative="Ocho semanas" (Title="Eight weeks")</blockquote><br />
<br />
===Refinement(s) for element: Description===<br />
<br />
'''tableOfContents'''<br />
<br />
''Label: Table of Contents''<br />
<br />
''Term description:'' A list of subunits of the content of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
When a description of a resource consists of a list of the contents, whether from a menu or other mechanism, tableOfContents can be used to differentiate this list from descriptive text that is written in sentence form. This allows more options for display and indexing.<br />
<br />
''Examples:''<br />
<br />
<blockquote>tableOfContents="Introduction; Vertebrates; Invertebrates; Molluscs"</blockquote><br />
<br />
'''Abstract'''<br />
<br />
''Label: Abstract''<br />
<br />
''Term description:'' A summary of the content of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Used when a description of a resource consists of a formal abstract. For implementations where formal abstracts are preferred, using the specific term allows the label to better reflect the level of the description.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Abstract="This article describes the work of the IFB Chaos Committee, including a summary of its major findings."</blockquote><br />
<br />
===Refinement(s) for element: Date===<br />
<br />
Date refinements are generally useful in situations where more than one date is needed, and the difference between the dates may be important to users. Note that the first five Date refinement terms were among the earlier ones approved by DCMI, and the naming convention of the time was not to include "date" as part of the refined term. The most recent ones reflect changes in the naming convention used, in which the name of the refined term expresses more clearly the relationship to the parent element. When using date refinements it can be unwise to insert a text string that repeats the distinction created by the refinement itself. For instance, the string "Valid 20010211" in a statement where the refinement "valid" is used might show up in a labelled display as: VALID: Valid 20010211.<br />
<br />
'''Created'''<br />
<br />
''Label: Created''<br />
<br />
''Term description:'' Date of creation of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If the date of creation of the resource is known, and that date is important to note specifically (e.g., there are other relevant dates to record), use the term Created for the creation date of the resource. Note that the "one-to-one" rule requires that the creation date be that of the resource being described, not any early version from which the current resource is derived.<br />
<br />
'''Valid'''<br />
<br />
''Label: Valid''<br />
<br />
''Term description:'' Date (often a range) of validity of a resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If the resource is only valid or relevant for a particular date or range of dates, the term Valid may be used to express those dates. This may be particularly important if the resource will be retained over time but its use is valid only during a particular period or until a particular date.<br />
<br />
'''Available'''<br />
<br />
''Label: Available''<br />
<br />
''Term description:'' Date (often a range) that the resource will become or did become available.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
In general, the term Available should be used in the case of a resource for which the date of availability may be distinct from the date of creation, and the date of availability is relevant to the use of the resource.<br />
<br />
'''Issued'''<br />
<br />
''Label: Issued''<br />
<br />
''Term description:'' Date of formal issuance (e.g., publication) of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
The term Issued should be applied when a formal date of issuance or publication is relevant to the resource, and is distinct from other dates that may be used with the resource.<br />
<br />
'''Modified'''<br />
<br />
''Label: Modified''<br />
<br />
''Term description:'' Date on which the resource was changed.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Modified dates may be used to record either all instances of modification or only the latest. When only one modified date is recorded, it is assumed to be the latest.<br />
<br />
'''dateAccepted'''<br />
<br />
''Label: Date Accepted''<br />
<br />
''Term description:'' Date of acceptance of the resource (e.g. of thesis by university department, of article by journal, etc.).<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If, in the lifecycle of a resource, the date of acceptance by a formal body or entity is relevant to the use of the resource, dateAccepted may be used.<br />
<br />
'''dateCopyrighted'''<br />
<br />
''Label: Date Copyrighted''<br />
<br />
''Term description:'' Date of a statement of copyright.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If, in the lifecycle of a resource, the date of copyright is relevant to the use of the resource, dateCopyrighted may be used.<br />
<br />
'''dateSubmitted'''<br />
<br />
''Label: Date Submitted''<br />
<br />
''Term description:'' Date of submission of the resource (e.g. thesis, articles, etc.).<br />
<br />
''Guidelines for creation of content:''<br />
<br />
If, in the lifecycle of a resource, the date of submission to a body or entity is relevant to the use of the resource, dateSubmitted may be used.<br />
<br />
===Refinement(s) for element: Format===<br />
<br />
'''Extent'''<br />
<br />
''Label: Extent''<br />
<br />
''Term description:'' The size or duration of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Because the refinement Extent is used in a variety of situations, it generally consists of both a numeric value and a caption that is needed to interpret the numeric value. Best practice is to separate the numeric value and the caption with a space, whether the caption appears before or after the value.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Extent="folio"<br />Extent="899 Kb"<br />Extent="21 minutes"</blockquote><br />
<br />
'''Medium'''<br />
<br />
''Label: Medium''<br />
<br />
''Term description:'' The material or physical carrier of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Medium is generally used when the resource is of a physical nature, for instance a painting or model, where the physical carrier or material used is relevant to the user. For instance, if the resource is a movie on DVD, and is only available as a physical object, it should be described as such. If it is available digitally, for download or presentation on a website, its format would be reflected in the Format element. Note that, because of the physical nature of materials described with this refinement, the encoding scheme "IMT" is not valid for use with Medium.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Medium="cotton fabric with sequins"<br />Medium="bronze on wooden pedestal"<br />Medium="oil on wood"</blockquote><br />
<br />
===Refinement(s) for element: Relation===<br />
<br />
Most of the refinements of Relation are expressed as "reciprocals" and may be used to link resources in two directions, though this is not required. Implementors need not describe both or all resources involved in a reciprocal relationship to express the relationship--in other words, they may describe a later version and relate it to the earlier without having the need or opportunity to describe the earlier, and vice versa. In some of the relationships below, maintaining reciprocality is more important. In others, one direction of the relationship is more relevant that the other. These differences will be mentioned in the guidelines for specific terms.<br />
<br />
In All cases, either a string or a URI may be used as a value. If a URI is used, the scheme should be designated.<br />
<br />
Examples for Relation refinements can be found with the [http://dublincore.org/documents/usageguide/elements.shtml#relation Relation element]. When using Relation refinements, do not use embedded text labels, as the examples illustrate.<br />
<br />
'''isVersionOf'''<br />
<br />
''Label: Is Version Of''<br />
<br />
''Term description:'' The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Use only in cases where the relationship expressed is at the content level. Relationships need not be close for the relationship to be relevant. "West Side Story" is a version of "Romeo and Juliet" and that may be important enough in the context of the resource description to be expressed using isVersionOf. The Broadway Show and the movie of "West Side Story" also relate at a similar level, but the video and DVD of the movie are more usefully expressed at the level of format, the content being essentially the same.<br />
<br />
See also [http://dublincore.org/documents/usageguide/qualifiers.shtml#isFormatOf isFormatOf].<br />
<br />
'''hasVersion'''<br />
<br />
''Label: Has Version''<br />
<br />
''Term description:'' The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isVersionOf isVersionOf] for basic guidelines.<br />
<br />
'''isReplacedBy'''<br />
<br />
''Label: Is Replaced By''<br />
<br />
''Term description:'' The described resource is supplanted, displaced, or superseded by the referenced resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
When establishing a chain of versions, where only one version is valid, the use of isReplacedBy and Replaces allows the relationship to be expressed and the user directed to the appropriate version. In this case, the reciprocal relationships are quite important.<br />
<br />
'''Replaces'''<br />
<br />
''Label: Replaces''<br />
<br />
''Term description:'' The described resource supplants, displaces, or supersedes the referenced resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isReplacedBy isReplacedBy] for basic guidelines.<br />
<br />
'''isRequiredBy'''<br />
<br />
''Label: Is Required By''<br />
<br />
''Term description:'' The described resource is required by the referenced resource, either physically or logically.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
In the case of IsRequiredBy and Requires, there is a clearer need to express the Requires relationship than the IsRequiredBy, though both can be useful. This relationship is most often seen in relationships between software and documents or applications and hardware and/or software requirements.<br />
<br />
'''Requires'''<br />
<br />
''Label: Requires''<br />
<br />
''Term description:'' The described resource requires the referenced resource to support its function, delivery, or coherence of content.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isRequiredBy isRequiredBy] for basic guidelines.<br />
<br />
'''isPartOf'''<br />
<br />
''Label: Is Part Of''<br />
<br />
''Term description:'' The described resource is a physical or logical part of the referenced resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
The isPartOf and hasPart relationships are essentially "parent/child" relationships--hierarchical in nature. With them can be expressed both one-to-one and one-to-many types of relationships.<br />
<br />
'''hasPart'''<br />
<br />
''Label: Has Part''<br />
<br />
T''erm description:'' The described resource includes the referenced resource either physically or logically.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isPartOf isPartOf] for basic guidelines.<br />
<br />
'''isReferencedBy'''<br />
<br />
''Label: Is Referenced By''<br />
<br />
''Term description:'' The described resource is referenced, cited, or otherwise pointed to by the referenced resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
The isReferencedBy and References refinements enable the expression of relationships that aid the user but are not necessary tied to the lifecycle or necessary for the intended use of the resource. This relationship might be used to link an article critical of a resource to that resource, a satire of a speech to the original speech, etc.<br />
<br />
'''References'''<br />
<br />
''Label: References''<br />
<br />
''Term description:'' The described resource references, cites, or otherwise points to the referenced resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isReferencedBy isReferencedBy] for basic guidelines.<br />
<br />
'''isFormatOf'''<br />
<br />
''Label: Is Format Of''<br />
<br />
''Term description:'' The described resource is the same intellectual content of the referenced resource, but presented in another format.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
This relationship is explicitly for the expression of relationships between resources for which format is the primary variable. Because Dublin Core maintains the principle of "one-to-one," each resource is expected to have its own description.<br />
<br />
See also [http://dublincore.org/documents/usageguide/qualifiers.shtml#isVersionOf isVersionOf].<br />
<br />
'''hasFormat'''<br />
<br />
''Label: Has Format''<br />
<br />
''Term description:'' The described resource pre-existed the referenced resource, which is essentially the same intellectual content presented in another format.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
See [http://dublincore.org/documents/usageguide/qualifiers.shtml#isFormatOf isFormatOf] for basic guidelines.<br />
<br />
'''conformsTo'''<br />
<br />
''Label: Conforms To''<br />
<br />
''Term description:'' A reference to an established standard to which the resource conforms.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
The standards referenced might be educational standards, accessibility standards, or any other established standard that is relevant to the use of the resource.<br />
<br />
===Refinement(s) for element: Coverage===<br />
<br />
'''Spatial'''<br />
<br />
''Label: Spatial''<br />
<br />
''Term description:'' Spatial characteristics of the intellectual content of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Spatial characteristics may include geographic names, latitude/longitude, or other established georeferenced values. Clearly, this refinement does not allow complex or sophisticated georeferencing, but attention to standard schemes and controlled vocabularies should provide useful results. Controlled vocabulary terms can be drawn from recommended vocabularies, or standard labelling within the value can provide useful assistance to users and applications. For additional information on encoding spatial information see the [http://dublincore.org/documents/dcmi-box/ DCMI Box Encoding Scheme] and the [http://dublincore.org/documents/dcmi-point/ DCMI Point Encoding Scheme].<br />
<br />
''Examples:''<br />
<br />
<blockquote>Spatial="Chicago, Ill."<br />Spatial="Lat: 44 00 00 S Long: 068 00 00 W Name: Patagonia"<br />Spatial="Upstate New York"</blockquote><br />
<br />
'''Temporal'''<br />
<br />
''Label: Temporal''<br />
<br />
''Term description:'' Temporal characteristics of the intellectual content of the resource.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Temporal characteristics include those aspects of time that relate to the intellectual content of a resource and not its lifecycle. Examples might include a resource describing some aspect of the 19th century but itself created this year. In that case, the Temporal Coverage would be the 19th century, and the Date (or Date Created) would be 2003. Values can be text strings or encoded values. Specific suggestions for encoding Temporal characteristics may be found in the [http://dublincore.org/documents/dcmi-period/ DCMI Period Encoding Scheme.]<br />
<br />
''Examples:''<br />
<br />
<blockquote>Temporal="Jurassic Period"<br />Temporal="1922-1978"<br />Temporal="Twentieth Century"</blockquote><br />
<br />
===Refinement(s) for element: Audience===<br />
<br />
'''Mediator'''<br />
<br />
''Label: Mediator''<br />
<br />
''Term description:'' A class of entity that mediates access to the resource and for whom the resource is intended or useful. The audiences for a resource are of two basic classes: (1) an ultimate beneficiary of the resource, and (2) frequently, an entity that mediates access to the resource. The mediator element refinement represents the second of these two classes.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
In an educational setting, a teacher might be designated the Mediator for a resource intended for use by a teacher in a classroom of students of a particular level or sharing other similar characteristics. Resources intended to be used directly by those same students would not include a Mediator. Mediators may be expressed in more or less specific terms, depending on the needs of the implementation. Controlled vocabularies can be useful in distinguishing Mediators.<br />
<br />
''Examples:''<br />
<br />
<blockquote>Mediator="Reading specialist"<br />Mediator="ESL teachers"</blockquote><br />
<br />
'''educationLevel'''<br />
<br />
''Label: Education Level''<br />
<br />
''Term description:'' A general statement describing the education or training context. Alternatively, a more specific statement of the location of the audience in terms of its progression through an education or training context.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Commonly, this term would be used for a grade level for materials intended for an educational setting. Although no specific controlled vocabulary has been recommended for use with educationLevel, consistent use of terminology or reliance on an available controlled vocabulary enables more consistent results.<br />
<br />
''Examples:''<br />
<br />
<blockquote>educationLevel="elementary school students"<br />educationLevel="4th-5th grade"<br />educationLevel="secondary science"</blockquote><br />
<br />
===Refinement(s) for element: Rights===<br />
<br />
'''accessRights'''<br />
<br />
''Label: Access Rights''<br />
<br />
''Term description:'' Information about who can access the resource or an indication of its security status. Access Rights may include information regarding access or restrictions based on privacy, security or other regulations.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Access rights is intended to allow the characterization of restrictions to view, search or use resources, based on attributes of the resource itself or the class or category of user. An example would be a resource that was restricted to users holding a particular security clearance, or one that required login or authentication at a particular website.<br />
<br />
''Examples:''<br />
<br />
<blockquote>accessRights="Available to subscribers only."<br />accessRights="Viewable by Medium security cleared staff only."</blockquote><br />
<br />
'''license'''<br />
<br />
''Label: License''<br />
<br />
''Term description:'' A legal document giving official permission to do something with the resource. Recommended best practice is to identify the license using a URI. Examples of such licenses can be found at http://creativecommons.org/licenses/.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
License is designed to allow the inclusion of specific licensed uses to be specified. An example would be a resource that was available to be used freely but not for reproduction within commercial applications.<br />
<br />
''Examples:''<br />
<br />
<blockquote>license="http://creativecommons.org/licenses/by-nc-nd/2.0/ legalcode"<br />license="Licensed for use under Creative Commons Attribution 2.0."</blockquote><br />
<br />
===Refinement(s) for element: Identifier===<br />
<br />
'''bibliographicCitation'''<br />
<br />
''Label: Bibliographic Citation''<br />
<br />
''Term description:'' A bibliographic reference for the resource. Recommended practice is to include sufficient bibliographic detail to identify the resource as unambiguously as possible, whether or not the citation is in a standard form.<br />
<br />
''Guidelines for creation of content:''<br />
<br />
Because this term is not describing a relationship to another resource, it should be limited to citations to the resource described in the remainder of the record. For instance, if the resource is an article for a journal, it is appropriate to include very specific information about the article, even page references, if such information is used to cite the article in a standard format for reference by other resources, ''even if the article being described is in a digital format''.<br />
<br />
''Examples:''<br />
<br />
<blockquote>bibliographicCitation="ESOP, v.2, no. 1, Apr. 2003, p. 5-8"<br />bibliographicCitation="Nature, v.87, p. 200"</blockquote><br />
<br />
For additional guidance on using this refinement, see: [http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core.]<br />
<br />
<br />
=Using Dublin Core - Appendix, Roles=<br />
<br />
==6. Using Agent Roles in Dublin Core==<br />
<br />
===Introduction===<br />
<br />
MARC Relator terms are properties used to describe the relationship of an agent to a resource by specifying the particular nature of the relationship. They can be used to describe the various roles people and organizations play in the development and use of a resource. The property "Illustrator", for example, can be used for an agent which provided illustrations for the resource.<br />
<br />
In Dublin Core, agent roles are expressed as properties (i.e., elements or element refinements). As explained below, most are refinements of the element dc:contributor. In order to identify a subset of MARC Relator Terms as refinements of dc:contributor, DCMI and the Library of Congress cooperated on the evaluation of all (circa) 150 MARC Relator Terms with regard to whether they represented "an entity responsible for making contributions to the content of the resource."<br />
<br />
===The MARC Relator List: What It Is and How It's Structured===<br />
<br />
The MARC Code List for Relators was developed for use in MARC 21 bibliographic records to express the relationship between a name and a work. The list includes both role terms and three-character codes representing those terms. The terms were only included on the list when the name and its associated role were considered important enough to include on a bibliographic record as an access point. The Library of Congress is the maintenance agency for this list and regularly adds new terms when a need is expressed and documented. The agreement between DCMI and the Library of Congress specifies that new terms submitted to LC will be referred to the DCMI Usage Board for endorsement of sub-property relationships asserted with regard to Dublin Core elements. This agreement is described in the Web document [http://dublincore.org/usage/documents/relators/ "MARC Relator Terms and Dublin Core"].<br />
<br />
The MARC Relator list includes three-character alphabetic codes to be used to identify roles. In addition the list provides definitions for the terms (and associated codes). In MARC records, the codes are synonyms for the term they represent. In DC metadata descriptions, properties are referred to using unique identifiers (URIs), and the codes were used to form unique identifiers for these properties. The list of MARC Relator Terms is maintained by the Library of Congress, so the terms have been assigned URIs on the basis of a namespace established by LC. Schemas or instance metadata will need to cite these URIs (or the MARC relator namespace) in order to use any of the MARC Relator properties, be they sub-properties of Dublin Core elements or not. See the document "Guidelines for Implementing Dublin Core in XML" for specific information on using non-DCMI namespaces.<br />
<br />
In addition to providing Web documentation of the MARC Relator Terms, the Library of Congress provides a representation of the MARC Relator Terms in RDF/XML. Refinements of dc:contributor are, in the RDF/XML representation, asserted to be sub-properties of dc:contributor. In RDF/XML, this is done as follows:<br />
<br />
<br />
<rdf:Description rdf:about="http://www.loc.gov/loc.terms/relators/ILL"><br />
<rdfs:subPropertyOf<br />
rdf:resource="http://purl.org/dc/elements/1.1/contributor" /><br />
</rdf:Description><br />
<br />
In determining whether a sub-property relationship was to be asserted, LC and the Usage Board took a fairly narrow view. The relationship was asserted only if the contribution was judged to apply, by its nature, to the content of the resource. For example, whether or not "binder" is to be considered a sub-property of dc:contributor depends on the nature of the resource. Where the resource in question is valued as an art object, a binder may be construed as a "contributor" to its content; in other cases, the binder may not have this role.<br />
<br />
===Roles as refinements of Dublin Core elements===<br />
<br />
A subset of MARC Relator Terms have been identified as refinements of dc:contributor. The MARC Relator term marcrel:CRE (Creator) is asserted to be a sub-property of both dc:creator and dc:contributor. In a few cases, MARC Relator terms are considered to be refinements of Dublin Core elements other than dc:contributor. The MARC Relator terms marcrel:PBL (Publisher) and marcrel:DST (Distributor) are considered refinements of dc:publisher, as a publisher may or may not also be a "contributor" to the resource. The term marcrel:DPC (Depicted) is considered a sub-property of dc:subject.<br />
<br />
Because roles are generally used with dc:contributor, appropriate "Dumb Down" of most agent refinements in the MARC Relator subset will be to dc:contributor, with exceptions noted above. Implementors may choose to describe "creators" using either marcrel:CRE (which will dumb down both to dc:creator and dc:contributor) or dc:creator (which will remain distinct from dc:contributor in Simple Dublin Core).<br />
<br />
A document with further examples of refinement relationships and Dumb Down, along with examples of usage in XML, XHTML and RDF/XML, can be found at: http://www.ukoln.ac.uk/metadata/dcmi/marcrel-ex/.<br />
<br />
===Terms Not on the MARC Relators List===<br />
<br />
The MARC Relator list has been developed over many years to meet a wide variety of needs. New terms are added on the basis of need, and LC has expressed willingness to continue to expand the list upon request. Implementers also have the option to create and expose alternative vocabularies for the expression of other kinds of roles not reflected in the MARC Relator list.<br />
<br />
For those implementations wishing to use terms from the MARC relators list that do not have a sub-property relationship to Dublin Core elements, it should be noted that an implementation may use such terms with no intrinsic harm to interoperability by using them directly, as elements, in their metadata. In the context of a Dublin Core record based on an application profile using MARC relator terms, roles not on the list as valid sub-properties endorsed by DCMI could be used in a Qualified DC expression, but not in a Simple DC expression.<br />
<br />
===Managing the Use of Role in an Implementation===<br />
<br />
The full MARC Relator list includes approximately 150 separate terms for various roles. A subset includes sub-property relationships with DC elements endorsed by DCMI. Even within this subset some of the relator terms on the list were created for specific domains and would be of little use in other communities. It might therefore be useful for implementations to declare a further subset of the relator vocabulary as relevant to their specific goals, preferably by way of a formal application profile.<br />
<br />
The full list of MARC Relator Terms (including refinements of Dublin Core elements): http://www.loc.gov/loc.terms/relators/<br />
<br />
The subset of MARC Relator Terms which refine Dublin Core terms: http://www.loc.gov/loc.terms/relators/dc-contributor.html<br />
<br />
The RDF representation of MARC Relator Terms: http://www.loc.gov/loc.terms/relators/dc-relators.xml<br />
<br />
For further information, see "MARC Relator Terms and Dublin Core" [http://dublincore.org/usage/documents/relators/ http://dublincore.org/usage/documents/relators/].<br />
<br />
----<br />
<br />
2005-01-16, Errata: broken link repaired.</div>Dianehttp://wiki.metadataregistry.org/Aug._13,_2007Aug. 13, 20072007-08-12T21:29:06Z<p>Diane: </p>
<hr />
<div>* INTEROP status reports<br />
* Registry beta progress (Jon)</div>Sasuttonhttp://wiki.metadataregistry.org/Aug._8,_2007Aug. 8, 20072007-08-07T20:36:43Z<p>Diane: </p>
<hr />
<div>* TERMS proposal Cornell wrap-up<br />
** Time to involve Tom Frank<br />
*** Approve budget & budget justification<br />
*** Approve statement of work<br />
* RDA proposal<br />
** Need review eyeballs on the draft<br />
** Budget is progressing<br />
* Singapore issues<br />
** DC-Ed?</div>Sasuttonhttp://wiki.metadataregistry.org/Telecon:_Corey_Harper,_Dan_Eshom,_DianeTelecon: Corey Harper, Dan Eshom, Diane2007-08-07T16:07:13Z<p>Diane: </p>
<hr />
<div>===Telecon: Corey Harper, Dan Eshom, Diane & Jon, August 7, 2007===<br />
<br />
Agenda & Notes:<br />
<br />
#DCMI Issues:<br />
#*Documentation contract: Where are we? What comes next? What are the implications for "Using Dublin Core"<br />
#**Current website evaluation and document evaluation project should be finished by mid-Sept. Not clear whether Jon & Diane will bid for "Fixing" contract--depends on whether other ships come in. Diane not anxious to update "Using DC" until wiki is enabled.<br />
#*Updates on DCMI-flavored grant proposals <br />
#** Two proposals going to NSF INTEROP: one to bring legacy vocabularies onto the web, the other to build a community around the RDA Vocabularies.<br />
#NSDL issues<br />
#*How can we improve the visibility and usefulness of the NSDL Registry within the NSDL? <br />
#*What happens to the Registry if we don't get funding?<br />
#*Is there any opportunity coming up to engage the NSDL on the [http://dublincore.org/educationwiki/DC_2dEducation_20Application_20Profile DC-Ed Application Profile]? What are the implications for the nsdl_dc schema? <br />
#Singapore<br />
#*Who will be there? What are the opportunities for furthering discussion?<br />
#Other issues:<br />
#*Reports on the Open Registries Forum? Any issues need follow up?</div>Dianehttp://wiki.metadataregistry.org/Telecon:_Corey_Harper,_Dan_Eshom,_Diane_%26_JonTelecon: Corey Harper, Dan Eshom, Diane & Jon2007-08-07T16:05:00Z<p>Diane: New page: ===Telecon: Corey Harper, Dan Eshom, Diane & Jon, August 7, 2007=== Agenda & Notes: #DCMI Issues: #*Documentation contract: Where are we? What comes next? What are the implications for "...</p>
<hr />
<div>===Telecon: Corey Harper, Dan Eshom, Diane & Jon, August 7, 2007===<br />
<br />
Agenda & Notes:<br />
<br />
#DCMI Issues:<br />
#*Documentation contract: Where are we? What comes next? What are the implications for "Using Dublin Core"<br />
#*Updates on DCMI-flavored grant proposals <br />
#NSDL issues<br />
#*How can we improve the visibility and usefulness of the NSDL Registry within the NSDL?<br />
#*Is there any opportunity coming up to engage the NSDL on the DC-Ed Application Profile? What are the implications for the nsdl_dc schema? <br />
#Singapore<br />
#*Who will be there? What are the opportunities for furthering discussion?<br />
#Other issues:<br />
#*Reports on the Open Registries Forum? Any issues need follow up?</div>Dianehttp://wiki.metadataregistry.org/July_30,_2007July 30, 20072007-08-01T14:46:23Z<p>Diane: </p>
<hr />
<div>* INTEROP proposal status<br />
** TERMS<br />
<br />
Stuart is working on the one pager and will incorporate Stu's text on FAST.<br />
** RDA</div>Sasuttonhttp://wiki.metadataregistry.org/July_23,_2007July 23, 20072007-07-24T11:32:48Z<p>Diane: </p>
<hr />
<div>===Agenda and Notes, July 27, 2007===<br />
<br />
1. Short discussion of the DCMI documentation contract, with suggestions for the new Conference papers site (Jon & Diane)<br />
<br />
* '''Action Item:''' Jon and Stuart will work out the details on how to get Google Analytics set up for the conference papers site.<br />
<br />
2. Update on the TERMS Proposal work (Stuart)<br />
<br />
* We need a tangible outcome for the project, probably something more generalized than use of our Registry. Maybe one thing would be use of the cookbook. Large vocabularies must have functional URLs, etc.<br />
* Budget: Alpha has been in touch with the OCLC person who has Stu's data. <br />
<br />
* '''Action Item:''' Diane will update Stuart on changes in her and Jon's base salaries, he will send the spreadsheet to Diane.<br />
<br />
3. Update on the RDA Proposal work (Diane)<br />
<br />
4. Registry move to commercial hosting (Jon)<br />
* Jon explained the reasoning behind moving to DreamHost, and what kinds of problems he's been having getting the site moved.<br />
<br />
5. Stuart talked about the NSDL telecon he "attended" about the issues of cooperation between the Pathways and ASN to move forward on correlation etc. Stuart is working on the "correlation entity" using some of the NSDL records as examples to establish some way for use this for NSDL. He will write up the documentation and include pictures for the DC-Ed effort.<br />
<br />
Next meeting is Wed. Aug. 1, 2007 at 8:00 Pacific/11:00 Eastern.</div>Dianehttp://wiki.metadataregistry.org/July_16,_2007July 16, 20072007-07-15T22:06:43Z<p>Diane: </p>
<hr />
<div># Status of registry implementation--End: 9/30/07 (Report 10/1/07)<br />
#* To be accomplished<br />
#** history<br />
#*** 80% done<br />
#** versioning<br />
#*** time-slice vocabulary and concept retrieval<br />
#*** named versions based on time-slice UI and retrieval<br />
#** notification<br />
#*** RSS, Atom feeds and email<br />
#*** UI still needed<br />
#** user management<br />
#*** 50% done<br />
#** Import<br />
#*** SKOS, CSV, RDF Ontology<br />
#* Not to be accomplished<br />
#** Metadata Schema registration<br />
#** Application Profile registration<br />
#* '''Action Items''': <br />
#** Set up wiki template for the Final Report {Stuart}<br />
#** Send Stuart an email with some suggestions for software license for the Registry {Jon}<br />
#** Determine what license we should use so we can add add that to our site and specs {Stuart}<br />
# Singapore<br />
#* DC-Ed Community<br />
#** AP modeling<br />
#**# Inclusion of 'authority' (related issues)<br />
#**# Will confirm that Mikael will be there and can discuss the issues of modularity, and whether the DC-Ed AP is a separate description or included in the resource description itself.<br />
#**# Correlation as related resource<br />
#**#* Use of <tt>conformsTo</tt> or a new <tt>standardCorrelation</tt><br />
#** '''Action Items:''' <br />
#*** Re-do model, simple case {Stuart}<br />
#*** Think about paper on what's lacking in terms of provenance of statements {All}<br />
#* Registry Community<br />
#** Action item: Jon will prompt Emma to come up with the Agenda<br />
#* Advisory Board issues<br />
#** Conference location<br />
#** Conference proceedings and other publications<br />
#**# Publication form for DCMI conference proceedings (online/print/CD)<br />
#**# Use of the OJS for publishing proceedings(housed at University of Washington)<br />
#**# Other publications<br />
#**#* ''DCMI Occasional Papers''<br />
# Document/presentation inventory needed for Singapore<br />
#* Proposal document for permanent publishing of DCMI conference proceedings using the OJS {Stuart & Joe}<br />
#* Proposal document for ongoing publication of a new ''DCMI Occasional Papers'' series {Stuart}<br />
#* Proposal document for DCMI conference venues (U.S. & Europe) with educational efforts in other regions {Diane & Stuart}<br />
#* Presentation of correlation resource {Stuart}<br />
#* Presentation on 'authority' in general(?){Diane & Jon}<br />
#* Paper presentation {Diane}<br />
# Other matters<br />
#* Usage Board: <br />
#** VES/SES {Stuart & Joe}<br />
#** Shepherding the DCMES term changes {Diane}<br />
#** ...</div>Sasuttonhttp://wiki.metadataregistry.org/June_18,_2007June 18, 20072007-06-18T13:14:30Z<p>Jon: </p>
<hr />
<div>=== Agenda and Notes, June 18, 2007 ===<br />
<br />
1. Diane shared a new document on the possibility of an NSF proposal to work on a maintenance plan and entity for RDA. It should be noted that it has some effort in there for the Registry.<br />
<br />
2. Jon's new Dutch penpal.<br />
Lourens van der Meij<br />
STITCH project: http://stitch.cs.vu.nl <br />
<br />
3. Getting TERMS going? (Tom wants to use skype--what's his skype name? Mine is dihillmann)<br />
tbaker9957<br />
<br />
4. DCMI Website [http://managemetadata.org/dcmi/deliverable_1.html review documents] go up.</div>Dianehttp://wiki.metadataregistry.org/June_11,_2007June 11, 20072007-06-11T12:47:29Z<p>Diane: </p>
<hr />
<div>===Agenda & Notes, June 11, 2007===<br />
<br />
1. Wiki upgrade (Jon). We should discuss what we want to do with the new capabilities (if anything). Look [http://ontoworld.org/wiki/Help:Annotation here] for some stuff about what could be done.<br />
<br />
Jon explained that we were now on the most current version of MediaWiki with the Semantic MediaWiki plugin enabled. We should feel free to play with this (refer to the link above for instructions) and embed some metadata in the pages, for instance.<br />
<br />
2. Registry upgrades (See Jon's [http://metadataregistry.org/blog/2007/06/09/registry-update/ blog post] on the upgrades. Questions?<br />
<br />
We noted that the fixing of the bug ("too aggressive") did not allow the completion of the NSDL GEM Topics vocabulary. Diane has finished that, subsequently. Jon mentioned that he has another upgrade ready to go that allows status information to show up for properties as well as concepts. This will be necessary to allow for the kind of change management that we'd envisioned. He is also making it easier to support multiple languages--it will be possible to have multiple prefLabels in different languages and with different statuses. All prefLabels will then be status and language specific.<br />
<br />
3. Diane has used up some of her 15 minutes of fame: http://talk.talis.com/archives/2007/06/diane_hillmann.html<br />
<br />
4. Getting some momentum on the DC-Ed AP--I've put the text so far on Google docs. I'm particularly concerned about getting a model in there (not being much of a modeler myself)<br />
<br />
Stuart pointed out that mostly what we're talking about in "models" is a regular entity/relationship model. Because we're doing a modular thing, which is all about the resource. With the standard correlation object we might be adding a bit of complexity. The other bit of complexity is the "who" issue. So our model includes a resource entity, an agent entity and a correlation entity, also subject/genre. So far those have been handled as simple properties, Stuart thinks. We should check with the ePrints and see what they did. When you're talking about another URI it's really another entity. <br />
<br />
5. Terms effort--what can we do to get that going? Does the registry have a role? Can a re-imagined role provide a basis to make a proposal for the INTEROP money? <br />
<br />
We discussed the possibility of doing two proposals, one for the TERMS workshops and another for the Registry to support the RDA/DCMI work. Stuart will try and get a call set up before ALA, and Diane will get some ducks in a row to discuss a proposal with the RDA folks at ALA.<br />
<br />
6. Other?</div>Dianehttp://wiki.metadataregistry.org/June_4,_2007June 4, 20072007-06-04T13:09:21Z<p>Diane: </p>
<hr />
<div>===Agenda & Notes, June 4, 2007===<br />
<br />
1. Registry bug<br />
<br />
Bug that prevented adding some NSDL-GEM properties has been fixed and the properties corrected.<br />
<br />
2. "The Web as Registry"--how can we counter this? <br />
<br />
Stuart suggested a bulleted list describing necessary functionality for this project, past the "publication/declaration" stage. <br />
<br />
3. The paper: accepted, now re-edited?<br />
<br />
Diane will follow through on this. <br />
<br />
4. Any interest in reviewing the DCMI website evaluation documents?<br />
<br />
Stuart and Joe are interested in looking at what we're doing. <br />
<br />
Next week, same time and place.</div>Dianehttp://wiki.metadataregistry.org/May_29,_2007May 29, 20072007-05-29T12:13:21Z<p>Diane: </p>
<hr />
<div>===Agenda & Notes, May 29, 2007===<br />
<br />
1. Various updates on project work.<br />
* Jon has been making incremental changes and expects to have some of the change management stuff up in beta perhaps by next week. <br />
* Joe is moving back to Seattle. The ASSIST paper has been accepted and changes were sent off a few days ago. It should be published online fairly soon. <br />
* Stuart suggested that we need a DLib article, something with a more general reach and a bit less academic. He is in the middle of finishing the peer review for the Singapore papers. There will be about 11 papers, with a 44% acceptance rate. '''Action item:''' Stuart will set up a TERMS mailing list.<br />
* Diane reported on some of the DCMI/RDA work, which will likely be done by Alistair Miles and Karen Coyle. Tom Baker is working on the description of work. Diane is still planning to start the proposal for the DC AB on conference changes and educational focus. <br />
<br />
2. Can we finish the NSDL GEM vocabulary yet? Jon thinks he fixed that bug, and Diane will attempt to finish the registration. Stuart will tell Diane which terms he needs registered first. '''Action item:''' Diane will check and see what happened at the CI meeting in Ithaca (and also try and set up a time for Dan & Corey to visit Ithaca).<br />
<br />
3. Upcoming meetings:<br />
* ALA--anyone but Diane going?<br />
* Registry Forum--Anyone but Jon going?<br />
** http://metadataopenforum.org/index.php?id=3,0,0,1,0,0<br />
<br />
4. Singapore update? <br />
We agreed that the conference change proposals needed to go out to the AB list well before Singapore so that discussion could ensue even though Stuart (and probably others) would not be present. The Singaporeans will not pay registration for us, though they have agreed to pay all conference hotel and transportation. <br />
<br />
Our next telecon will be at the regular time on Monday, June 4, 8 am Pacific, 11 am Eastern.</div>Dianehttp://wiki.metadataregistry.org/May_21,_2007May 21, 20072007-05-15T13:34:09Z<p>Diane: </p>
<hr />
<div>===Agenda & Notes, May 21, 2007===<br />
<br />
1. Singapore DC2007 continued ...<br />
* Registries Community: Do we have anything we want to discuss/expose at that meeting? How can we support Emma as she moderates that meeting?<br />
* DC-Ed Community: Stuart wants to add an agenda item about the correlation entity he's working on. Should we include some of that in the DC-Ed application model?<br />
** Libraries AP reflects MARC view of the world, does not do what RDA work will attempt. DC-Ed has also been conceived as flat, but we agreed that we should move into a description set model. Need to express degrees of fit and "authority," also with pedagogy. Stuart pointed out that the new encodings (status unknown) should be able to handle that expression.<br /> <br />
'''Action item:''' Stuart will make a stab at a domain model.<br />
<br />
2. Licensing<br />
* We started talking about this a few months ago and dropped the thread. As our current funding runs out, we need to think about how to continue working on our projects under a different funding regime (more consulting than NSF?). In that mode we'll need to think about licensing, and we should prepare ourselves for that eventuality.<br /><br />
**GNU: http://www.gnu.org/copyleft/gpl.html<br /><br />
**Wikipedia Open Source License page: http://en.wikipedia.org/wiki/Open_source_licenses<br /><br />
**KOHA ILS (GNU License): http://www.koha.org/download/<br />
'''Action item:''' Stuart will make a recommendation.<br />
<br />
3. Conference and educational proposals to DCMI<br />
* Much of this fits in with the work Jon and Diane are doing with their contract for review of the DCMI Website. If we share some of that work with Joe and Stuart, would that help with a proposal? Diane has started some text on this, but hasn't gotten very far--should we convert it to a Google Doc and see what we can do?<br />
<br />
4. Next week's meeting <br />
* Monday is a holiday, can we do Tuesday instead? Will do Tuesday an hour before (10 Eastern, 7 Pacific).</div>Dianehttp://wiki.metadataregistry.org/May_14,_2007May 14, 20072007-05-14T14:20:50Z<p>Diane: </p>
<hr />
<div>===Agenda and Notes, May 14, 2007===<br />
<br />
1. "Catching up" reports: <br />
* Stuart: In the past round of funding NSDL extended funding on several standards projects, including ASN, WGBH (for its intermediary), DLESE, CNLP. They were supposed to be working together, using ASN as their data source for standards. The group committed to create a test collection of records with human reviewed correlations, so that the tools could be tested and evaluated. Stuart was trying to build a schema to express the correlation, using a correlation entity, and a vocabulary expressing strength of fit. The simple case is a "conformsTo" with a URI. More complex case you have strength of correlation, authority (who says), etc. CI didn't know what to do with the results, so called together a group to discuss this. Their contention was that they couldn't do anything outside of standard DC. For an illustration, Stuart tried plugging in URIs for some of the terms in DLESE records, to illustrate the complexity coming. They also demonstrated the CNLP tool that does standards mapping. Stuart asked where the URIs were coming from, and learned that CI was not using any of the Registry URIs for any of the vocabularies. Stuart will keep pushing these issues within CI. <br />
<br />
* Diane: London meeting, Chicago testimony, Rochester collaboration, TERMS proposal<br />
Stuart suggested that we might get Cliff to bring CNI in as a partner, and go to Mellon or one of the big funders. He thinks it should be a two-three year project.<br />
<br />
* Jon: Has been updating the backend, and fixing bugs. The sandbox has been very busy and they've been identifying bugs as well. None of this has been exposed yet, but will be in beta 'soon.' <br />
<br />
* Joe: Has CARLCore application profile to distribute for us to look at. This is for research libraries in Canada, who are trying to do harvesting. They are not seeking DCMI approval, but will be using this. Joe was at the CASE meeting in Montreal and there was another paper with some quality issues explored (he will send a cite along).<br />
<br />
2. Moving forward with our projects. What threads should we be gathering? <br />
* We all agree that moving forward with Registry improvements will be important, as we attempt to make our efforts more visible.<br />
<br />
3. Singapore, DC-2007<br />
* Workshop: ''Metadata That Works: Making Good Decisions'' Diane will send around the outline for some ideas on presenters. Stuart will be flying back on Friday so can't present. He has been talking with UW about hosting the software and perhaps sponsoring an occasional papers series for project reports.<br />
* Jon and Diane have been talking about the idea of a traveling 'road show' that might be less of an event that every one needs to fly to than something that can be hosted more easily and provide more 'how-to'. Diane will try and draft something to send out to the AB, hopefully before the meeting. Important to meet several needs: education, expert F2F, etc. <br />
<br />
Next week we return to our regular schedule.</div>Dianehttp://wiki.metadataregistry.org/Apr._2,_2007Apr. 2, 20072007-03-28T14:13:38Z<p>Diane: </p>
<hr />
<div>===Agenda & Notes, April 2, 2007===<br />
<br />
1. Review of Progress, New Proposal:<br />
* Pin generation (links proposals in FastLane)<br />
* Narrative complete (done)<br />
** Summary<br />
** Narrative<br />
** References<br />
* Budget<br />
** Characterizing CUL work<br />
** Where to get money for ongoing computer maintenance? Should we split costs between proposals? [Yes, include all costs on both budget]<br />
** Justification<br />
* Support letters<br />
** iVia letter received<br />
** Bill Arms letter on the way<br />
** Requests sent to Laura Bartolo, Stuart Chalk, Kim Lightle (will follow up this week)<br />
** Others? Diny? [Stuart will draft and ask for letterhead]<br />
* [Need current and pending support: these two proposals and existing proposals]<br />
* [Have bios done]<br />
<br />
2. Review of Progress, Extension proposal<br />
* Narrative nearing completion?<br />
* Should we include some screenshots?<br />
** 1-page summary for FastLane (Stuart)<br />
* Budget?<br />
** Diane will start that based on new proposal budget<br />
** Justification [need to include bracked actual cost at the end of the paragraph]<br />
* Support letters, do we need them? How many? <br />
** We'd thought about asking Tom Baker--any others? Alistair? [Diane will ask both of them]<br />
** Letter from Stuart supporting unfunded collaboration (advisor)<br />
<br />
3. DCAM issues<br />
* Issue of "Abstract syntax" vs. "Abstract model" brought up by [http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0702&L=DC-ARCHITECTURE&P=R5148&I=-3 Alistair on 2/26]</div>Dianehttp://wiki.metadataregistry.org/Mar._12,_2007Mar. 12, 20072007-03-10T19:33:21Z<p>Jon: </p>
<hr />
<div>===Telecon Agenda and Notes, Mar. 12, 2007===<br />
<br />
1. Jon's mockup of the AP Registration process:<br />
* URLs:<br />Note: whenever you see a dropdown selection, it contains the correct proposed values<br />
http://beta.metadataregistry.org/schema.html<br />
http://beta.metadataregistry.org/schema_namespace.html<br />
http://beta.metadataregistry.org/schema_property.html<br />
http://beta.metadataregistry.org/profile.html<br />
http://beta.metadataregistry.org/profile_property.html<br />
* Issues:<br />
** In the [http://dublincore.org/groups/collections/collection-ap-summary/2006-08-24/ DC CD-AP], obligations under values are separately recorded, indicating whether URIs or strings are mandatory, fixed, optional or not allowed. Diane thinks this might lead to odd combinations and bad outcomes. For instance, if both URIs and strings are marked mandatory, would people interpret that as requiring repeated statements, one with a string, one with a URI? If that combination ''were'' valid, how would people encode that? The ultimate question is, should the Registry enforce common sense, or allow all combinations?<br />
https://netfiles.uiuc.edu/sshreeve/www/dcmi/Collection-application-profile/2007-03-09/#coldctype1<br />
** Order of input screens in the mock-ups is similar to "standard" order that has been used before, but we may want to fiddle. For instance, should "obligation" for the property be higher, to avoid confusion with obligations for values lower down?<br />
<br />
2. The proposals:<br />
* Diane reports that there is still no decision from Cornell about overheads, but she was solicited on Friday to write up how the proposals related to the library, which she did. This signifies movement, I hope a decision (the right decision) comes soon. The library management is supporting us fully on this.<br />
* What else still needs to be done?<br />
** Diane has internal paperwork to do, but can't proceed on that until the overhead decision is made and we can finalize budgets<br />
** We still need figures on how much the CUL evaluation will cost. Elaine has promised to have them to me by Wed., which means we should be able to add those to the budget and see where we stand.<br />
3. Reply to the query from the Australian Broadcasting System. <br />
* Do we need a licensing decision?<br />
* What should we suggest to them? (and who will do it?)</div>Dianehttp://wiki.metadataregistry.org/Mar._5,_2007Mar. 5, 20072007-03-05T13:33:58Z<p>Diane: </p>
<hr />
<div>===Telecon Agenda and Notes, Monday, Mar. 5, 2007===<br />
<br />
1. The AP presentation at the Usage Board meeting. Jon's questions:<br />
* Do we have some expectation that a machine-readable AP will be used<br />
for data validation?<br />
** I assume yes, so... what kind of machine-readable representations we're considering -- RDF, RDFS/OWL, XSD, XML<br />
<br />
We agreed at the outset that RDF doesn't do data validation, so that we need to do is shift somewhat towards XML from a purely RDF application. Should we settle for machine readable rather than machine usable? Stuart pointed out that the early GEM tool "assumed" an application profile and built data based on that but did not validate the data that was created. It could use elements from any number of schemas. It was also agreed that there are two problems: creating a schema that would allow a tool to produce conformant data, and allowing an application to evaluate and validate data that declares itself as following the AP. Both of these are important and within the area we want to work.<br />
<br />
Stuart suggested that we look at the proposal for the new "DC in XML" guidelines, and determine whether we can work with the new DC encoding? In theory, anything that can be dumped into the new DCMI/XML, should be easily transportable to RDF. Jon: the question is can we register a useful AP that can be expressed in either XML or RDF. Stuart: that's what the new XML binding is intended to do, there's a schema attached to it, etc. Diane: We should present this as a test case for those guidelines, perhaps? Joe, Stuart: we need to know whether we can do this without data loss.<br />
<br />
* Will we _require_ that an AP have subordinate metadata schemas and what form will these schemas take? I assume the form as an AP, but want to be sure<br />
<br />
Jon: To what extent are we creating an ontology. Joe: we need to look at the way the AP says that the data is modelled. Jon: The question comes up because we may want to express the AP as RDFS/OWL, and does it bring us additional functionality for logical reasoning and data constraints. <br />
<br />
Diane: We can use the [http://kmoddl.library.cornell.edu/aboutmeta2.php KMODDL AP] as a test case. <br />
<br />
Discussion on the inability within an AP to discuss a domain for a property without being able to define it's context, specifically relating to a node with a URI. This is related to the sheep discussion Joe has been having on the lists. In order for a property in an AP to be defined correctly it had to be related to a URI, and there has to be a definition at the URI. <br />
<br />
* Other questions?<br />
** Who will present this at the UB?<br />
<br />
2. Proposals<br />
* Diane has been working on the narratives, incorporated most of Jon's suggestions in the extension proposal and filled in some blanks on the new proposal. We should probably all read through them and be prepared to discuss gaps, etc.<br />
** Diane has sent a note to Kim Lightle as suggested last week--no reply yet.<br />
<br />
3. Stuart's report from WebWise?</div>Dianehttp://wiki.metadataregistry.org/Feb._26,_2007Feb. 26, 20072007-02-22T19:55:43Z<p>Diane: </p>
<hr />
<div>===Agenda and Notes, Monday, Feb. 26, 2007===<br />
<br />
1. Review of progress on proposals<br />
<br />
2. Letters of support--who shall we ask? (New Proposal)<br />
* Johannes Ruscheinski (iVia)<br />
* Diny, for GEM Exchange?<br />
* Bill Arms?<br />
* NSDL projects and pathways using the sandbox?<br />
* ENC/Kim Lightle<br />
* Stuart Chalk/Chem<br />
* Laura Bartolo/MatDL<br />
<br />
3. Letters of support--Extension? Do we need additional letters?<br />
* I have the name of the OCLC Terminology Services person who might be interested in working with us<br />
* Tom Baker, both in his role as W3C WG chair, and as DCMI documentation guru?<br />
<br />
4. Short discussion of what we intend to do in Barcelona, regarding registration of APs<br />
* A functional walk-through of how we would register and manage AP information<br />
* How we would output APs in various flavors, machine readably<br />
* How would the machine readable AP be used?<br />
* How would export for humans work? Output for HTML pages, etc.</div>Dianehttp://wiki.metadataregistry.org/Feb._19,_2007Feb. 19, 20072007-02-19T00:53:09Z<p>Diane: </p>
<hr />
<div>===Telecon Agenda and Notes, Monday, Feb. 19, 2007===<br />
<br />
1. Diane: I have enabled Elaine Westbrooks to view the narrative--she's the person from CUL Metadata Services that will be working with us.<br />
<br />
2. Registry Extension:<br />
* Diane: I've started an extension proposal for the Registry, and it's still got quite a bit in it from the original proposal, which I've flagged so we can tell what's new.<br />
<br />
3. New Proposal Narrative</div>Dianehttp://wiki.metadataregistry.org/Feb._14,_2007Feb. 14, 20072007-02-13T21:39:39Z<p>Diane: </p>
<hr />
<div>===Valentine's Day Telecon and Notes, Feb. 15, 2007 (Moved from 2/14)===<br />
<br />
1. Change in telecon time to accommodate Joe. <br />
<br />
* Change to Mondays at 8 Pacific and 11 Eastern.<br />
<br />
1a. Static on the SKOS list...important? Jon thinks that some of this was provoked by a recasting of SKOS documentation by Alistair. There's also some functional requirements documents that are being discussed. <br />
<br />
2. Diane's discussion with Karen Henry, notes:<br />
* What pathways are trying to gather user annotations (even for local use), does she think they'd be interested in working with us on this. [Ask Kim about this, too]<br />
** Sounds like they still don't know what they're doing with this, going into it very slowly. I brought up the idea we'd had years ago about harvesting them, and she sounded like that was a new idea to her. I pointed out that it was important to be able to categorize them, and the Registry was the tool for that.<br />
* How do they think Expert Voices is going? Are they getting much data? Are they still planning to use the simple model of relating the annotation data, or has something else been developed?<br />
** They're thinking of enabling some limited social tagging for their initial annotation service, so we might add something about relating tags to established vocabularies in our terminology services. <br />
* Are they looking to offload Metadata Harvesting? Or is that seen as something that must be tightly tied to the NDR?<br />
** She was responsive to the notion that the OAI world has not embraced the NDR APIs and that coordinating and scheduling services might be useful. Interestingly, she also mentioned that audience project that SDSC is doing, and I think we should include that as one of our Terminology Service examples.<br />
* Ask what the status is with the iVia contract--is that something that NSDL would welcome having us contribute to?<br />
** Sounds like they're putting lots of pressure on Johannes, they think iVia hasn't been providing much value for the money they've spent. They're working on another contract with them and seem to want to impose numbers on them (60% is what she threw out), which is clearly unwise and probably impossible. No pathways or projects have been able to use the service, mostly, I think because they don't understand the limitations or the product. There could be some possibilities here to include something in evaluation (is this collection one that could benefit from iVia services? Or NLP?) as well as in terminology services (maybe use the FAST stuff instead of LCSH, or pull out geographics?) Mapping from their rich text might also be an option.<br />
<br />
3. Proposal discussions. <br />
* One thing Karen warned about is biting off more than we can chew, so we might think about focusing the proposal more, maybe leaving some things (the GEM stuff maybe?) for next year. I think we don't want them to think we've no chance of delivering.<br />
* Given Karen's reactions to the human evaluation portions, I think we should definitely beef that up a bit and talk about our ideas about moving to machine evaluation via APs.<br />
** Organization and Narrative<br />
*** Jon will add some information about the Hub and relation to our orchestration paper. Diane will reorganize so that that what's now in Project Goals is Project Design with the hub stuff at the head. Diane will also add some concrete examples and descriptions based on some of the ideas from Karen's phone call.<br />
** Milestones<br />
** Budget and Overhead<br />
*** We have to look into how to include Metadata Services Unit information<br />
** Tables and images<br />
*** Table looks okay, will need some revision as we move on<br />
<br />
4. Questions to NSF, answers from Alpha:<br />
* The 100,000 limit applies to our Registry extension. They don't always allow up to $100,000<br />
* Level of documentation needed: Need a full proposal, which means all of the pieces need to be there but not necessarily 15 pages. Additional questions identified in the documentation.<br />
** Diane will start that<br />
* Those categorized as "continuing" is in NSF document 04-32--Stuart will scope that out.</div>Dianehttp://wiki.metadataregistry.org/Feb._7,_2007Feb. 7, 20072007-02-06T21:35:52Z<p>Diane: /* Telecon Agenda and Notes, February 7, 2007 */</p>
<hr />
<div>===Telecon Agenda and Notes, February 7, 2007===<br />
<br />
1. Proposal tasks begun or completed:<br />
* Diane has begun the process of getting Cornell to allow us an off-campus overhead rate (memo sent to library financial officer)<br />
* Diane has contacted the CUL sponsored program officer, and notified her that we'll be doing the extension and new proposal<br />
* Diane has contacted Karen Henry to get her ideas on needed services<br />
* Diane has spoken to Elaine Westbrooks from the library about getting costs for human evaluation and setting up transforms<br />
* Stuart has a call with Diny later today which includes a conversation about talking to Lee Z.<br />
<br />
2. Proposal tasks to do<br />
* Determine where draft needs more work<br />
** Articulate the "hub" idea and the other services can be exemplars (Jon will start?)<br />
** Integrating the Ockham Registry in as the services registry portion (Jon)<br />
** Need a new name for this: Metadata Services Coordinator?<br />
** Services to teachers, including GEM (Stuart)<br />
* Figure out what kinds of harvesting services are they interested in [see [http://expertvoices.nsdl.org/whiteboardtalkback/ WBR#109] for discussion about what the NDR thinks it's doing] (Diane will ask Karen)<br />
* Flesh out more fully the services we plan to propose [Question: should we shift focus more towards educational issues or keep things general?]<br />
<br />
3. Set milestones and task assignments<br />
* Support letters (need better narrative and summary before soliciting) by early March?<br />
** iVia<br />
** Liz<br />
** Kim Lightle?<br />
* Budget<br />
** Check benefit rates and salaries for me and Jon, feed to Stuart for budget, also raises, changes in rates, etc.<br />
** Stuart will ask Alpha to ask NSF about limits on renewals, etc.</div>Diane