rralley
commented
12 months ago Would this (item 1) not mean that someone trying to annotate a text from that institution's repository couldn't create an annotation for any fragment shorter than a page? So you wouldn't be able to link the name of a person mentioned in the text to their biographical entry in a reference work, for instance.
FWIW, I like the idea of 2 - I think it would be very worthwhile to be able to see the fragment in context, even if that simply means somehow highlighted within the whole text or section of text, rather than seeing a few words or lines either side. I seem to remember that the general view at the Cambridge workshop was that that was something that could be done in implementation without having to be covered specifically in the spec.
mjhawkins
neilsjefferies
I was wondering whether it would be useful for the manifest to contain a field that defines what level of granularity an institution's text extractor is capable of supporting (either in general or perhaps even per collection).
My rationale was this: 1) Not ever institution might wish to support the ability to extract text from arbitrary positions on a page. They might decide, for example, that page by page is all the granularity they want to support. 2) I like the idea of client ITF viewers being able to offer readers the ability to 'peek' on either side of the extract they're seeing to view it's wider context.
The ability to peek on either side of an excerpt could help to counter concerns regarding the malicious selection of text to invert its original meaning. For example, around the turn of the century several studios started selectively putting quotes on movie posters from credible critics saying things like 'A cinematic masterpiece' and 'Best Picture of the Year' - when the original review said. 'This is far from the best picture of the year and could be considered a cinematic masterpiece for insulting viewers' intelligence.
For a peek around function to work, the client viewer would need to know what sort of request to generate. There's no point trying to select a dozen words more on either side when the material can only be delivered by the page.
It likely wouldn't take much to provide this information. We could, for example, just go for the old school approach of using various bits on an integer. Bit 1 indicates whether character co-ords are supported; Bit 2 - page references; Bit 3, etc. One 8-bit number would likely be able to convey all the meaning that we'd need. I don't think there's any need to make extracting from semantic chunks machine actionable is worth attempting - just noting that it's available would be enough for me.
This also raises one additional feature that would be useful - a recommended field to record a hyperlink to a page that outlines how the institution's service works and what the terms and conditions are for the use for using it. This is distinct from the legal status for the text iteself.