Metadata: 6-Dot or 8-Dot Braille

[shepazu]

• Requested metadata: This element could be required to indicate whether the braille code used in the eBraille file is 6-dot or 8-dot.
• Metadata Element: dc:Format (?)

[jrbowden]

Maybe a third option for both six and eight dot? e.g. some sections are in six dot, but there is a section in eight dot. The display has to be capable of eight dot, but there is no need to add the extra space in the six dot sections.

[shepazu]

Having values for 6-dot, 8-dot, or mixed 6-dot and 8-dot makes sense. It's always better to have descriptive values rather than a boolean value.

[shepazu]

While dc:Format does superficially make sense here, we're using dc:Format elsewhere, so we'd be overloading it.

Also, dc:Format takes as a value a MIME type, and I couldn't find any registered MIME type for braille at all, much less a differentiator between 6 and 8 dot.

Both Unicode and ISO define 6-dot and 8-dot braille standards, but I can't find any designation to easily differentiate them (e.g. a short string, akin to a MIME type or IETF language tag).

Does such a tag schema exist for 6-dot and 8-dot braille? If not, we should create a schema and ideally register it with some registrar, like IANA or IETF.

In any case, I don't think dc:Format is the right metadata element for this, since it's overloaded. I'll look for a better one, or maybe NLS has one?

[wfree-aph]

I agree about not using dc:Format. It seems to be more concerned with the "file format, physical medium, or dimensions of the resource." Six vs eight dot is somewhat a part of the physical medium but to me seems more akin to something like a font type. I think we could use our own designation, like characterSet.

[wfree-aph]

While we may change the name of this metadata term based on the discussion on issue #194, it is currently reflected in the first draft of the specification and there is no discussion to remove the concept of this term from the specification. Closing this as resolved.

[bertfrees]

In #209 I asked about why the brl:cellType field (formerly brl:dotNumber) should allow "6, 8" or "8, 6", rather than just "8" or "6". What could a user agent do with this information?

@mattgarrish said:

I'm probably not the right person to answer this, but wouldn't it allow the reading system to attempt to render the publication (if it's predominantly in a cell type it supports) rather than rejecting it outright because it can't render any of it?

@egli said:

As far as I understand the reason for allowing both values is so you can publication that contain both kinds of braille cells.

My question: how can a user agent gracefully handle 8-dot braille when it isn't capable of rendering 8-dot cells?

[mattgarrish]

how can a user agent gracefully handle 8-dot braille when it isn't capable of rendering 8-dot cells?

I wouldn't expect that it could, but it could alert the user when they load or open the book that it contains characters that cannot be rendered. Or a library or bookstore could indicate in the description that support for both is needed so that users can decide in advance to skip the publication if their device won't support it.

[bertfrees]

OK thanks.