1. Flexible Syntax and Concept Registries as a basis for Metadata Daan Broeder TLA - MPI for Psycholinguistics & CLARIN Metadata in Context, APA/CLARIN Workshop, September 2010 Nijmegen

2. Metadata for Language Resources  Research at the MPI for Psycholinguistics is performed with Language Resources:  (classical) text corpora,  multi-modal/multi-media recordings  Lexica possibly with multi-media extensions  Everything that can help study language  10 years ago started using metadata to try control the mounting chaos caused by increasing numbers of resources  Reuse, management, metadata itself is also valuable resource  What to use?  DCMI not specific enough and alien terminology  TEI too complicated and then had no support for media

3. Metadata for Language Resources  Developed IMDI, a dedicated metadata set for multi- media/multi-modal Language Resources  Flexibility: special profiles for Sign-Lang., SL Acquisition,…  Specializations for descriptions at the data set level.  Crosswalks to and from DC/OLAC  Currently the IMDI catalog contains about 80000 metadata records for > 300000 resources  Also harvested from external IMDI metadata providers  Currently working on harvesting IMDI records for CMU’s Childes & Talkbank corpus resources.  However the EU CLARIN project that is aimed at creating an integrated infrastructure for Language Resources allowed us to reconsider the situation.

4. Current LR Metadata Situation When starting the CLARIN project we saw a fragmented landscape  Metadata sets, schema & infrastructures in our domain:  IMDI, OLAC/DCMI, TEI  Problems with current solutions:  Inflexible: too many (IMDI) or too few (OLAC) metadata elements  Limited interoperability (both semantic and functional)  Problematic (unfamiliar) terminology for some sub- communities.  Limited support for LT tool & services descriptions

5. Metadata Components CLARIN chose for a component approach: CMDI  NOT a single new metadata schema  but rather allow coexistence of many (community/researcher) defined schemas  with explicit semantics for interoperability How does this work?  Components are bundles of related metadata elements that describe an aspect of the resource  A complete description of a resource may require several components.  Components may contain other components  Components should be designed for reusability

6. Metadata Components Technical Metadata Sample frequency Format Size … Lets describe a speech recording

7. Metadata Components Language Technical Metadata Name Id … Lets describe a speech recording

8. Metadata Components Language Technical Metadata Actor Sex Language Age Name … Lets describe a speech recording

9. Metadata Components Language Technical Metadata Actor Location … Continent Country Address Lets describe a speech recording

10. Metadata Components Language Technical Metadata Actor Location Project … Name Contact Lets describe a speech recording

11. Metadata Components Language Technical Metadata Actor Location Project Metadata schema Metadata description Lets describe a speech recording Component definition XML W3C XML Schema XML File Profile definition XML Metadata profile

12. Country dcr:1001 Language dcr:1002 Location Country Coordinates Actor BirthDate MotherTongue Text Language Title Recording CreationDate Type Component registry BirthDate dcr:1000 ISOcat concept registry user Dance Name Type Semantic interoperability partly solved via references to ISO DCR or other registry Selecting metadata components & profiles from the registry Title: dc:title DCMI concept registry CMDI Explicit Semantics User selects appropriate components to create a new metadata profile or an existing profile ISOCat or ISO DCR implementation of ISO- 12620 standard for data categories under control of the linguistic community ISO TC37 Metadata is just one of the seven “thematic domains”

13. Recording CreationDate Type Component registry Genre 1 dcr:1020 Language dcr:1002 Genre 2 dcr:1030 Dance Name Type Relation Registry Text 1 Language Title Genre1 Text 2 Language Title Genre2 ISOCat Relation Registry User MD search User selects or creates a profile that specifies relations between DCs dcr:1020 = dcr:1030 dcr:1020 ~ dcr:1030 dcr:1020 > dcr:1030 Metadata modelers or terminology expert can also use the RR to specify relations that the ISO DCR can’t store

14. CMDI Architecture MD Comp. Editor MD Comp. Registry ISO-Cat DCR MD Editor. Local MD Repository OAI-PMH Data provider OAI-PMH Service Provider CLARIN Joint MD Repository MD Services Semantic mapping Services Relation Registry MD Catalog user Metadata modeler ISO TDG MD Creator External agents

15. Metadata Components & Semantic Granularity  Problems with component metadata: too high granularity in the ISOCat  Actor.Name, Actor.Fullname, Actor.Address, Actor.email,…  Creator.Name, …, Creator.email,…  Funder.Name, …,Funder.email  Having a DC for every of these MD elements would explode the ISOcat. Using just generic “Name” loses precision. 1.Compromise: use fine granularity only for elements that are expected to be often used (CreatorName, ActorName) for searching in metadata. Map the rest to generic “Name” 2.More fundamental solution: Use container concepts:  create an “Actor” DC, then we can reason with the context.  Actor ~ Participant, Name ~ Fullname -> Actor.Fullname ~ Participant.name

16. Query Scenario’s I  Keyword search with regexps  Searching for “Mandarin” will give you all resources in and about Mandarin  Semantic mapping is possible if a keyword is present in a concept registry.  Query for: “discourse” can return also records that have “dialog”  It looks “very” useful to have vocabularies available as pick lists in a taxonomy tree

17. Query Scenario’s -Terminology What terminology to use in the search interface?  The “canonical” one from the ISOcat  Might be unknown to the user  Some standard ones like OLAC, IMDI, TEI  To provide “compatibility” with these existing frameworks  The terminology used in the metadata components  A user should be able to use the same terms for retrieving resources as he used when creating the metadata  Then he should at least retrieve what he put in.

18. Metadata quality  In the end all will fail if we cannot provide high quality metadata.  See the VLO presentation tomorrow for an idea about the current status  Collaborative effort of researchers, funders, archive managers and infrastructure & tool builders  Researchers (still) need to be convinced that it is worthwhile  Funders need to allow them the time  Archive management need to audit, evaluate, curate  Tools and infrastructure need to make it all easy as possible

19. Thank you for your attention CLARIN has received funding from the European Community's Seventh Framework Programme under grant agreement n° 212230

20. Query Scenario’s II  Consider the following queries Participant.name = ‘xxx’ Actor.fullname = ‘xxx’ DCR: participant_name == Particpant.name DCR: participant_name == Actor.fullname  Context problem solved by high DCR granularity  If you extrapolate this strategy requires a lot of entries in the DCR.

21. Query Scenario’s III  Consider the following queries Participant.name = ‘xxx’ Actor.fullname = ‘xxx’  Limited granularity with registration of container concepts, perhaps low semantic precision DCR:name == fullname myDCR:Actor == Participant

22. Query Scenario’s IV  Consider the following queries Participant.name = ‘xxx’ Actor.fullname = ‘xxx’  Precise semantics, low granularity DCR:name == name DCR:fullname == fullname myDCR:Actor == Actor myDCR:Particpant == Participant RR: Participant isKindofA Actor RR: fullname isKindofA name

23. Query Scenario’s V  Consider the following queries Participant.function = ‘annotator’; Participant.name = ‘xxx’ Actor.role = ‘creator’; Actor.name = ‘xxx’ But now map also to: Annotation.Creator = ‘xxx’ ???

24. Content  IMDI history  CMDI basics, components, ISOCat  Context independency  Metadata for Aggregations  Virtual collection registry  Profile matching via metadata  Caveat: metadata quality – fighting entropy