clarin-nl isocat workshop 2011 part 2 ineke schuurman menzo windhouwer
TRANSCRIPT
CLARIN-NL ISOcat workshop 2011part 2
Ineke Schuurman
Menzo Windhouwer
Part A• Issues brought up by participants
– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?– How to deal with larger amounts of data
Part B
• ISOcat and CLARIN: Do’s and don’ts (version 0.1)
– Introduction and discussion
• Part 1– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?– How to deal with larger amounts of data
• When (not) to adopt an existing DC
– It should ‘match’ with the way you use a specific notion in your annotation scheme, application, …
– It should come with the same profile– It should handle the same phenomenon,
SpeakerID =/= SingerID
Speaker vs Singer
String→Name→Person→Singer→Opera → Opera singer→Tenor →Tenor in La Bohème
First: too generic, last: too specificThe others are candidates
Note that SingerID and SpeakerID are siblings, whereas SingerID is subclass of both Singer and ID (RELcat!)
– When (not) to adopt an existing DC
– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?– How to deal with larger amounts of data
Standards
• Within ISOcat currently there are little or no standards,
Therefore
• CLARIN NL and VL will set up their own set of ‘standardized DCs’, Ineke will be in charge (she will consult with others)
– When (not) to adopt an existing DC– What about (CLARIN) standards
– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?– How to deal with larger amounts of data
Flagged DCs
• Never link with ‘deprecated’ DCs !
(in case of doubt: consult with Ineke or Menzo)
• In other cases the flags show whether the DC specification is correct from a technical point of view.
• Note that only DCs with a green marking are qualified for standardization
– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs
– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?– How to deal with larger amounts of data
DC/DCS and profile
• Profiles are not added automatically, a DCS may contain elements with various profiles
• In case the profile you need is not yet available, contact Menzo and Ineke
– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile
– What should be included in ISOcat (level of detail, abbreviations, …)
– What about TEI, metadata, webservice?– How to deal with larger amounts of data
What to include?
• Cf slide on SingerID/SpeakerID
• In general: all linguistically meaningful notions mentioned in your schema, manual, definition (cf part B)
• Abbreviations (PST for /past tense/)
are to be mentioned as Data Element Name
– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)
– What about TEI, metadata, webservice?
– How to deal with larger amounts of data
TEI, metadata, webservice
• TEI: likely to be taken care of at ‘higher level’, if not YOU are to insert the TEI definitions you use.
• Metadata: new in CMDI? In that case definition in ISOcat to be provided as well
• Webservice: to be taken care of in CMDI
– When (not) to adopt an existing DC– What about (CLARIN) standards– What with ‘flagged’ DCs– Relation DCS – profile– What should be included in ISOcat (level of
detail, abbreviations, …)– What about TEI, metadata, webservice?
– How to deal with larger amounts of data
Part B: do’s & don’tsDo’s:• Create a DCS for your scheme (name
project, ann.scheme, …)• Provide clear definition (short, to the point)
for your scheme, application, …. • Take care not to leave concepts used in your
definition undefined or vague• Use appropriate vocabulary (per profile)
• Check ‘adopted’ DC’s regularly till standardization !
Do’s (continued)
When creating a DC, fill out• Justification: used in XYZ, part of tagset
N• Language section
– Always English language section– Strong recommendation: sections for object
language(s), for working language manual– Sections in the various languages should
match (+/- be translations of each other)
Do’s (continued)
When creating a DC, fill out
• Example section – Note that *negative* examples may be very
helpful! (jongens, mannen, niet: gelovigen (is form of ADJ))
Example sections
Suppose you want to illustrate a German phenomenon:
• Ex.sec. in EN language section– German ex with transl in English
• Ex.sec. in NL language section– German ex with transl in Dutch
• Ex.sec. in EN linguistic section– EN example
• Ex.sec. in NL linguistic section– NL example with translation in English
Don’ts
• Confuse Language and Linguistic section– Latter contains language specific values for
closed domains
• Be (too) language specific in definition
• Mention scheme in definition
• Use several definitions in one DC
• Circular definitions
• Rely on authority
• Rely on standardized status– Definition should fit YOUR scheme, etc
.
-- End --