Open GouldenJen opened 10 months ago
An important thing to note is that you can use a numeric value for the contraction grade, or something more universal. The meaning of the numeric contraction grade is, indeed, local to a region. For example, for English braille, 0 means computer braille and 1 means (literary) uncontracted, 1.5 means partially contracted and 2 is fully contracted. But for German braille, 0 means (literary) uncontracted, 1 is partially contracted and 2 is fully contracted.
Liblouis uses a combination of both a numeric value and a more universal keyword ("none", "partial" of "full").
Thanks @bertfrees for pointing out how ambiguous braille grades end up being. The universal keywords might be clearer- though if we did those, it would probably be best to change the metadata type from "grade" to "contractions".
Braille grade is required in the first draft of the specification and found under section 5.2. Closing this issue as completed.
I'm not sure this is really completed. I'm looking at the preview where the metadata guide has been integrated. There is no mentioning of braille grade in the metadata section.
Maybe you are saying that the braille grade is integrated in the braille code? This sort of can be read into the text but doesn't seem to be explicitly mentioned.
It's currently listed as a required property in the metadata section but that section only lists a few properties we discussed very early on. it's not in the metadata guide so we'll lose that requirement in the open pull request.
I assume the property should be brl:grade, but are there any requirements on the value?
As mentioned in the discussion in #208 there is no agreement on the meaning of a braille grade. So maybe we should drop the grade metadata after all and make it part of the brl:code
or whatever that piece of metadata is going to end up being called
@egli I think that makes a lot of sense.
@egli I think the idea to include grade information with brl:code makes sense. We can validate that brl:code exists but we won't be able to validate what it contains without some master list of braille code and grade terminology, but I also think publishers will have a vested interest to maintain naming conventions for at least their own materials.
GitHub tickets: #41 and #19 Requested metadata: Identifies any braille grades used in the file NLS Dublin Core elements: N/A alternative DC or schema.org: x-metadata brl:brlGrade OR refines dc:Format? Notes from GitHub tickets: Include “gradeless” option for music, Nemeth, other codes that do not have a grade Notes from metadata team: Required if applicable? Use "refines" for braille code metadata or a separate x-metadata element?