1. Broad Functional Classification a Data Type Registry Use Case
Daan Broeder TLA/MPI for Psycholinguistics

2. The discovered metadata record links to ‘other’ data
Use case context
Communities are building central metadata service providers, usually a metadata catalogue
Harvesting metadata from different archives and repositories
Maybe doing some semantic mapping
Allowing users to browse and search for resources e.g. resource discovery
The discovered metadata record links to ‘other’ data
Users and especially automatic processes would be well served if they know where the metadata leads to

3. metadata/data link policy variety
Even within single communities there is much variety how metadata is connected to resources
Direct link to (protected) resource
Link to another structured metadata record
Landing page for the resource
Link to a general site-page
Link to contact information
Users and automatic processes need to know what to expect.
Proposal: type the links/PIDs

4. CLARIN community use of CMDI
CLARIN is the Linguistic/LR community
CMDI: Component Metadata Infrastructure
Flexible/reusable components to build metadata schema that fit different requirements
New roadmap needs to be discussed
Already CMDI supports distinguishing between linking to metadata or data
We will develop a classification scheme that supports all cases in the CLARIN community metadata

5. Possible new CMDI implementation
… <Resources> <ResourceProxyList> <ResourceProxy id="ZW--”> <ResourceType mimetype="application/x-cmdi+xml”>Metadata<ResourceType> <ResourceRef> </ResourceProxy> <ResourceProxy id="ZW--_S_03947"> <ResourceType mimetype="text/xml">Resource</ResourceType> <ResourceRef> </ResourceProxyList> </Resources>

6. Possible new CMDI implementation 1
… <Resources> <ResourceProxyList> <ResourceProxy id="ZW--”> <ResourceType mimetype="application/x-cmdi+xml”>Metadata<ResourceType> <ResourceRef> </ResourceProxy> <ResourceProxy id="ZW--_S_03947"> <ResourceType mimetype="text/xml">Resource</ResourceType> <ResourceRef> </ResourceProxyList> </Resources>
00-…
BFC: DO
mt: text/xml
BFC: … …
DO: ….

7. Possible new CMDI implementation 2
… <Resources> <ResourceProxyList> <ResourceProxy id="ZW--”> <ResourceType mimetype="application/x-cmdi+xml”>Metadata<ResourceType> <ResourceRef> </ResourceProxy> <ResourceProxy id="ZW--_S_03947"> <ResourceType mimetype="text/xml">Resource</ResourceType> <ResourceType TypeScheme=“BCF”>DO</ResourceType> <ResourceRef> </ResourceProxyList> </Resources>
00-…
BFC: DO
mt: text/xml
BFC: … …
DO: ….

8. Why use a DTR in this use-case?
Why data-types why registry
These conventions and their domain can also be implemented by community agreement
However:
Future refinements can be more easy introduced
Crossing community borders is more easy using ‘neutral’ accepted registries
Automatic type discovery and interpretation
Is the implied semantics of the DTs sufficient?