Trends in Concept Modelling Turning Issues into Solutions How to Discipline a Cat

1. Trends in Concept ModellingTurning Issues into SolutionsHow to Discipline a Cat Sue Ellen Wright, Kent State University

2. What is ISOcat? – 1 • The implementation of the ISO TC 37 Data Category Registry, a Metadata Registry • A knowledge resource containing, i.a., definitions for data category concepts used to annotate language resources • A (potentially) authoritative concept database that can be used to anchor relations in external Relation Registries (RRs) and other knowledge resources

3. Semantic Issues for DCs • What data element names occur in these data? • What do the content of these DCs “mean” in a semantic sense? • Can I utilize these data in my environment, especially across barriers of communities of practice?

4. Goals of ISOcat • Supporting the reusability, integratability, and interoperability of data by defining data categories (data element concepts) as an instantiation of ISO 11179 • Trusting data in a climate of different communities of practice • Community collaboration in defining the data categories used in language resources

5. Metadata Registries in 11179 • An ISO metadata registry consists of a hierarchy of "concepts" with associated properties for each concept. Concepts are similar to classes in object-oriented programming but without the behavioral elements. Properties are similar to Class attributes. ISO standards require that each concept and property have a precisely worded data element definition

6. What is ISOcat? – 2 • A social network designed to facilitate the creation of data category specifications for use in linguistic annotation schemes • A forum for achieving consensus on data category names, definitions, permissible instances and data category selections for work groups and thematic domains • A framework for standardizing a subset of these data categories and data category selections (e.g., tagsets)

7. ISOcat as an MDR with a history • “Authority” and credibility are hampered by: • Incorrect spellings, definitions, examples • Narrow perspectives that ignore individual language specifics • Failure to observe moderately uniform conventions • Failure in the past to accommodate consensus among experts

8. Knowledge Resource Issues • Flawed legacy data from the Syntax pilot DCR • Lack of stable guidelines for attributes such as definitions & some names • Introduction of data refinements, which require updating virtually all DCs • Technical glitches that resulted in missing DCs • Inevitable errors, coupled with inability to edit entries • Lack of efficient group consensus mechanism • Danger of similar issues in the future

9. Examples: Flawed SALT Input • Critical standardized items not imported • Recreated, but not marked as standard /part of speech/ is standardized as per ISO 12620:1999, but shows up as private & candidate

10. Uncorrected Data Errors • Incorrect definition for some languages In languages that actually use the accusative case, it is frequently used for other purposes, particularly as an object of some prepositions, or to use a noun as an adverbial. (Alas, even Crystal can be wrong on occasion.)

11. Uncorrected Data Errors • Discursive, rambling definitions; inappropriate example Again, reliance on one source & lack of feedback from speakers of other languages results in misinformation. A better example: She fixed him a nice lunch. Neeri Conference, Helsinki, 2009-10-01

12. Language-Related Issues • English, which can talk about the accusative case, but does not actually have an accusative case, conflates dative and accusative (at least) into objective case, but there is no entry for this.

13. Conflicting Definitions • The object is to define appellative nouns used as components of proper nouns

14. Uncorrected Data Errors • Tautological definition, confusing note, lack of a clarifying example Definitions should not simply restate the elements of the data category name.

15. Uncorrected Data Errors • Incorrect “language-independent” name (incorrect English name) The correct name is participial adjective..

16. Solutions • Data must be reliable and adhere to consistent rules in order to contribute to trust on the Web. • DCR Guidelines (unavailable during Syntax phase) are now in place. http://www.isocat.org/manual/DCRGuidelines.pdf

17. Solutions • Provide appropriate social networking environment & technical features • Designed to avoid and correct similar discrepancies in the future • Rationale: • Individual experts can make mistakes. • Group consensus verifies form and content. • Multiple mother tongues contribute to broader understanding. • Even non-standardized DCs benefit from consensus.

18. Roles in ISOcat – Individuals • Guests • Access, select, and output data • Experts • Above, plus save DCs, DCSs • Create new DCs • Share DCs • Create & serve on Ad Hoc Groups, TDGs • Coordinate Ad Hoc Group, chair TDGs • Submit DCs for standardization

19. Roles in ISOcat • Ad hoc groups – informal groups of experts assigned by individual experts • Comment on and reach consensus on DCs in shared space • Submit (if desired) DCs for standardization • Semi-formal ad hoc groups: • LISA/OSCAR group, others (DITA? DARWIN? XLIFF?) • CLARIN work groups • ISOcat work groups for other major projects • Informal, truly ad hoc groups

20. Roles in ISOcat • Thematic Domain Groups • Formal groups appointed by ISO TC 37 P members & TDG Chairs • TDG Chairs • Manage DC evaluation process per ISO 12620 • DCR Board members • Conduct DC validation & harmonization process

21. QA Scenario 1, Phase 1 • Expert A spots perceived error in DC belonging to Expert B or to a TDG • Expert A clones currently locked DC in his/her own workspace • Here s/he can propose editorial corrections in the cloned DC • Expert A invites Expert B to share clone • Expert A informs TDG and shares clone

22. QA Scenario 2, Phase 1 • TDG chair/Ad Hoc Group leader creates a DCS for review • Selection from current DCs or • Creation of new DCs • Profile change management • DCS (with its DCs) assigned to a pre-defined group (ad hoc or TDG)

23. Profiles versus DCSs • Profile membership is part of the DC specification • the profile indicates the thematic domain of the DC • the profile view in the UI is created by a query • there are a limited number of profiles • A DCS is a collection of DCs • hand picked by an user for a specific purpose • can contain DCs from various profiles • there can be an unlimited number of DCSs • There isn’t (yet) a profile specific view on a DCS

24. QA Scenario 3, Phase 1 • Any role (individual expert, group, DCRB member) identifies the need to harmonize DCs between TDGs or across communities of practice within a TDG • DC or DCs collected, cloned • Discussion group assigned & notified • Multiple ad hoc or thematic domain groups may have to interact.

25. All QA Scenarios, Phase 2 • Wiki and/or forum based discussion • Informal consensus or formal balloting • Correction according to above decision • Harmonization issues • Option 1: DCs merged to form one, perhaps with multiple profile options • Option 2: Multiple DCs, with clear indication of differences that justify doublettes • Option 3: Build external RR linking doublettes

26. Justified Doublettes – Terminology • The value domain for /part of speech/ in Terminology is very short.

27. Doublettes – Morphosyntax PoS • The value domain for morphosyntax is extremely large.

28. Tasks • Enable the retention of historical data category specifications while facilitating ongoing revisions • Integration of a variety of social networking features • Wiki and forum add-ons • Internal messaging system • Link to external mail • Creation, consensus, revision, harmonization

29. Thanks for your attention! Come play with the cat! http://www.isocat.org/ sellenwright@gmail.com isocat@mpi.nl