-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposing subtypes of TextDocument
#231
Comments
I'm in favor of this idea. Do you think it would make sense to also start enforcing/validating the directionality of alignments? Basically so that a subtype annotation can't be the source of a parent type annotation. E.g. an |
Another useful type may be Summary |
@marcverhagen Under the proposal, text-to-text summaries are @wricketts Yeah, I also like the idea of directed alignment. It's pretty clear for In terms of implementation of the directionalities, we could add an attribute to the alignment type or we can super-/subclass a "undirected-alignment". |
I could see a subclass |
I have been thinking of an alternative for the word An alternative would be to not introduce new annotation types but a Also, instead of alignments we can think of some of the relations between text documents and other types as proper relations and think (again) about how to structure the vocabulary part under In a related issue we discussed introducing types like CSV and CONNL in the hope that they would help with quickly rolling out a wrapped RFB app. We were thinking of those as MIME types though (incidentally, the vocabulary would have to change a bit since it only allows MIME types if you use the "location" property in stead of the "text" property). |
Yeah, I also thought about having it as a property. One thing we can (possibly greatly) benefit from a separate (sub-)type is that we can syntactically distinguish However, another point to consider is that vocab types are actually defined behind URIs, while for property values, we don't have any effective way to regulate them (behind developers' consciousness), so we are likely to end up with dealing lots quirk-y naming and typos (we have already experienced enough problems from minor quirks like |
Notes from yesterday's in-person meeting;
some additional notes from my thoughts:
Footnotes
|
Yes, it is weird to have Also, as an additional concern is the status of the LAPPS vocabulary and the potential need to expand the CLAMS vocabulary (see #202).
They are still in the vocabulary at https://mmif.clams.ai/1.0.5/vocabulary/ so technically not quite correct. Current code in timeframe evaluation makes heavy use of |
You are right in that the One more thing I wanted to add to that PR 262 was automatic "canonicalization" of the key name Just to be clear, these $ grep Type clamsproject/apps/docs/_apps/**/**/metadata.json
aapb-pua-kaldi-wrapper/v1/metadata.json: "description": "When true, the app looks for existing TimeFrame { \"frameType\": \"speech\" } annotations, and runs ASR only on those frames, instead of entire audio files.",
aapb-pua-kaldi-wrapper/v2/metadata.json: "description": "When true, the app looks for existing TimeFrame { \"frameType\": \"speech\" } annotations, and runs ASR only on those frames, instead of entire audio files.",
barsdetection/v1.0/metadata.json: "frameType": "bars"
barsdetection/v1.1/metadata.json: "frameType": "bars"
chyron-detection/v1.0/metadata.json: "frameType": "chyron"
east-textdetection/v1.0/metadata.json: "name": "frameType",
east-textdetection/v1.1/metadata.json: "name": "frameType",
east-textdetection/v1.2/metadata.json: "name": "frameType",
fewshotclassifier/v1.0/metadata.json: "frameType": "string"
fewshotclassifier/v1.0/metadata.json: "name": "finetunedFrameType",
gentle-forced-aligner-wrapper/v1.0/metadata.json: "frameType": "speech"
gentle-forced-aligner-wrapper/v1.0/metadata.json: "frameType": "speech",
parseqocr-wrapper/v1.0/metadata.json: "boxType": "text"
pyscenedetect-wrapper/v1/metadata.json: "frameType": "shot",
pyscenedetect-wrapper/v2/metadata.json: "frameType": "shot",
slatedetection/v1.0/metadata.json: "frameType": "string"
slatedetection/v1.1/metadata.json: "frameType": "string"
slatedetection/v1.2/metadata.json: "frameType": "string"
slatedetection/v2.0/metadata.json: "frameType": "slate"
slatedetection/v2.1/metadata.json: "frameType": "slate"
swt-detection/v3.0/metadata.json: "frameType": "bars"
swt-detection/v3.0/metadata.json: "frameType": "slate"
swt-detection/v3.0/metadata.json: "frameType": "chyron"
swt-detection/v3.0/metadata.json: "frameType": "credits"
tesseractocr-wrapper/v1.0/metadata.json: "boxType": "text"
tesseractocr-wrapper/v1.0/metadata.json: "name": "frameType",
tonedetection/v1.0/metadata.json: "frameType": "tone" Instead they always have been used to capture algorithmic classification results (they are all now replaced with |
More thoughts on the implementation of "full validation" of annotation objects based on vocab yaml (or equivalent piece of information from spec).
|
New Feature Summary
With a number of recent development, I'd like to propose more vocab types that are subcategories of
TextDocument
(all names are tentative in the proposal)Transcript
: a subtype of text document, always aligned to annotations in non-linguistic modalities (audio, vision), and represent linguistic, and "literal" transcript of the source modality. (e.g. ASR, TR/OCR)Translation
/Transformation
/Extraction
: a subtype of text document, always aligned to anotherTextDocument
-type annotations. The content of this annotation must be a kind "re-writing" of the source text document. (e.g. identity function in text-slicer, structural parsing in RFB, summary in text-summarizer apps)Caption
: this is similar toTranscript
but the content is not "literal" transcript of the source modality (e.g. image-based captioning app, audio-based summarizer app handles non-linguistic sounds like dog barking)Related
The addition of subtypes of text document will ease the identification of "app patterns" without relying on a specific app name, and hence help generalize I/O specs for any downstream/consumer applications.
The issue of view pattern identification has been raised many times, including
input
list in the app metadata clams-python#77Alternatives
No response
Additional context
Also see clamsproject/app-role-filler-binder#4 for discussion on development of a prototype "app pattern".
The text was updated successfully, but these errors were encountered: