Meeting minutes
<AvneeshSingh> Update on extending crosswalk of schema.org accessibility metadata and ONIX to MARC.
Update on extending crosswalk of schema.org accessibility metadata and ONIX to MARC.
<AvneeshSingh> google docs: https://
ChrisOliverOttawa: There is a draft, as a google doc we can now share it with the Marakesh TF metadata group who are interested.
… , issue tracker for would be for this group.
… , I will monitor both for comments. I resolved some editorial comments
<AvneeshSingh> GitHub isue tracker: https://
ChrisOliverOttawa: , one question on mechanics do people prefer meeting for those interested in the crosswalk, or prefer using online tools for the discussion
<AvneeshSingh> Please use label "marc" for the related issues in the issue tracker.
ChrisOliverOttawa: , I have heard folks are fine either way.
Christopher: work in progress not complete, I did add definitions for clarity for Schema.org and ONIX as they may not be totally equal.
MadeleineRothberg: are there things not clear or need more information or how they will be used to help you?
Christopher: in terms of MARC we only used 4 modes (auditory, textual, visual, and tactile) we didn't go further for math chemistry on visuals etc.
… , mode would be visual, but then the accessibility Feature math etc.
MadeleineRothberg: right for us the accessibilityFeature of math etc. would be accessible and be textual based vs. an image
Christopher: we can go back and refine this.
… , we may need to add chemistry and modes and the accessibility feature if it is a textual mode or visual etc.
tzviya: accessMode vs. accessModeSufficient is very confusing. I still confuse the way it works, so even something like mathML can be conveyed in a visual way, we need to document this in a clear way. something like an image is visual but the description is that textual or visual and how you document that.
AvneeshSingh: mathML is only used if there is MathML not a image of math.
MadeleineRothberg: the way we approached it if you have an image with alt text, the base resource is visual, but it has an adaptation ie. alternative text. so the resource has an accessModeSufficient of textual because that image has an alternative "textual" description.
tzviya: I am trying to limit this complex nuances into MARC if possible.
Christopher: we have submodes .
ChrisOliverOttawa: if you are going to filter for certain kinds of resources, we describe the base resource then we have accessibility features for each resource.
MadeleineRothberg: does it make sense to crosswalk the accessMode and features and leave accessModeSuficient for now
Chris: I think we have it might be at the very end. and does it make sense or should be review that.
Christopher: subfieldB has accessibility features, and would be for only one specific type, its a repeatable field. within it would describe it
MadeleineRothberg: there is a desire to pre-calculate if a user can use this resource which is where accessModeSufficient.
Christopher: we could put this as a note: this is textual Sufficient
MadeleineRothberg: ONIX can currently when accessModeSufficient if a resource is only access mode is textual but combinations can be difficult to crosswalk potentially here.
GeorgeK: accessModeSufficient Textual is the trigger for Screen Reader Friendly as all images would have alt text etc. accessibilitySummary where the description could be determined by who is making this document and add that. Would be great to have that in metadata vs. a Note
Christopher: can we get some examples.
<MadeleineRothberg> Does Gregorio have ONIX files?
tzviya: I can send you some metadata files from Wiley
Gregorio: we have some ONIX files we can share
<Gautier> There is also the exemple used in the Display Techniques for ONIX document : https://
Lars: bookshef of some sort some examples books with rich metadata to help implement UI to help the reader see what issues / features a book may have once it is downloaded. Person can get an EPUB which may not display the a11y metadata. especially display warnings etc. If anyone has publications to share that would be awesome.
George: Thorium is in the process on implementing that.
Lars: maybe Daniel has some example books.
AvneeshSingh: google docs currently the main way to contribute for now and we will move that to GitHub afterwards. use github for issues, hard to comment on google docs, use issue tracker for that instead.
Gautier: could we switch to landscape. I would be happy to move the google doc back to GitHub once done.
… , I estimate 2-3 hours to move that content over once finished.
Progress update on document for guiding, how to write good accessibility summary.
<ChrisOliverOttawa> Thank you Gautier! And excellent suggestions for the Google doc
Progress update on document for guiding, how to write good accessibility summary.
<AvneeshSingh> https://
GeorgeK: I sent out a link to the document which has it rendered in HTML
… , we have the github repo, I find it difficult to find the HTML view and sent it out last night.
Avneesh: it uses the respec tool from the W3C.
Charles: yeah there is a trick to using the rendered view of html files in github with github.io.
GeorgeK: I did label it with A11YSummary. did anyone have any updates for ONIX / MARC size of fields are limited are. ie 352 can be?
gpellegrino: ONIX that field is suggested to be less than 500 characters (maybe 250, i need to check) if this is a problem we can speak with Graham B.
<MURATA> 352 bytes? 352 UCS code points? Or 352 grapheme clusters (which may require more than 1000 UCS code points)?
<MURATA> Sorry. Please forget my comment.
Christopher: if you run out of space you can add another one but would rather not do that.
Chris: examples that are in the document I can't see any of them being an issue.
George: we should in the the example field we identify the length
MURATA: when you say Character… what do you mean one unicode point but could map to 8 code points. European languages, what about emoj could require more code points.
GeorgeK: please create an accessibilitySummary for Japanese would be great
… , I would think a translation into Japanese, unless it doesn't translate well.
MURATA: I will make an example that is long to show the potential issues we may face.
<MURATA> I volunteered to write an accessibility summary using lots of CJK variation selectors.
Charles: what about metadata being only in english, can we add lang attributes?
AvneeshSingh: Yes I believe you can do this now, it shouldn't be tied just English.
GeorgeK: You can do Italian metadata right.
gpellegrino: Yes the accessibilitySummary can be in Italian which is the publication is in Italian. If a publication is in two language you could have multiple language tags in the metadata the first being the primary.
… , latin and Italian, the main language could be either if each are equal, but there would be 1 accessibilitySummary in the main language. French/Italian is for say the Italian market then the accessibilitySummary would be in Italian
<MURATA> I have nothing to add.
Gautier: I agree what you have said. if you buy a book in another language that the summary would be in that language.
ChrisOliverOttawa: wonder if you could have two accessibility summaries? Say English and French. With this document the text for the accessibilitySummary the publishers if the book is in two languages.
gpellegrino: You can put different lang attributes in the metadata. the User Experience Guide would have to address this.
… , clarify the lang attribute may be a good suggestion.
CharlesL: issues regarding multiple conformsTo and how it is displayed and our guidelines when there are multiple statements in the metadata in our guide. Also what about in Canada with 2 official languages we should find out what Publishers are doing now or wish to do. as this is the first metadata which is human readable.
ACTION: Charles to add a github issue for multiple conformsTo statments and how to display them in our UI guide
ACTION: gpellegrino to add an issue for adding the lang attribute to the accessibilitySummary
George: to send avneesh about next steps.
AvneeshSingh: next call May 12th.