http://wiki.metadataregistry.org/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=20&offset=&namespace=0&username=&tagfilter=Metadata-Registry - New pages [en]2024-03-29T06:39:23ZFrom 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>Diane