1 / 16

Dutch Female Authors: Comparative Analysis of "wijf" in 14th, 16th and 18th Century Documents

This study analyzes the different forms of the term "wijf" in Dutch documents by female, male, and unknown authors. The results are presented by region and genre. Findings contribute to understanding gender roles and language evolution.

landons
Download Presentation

Dutch Female Authors: Comparative Analysis of "wijf" in 14th, 16th and 18th Century Documents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMDI/ISOcat And Semantic Operability Ineke Schuurman ISOcat content coördinator CLARIN-NL Menzo Windhouwer ISOcat system administrator Utrecht 4-3-2014 1

  2. “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?

  3. 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

  4. 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

  5. Within CLARIN, metadata concepts are to be defined CMDI ISOcat other Concept Registries related RELcat Consequence

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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’

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. Thank you for your attention. Any questions? ineke@ccl.kuleuven.be isocat@mpi.nl CLARIN-NL 16

More Related