160 likes | 277 Views
CMDI/ISOcat And Semantic Operability Ineke Schuurman ISOcat content co ö rdinator CLARIN-NL Menzo Windhouwer ISOcat system administrator Utrecht 4-3-2014. 1.
E N D
CMDI/ISOcat And Semantic Operability Ineke Schuurman ISOcat content coördinator CLARIN-NL Menzo Windhouwer ISOcat system administrator Utrecht 4-3-2014 1
“Give me a list with all forms of ‘wijf’ in 14th century documents in Dutch by female authors, the same for the 16th and 18th century. Contrast them with documents by male authors and by unknown authors. Present the results ordered per region and per genre.” How to find data that could answer such a research question? Uhhh?
Not ‘just by hand’ ► machine Subset selection ► metadata Some problem(s): question not formulated in ‘Metadatish’ What is clear for us is not clear for a machine What is meant by the concepts used (‘author’, ‘region’, ‘Dutch’) Several ‘definitions’ / ‘encoding schemes’ in use Metadata and machine
Not one metadata scheme favored You may combine elements of several schemes ► “semantic interoperability” is to be ensured Is a ‘kopiist’ an author? What defines a ‘genre’, a ‘region’? ► May differ in various metadata schemes coming with documents! CLARIN
Within CLARIN, metadata concepts are to be defined CMDI ISOcat other Concept Registries related RELcat Consequence
CMD Infrastructure • Each CMD record contains some information to be used for interoperability: • Metadata header information • Author • Metadata profile used • … • Share profiles/components (structure and semantics) • Still different profiles/components can also share semantics by sharing concepts • Main focus of this presentation
ISOcat: Data Category Registry defining widely accepted data categories (DCs) http://www.isocat.org Registry that stores DCs for language resources and their metadata, together with properties of the DCs (definition, administration, examples, etc.) ISOcat 7
ISOcat and CLARIN(-NL) • ISOcat is used by CLARIN • For defining metadata concepts in CMDI • Focus of this tutorial • For defining resource (content) concepts • This has been the main focus of the ISOcat tutorial • Ineke Schuurman is the CLARIN-NL ISOcat content coordinator • Guidelines (do’s and don’ts) for (reusing) DC specifications • Review and recommendation
NEHOL project Alphabet (DC-4143) any set of characters representing the simple sounds used in a language or in speech generally In principle good because: No language / project dependency No tautology Reusable (not too strict) A good example
Adopt an existing entry, if not possible: create a new entry In all cases: the entries should be GOOD ones But: what makes an entry a good one, one that you can (re)use? Some ‘rules’
Create a DCS for your scheme (name project, annotation scheme, …) Share your DCS with the CLARIN-NL/VL ISOcat group Not a member yet? Contact Ineke Schuurman to get an invitation Adopt DC’s where possible (see don’ts) Check ‘adopted’ DC’s regularly till standardization Use the Atom feed of your DCS Provide clear definition (short, to the point) for your scheme, application, …. as general as possible, as specific as necessary Take care not to leave concepts used in your definition undefined or vague Use appropriate profile (for CMDI: metadata) Use appropriate vocabulary (per profile) Keep track of relationships to existing DC’s Do’s
Be (too) language specific in definition Mention project/scheme in definition Use several definitions in one DC Circular definitions Rely only on authority Definition should fit YOUR purpose! Don’ts
Use these DCs! We will take care of those definitions that are tautological too strict … When you spot DCs that are imperfect, let us know! Athens Core
Try to avoid linking with ‘deprecated’ or ‘superseded’ DCs Can be needed for legacy data In other cases the flags show whether the DC specification is correct from a purely technical point of view Note that only DCs with a green marking are qualified for recommendation Reuse might trigger the owner into fixing the DC Obsolete/flagged DCs
CMDI and DC types • A CMD component should map to a container DC • A CMD element/attribute should map to a complex DC • A CMD value should map to a simple DC • The Component Registry enforces this mapping in the ISOcat search dialogue
Thank you for your attention. Any questions? ineke@ccl.kuleuven.be isocat@mpi.nl CLARIN-NL 16