Minutes – Z39.86 Advisory Committee Conference CallMinutes – Z39.86 Advisory Committee Conference CallAdvisory Committee:
Apologies:
The call agenda was distributed to the Advisory Committee list on August 5. There were no additions to the agenda.
The next call is scheduled for August 20, and then September 3, followed by the FTF Meeting on September 16-18 at Google.
Results of the NISO vote are official and the revision for Z39.86 is approved with 14 in favor, and 0 voting against, some companies abstained. Karen Wetzel at NISO is moving forward with the announcement to the NISO membership. George has been asked to chair the working group but anyone else is welcome to volunteer. NISO continues to emphasize stakeholder participation and is expecting those who voted yes to be interested in placing somebody on the working group. The NISO newsletter and official announcements are to go out today and will encourage participation on the working group. Everyone on this committee would be part of the working group but it is a separate entity and needs to follow the NISO process. The working group and official revision process has a one year life span and then another one year extension. Advice from Karen is to keep the group small. We can try to get good representation and the right people on the subgroups.
We should try to target a project plan that finishes 18 months from now, which would give a 6 month cushion if there are delays, but we should try to stay on target. Markus asked for clarification of what the 18 months includes. Per George, it does not include the initial voting period but does include the final review process. Rob asked if the schedule might turn out to be 1 year to get a draft and then 6 months for the review process. George said there are different approaches we could use in this standard process. We could have the whole specification out for review and then take comments while testing through the review period.
It was confirmed that 2 pieces of work that are high priority and can be separated out, are the DTBook and Container. George has not heard from Adobe about the container specification, but will send the announcement of the approval of the revision to Adobe and ask. George asked what are the other pieces of the specification that are related to DTBook. Rob mentioned the 'light profile', which might include non-book content such as magazine subscriptions that would involve revisions to the DTD. Marisa said that the issue of what is involved in relation to DTBook depends on whether the scope of the DTBook work is to clean it up or to extend the semantics. Cleaning it up means that it then still applies only to book content. We had talked about making the next version of the spec somewhat agnostic to a certain flavor of XML. Markus summarized that his understanding is that DTBook needs to be cleaned up, but that doesn't necessarily mean that it's general scope of capturing book semantics is going to change. George's vision is that whether we go to schema or RelaxNG, DTBook needs to more cleanly define the semantics of book content and that we really need a base line vocabulary in order to support synchronized text and multimedia output, and braille, certainly refreshable braille. Then we need to clearly define the mechanism for extending the vocabulary for a variety of uses. Rob asked if #1) we clean up DTBook to express synchronized multimedia and #2) then enable good representation echoed that something might be different with respect to magazine output, 'DTMag'. Lloyd questioned whether books and magazines were really different. RNIB's experience suggests that it is more efficient to have separate DTDs for different kinds of products. George agreed that one all-encompassing spec might be unmanageably complex, and is still thinking of the pizza model where DTBook is the cheese pizza, and adding the magazine and journal module that would go on top of it. There would with different toppings such as North American braille. He would hope that the base vocabulary might address 80% of the different types of content.
Markus asked that reviewed the need to update DTBook which is to be able to have an XML mastering format that would be able to output, multimedia, a.k.a. multi-format output. Trying to author a grammar that would allow any form of output is not wanted, since then it would be so diluted, such as HTML which is done and is so neutral. Right now DTBook is very much targeted against the print book alone. Neutralizing it to encompass more would be good, and maybe we should stop saying 'book' but say 'publication' instead. Having many modules on top of a neutral base for different purposes would make it highly targetable. We have need for a better extension model than we have today.
Rob asked if the 'neutral' base would emcompass books for books or are books one of the toppings? The risk is that the neutral base becomes nothing, or just text. Kenny drew an analogy to the XHTML 1.1 model which has a role, access, and media module and incorporates them into the XHTML namespace. George commented that it seems like the architecture of this is fundamental to all of the work that we are going to do with RDF and distribution profiles. If we have an agreed-upon architecture, then we can create a subgroup that can jump into the core vocabulary. Boris agreed that we should work on the bigger architecture problems first. James reviewed the notes from Palo Alto on the Zednext wiki which had outlined that a small tech group meeting was to have met by late summer to decide the major architectural framework.
Kenny commented that at Vision Australia they were expecting that DTBook Next would be the single source file, not suggesting that are semantics be part of DTBook, but the ability of to have modular extensions would be the most consistent thing for us to go. George asked if the core DTD is what we think of as the pillar for the interchange format, and then people could have their own extensions, or will the collaborative work also take place regarding these extensions. Rob would suggest the former, since the braille problem being dependent on so many different braille codes around the world. Kenny still thought that collaboration would be possible.
Markus would still hope that many modules would be reusable. The majority of users just want to be given something that works. The most important target should be that anyone who gets DAISY gets something that they can use right out of the box. Rob emphasized that at RNIB, the reality is that whereas they want to use DAISY as the single source file, but in the last year they have not been able to. RNIB must be able to produce braille according to British authority (U.K.) rules.
George realized that he has been considering that the most important thing is the RDF and maybe that thinking is wrong. I don't care what element it is, I care about the semantics of what it is. If we have this set of core elements, each of which has its own particular role, this is noted in our RDF ontology. If I want to extend it, then we add an etymology, a part of speech, and that extends our semantic layer and our RDF. It you use DocBook, you could use the RDF to do transformations from one language to another, if the roles are the same.
Boris rephrased it that we need to identify the core set of roles that the information is. We define what roles the elements would play that define a DAISY object, and then write mappings from various DTDs to identify which elements play which roles. George, so if you've got that mapping correct, your distribution utility would use that role the walk the content to extract what it needs for the navigation. Then the reading system could use the same information in doing presentation to the end user. Markus: yes, the roles serve as sort of a metadata layer on top of what XML instance it happens to be. You can use the role layer to discover the constructs with the role layer being consumed by user agents. The role could help define what something unknown means. Boris: A simple DTD would provide the simple DAISY roles in a very clear way. James: You wouldn't really need anything else, you shift the job of defining all the elements to the semantic layer. The DTBook or rather the DTDocument wouldn't really have to define that many elements. Boris: and turn it into that DTBook element.
Markus: I still believe we need a good base grammar which serves a practical purpose which is what people will use to create their master files. They want to create RDF-aware input. James: Do we need as much detail in the DTD such as having to define every type of sidebar for every type of document? This has been redundant, but for example note and noteref, annote and annoteref, we could collapse all these into a 'thing' and it's reference.
George summarized: we're linking together the grammar and the RDF pretty tightly. Then we have this other work which is focused on distribution, on DAISY book presentations, i.e. SMIL or non-SMIL presentations. This other bunch of work, which we're calling profiles, is quite separate from the content and RDF. Markus: the more complex of the talking profiles would be quite complex and would need to understand the RDF and the content quite well. There is a connection between the RDF and the talking book, so some of the profiles could be developed independent of the grammar. The light-weight profile, for example, could come a long way on its own. George: So, are there only 2 threads in our development, the profiling and the grammar, or is there something else? Kenny: What about the container part? Lloyd: That could be part of the distribution thread.
Markus: In Palo Alto, we wanted to make it quite clear what the ambition is what we wanted to do with profiles. George: the overall working group has the responsibility for everything. The actual working group has the responsibility for the actual specification and puts its name on all 3 pillars, but has the flexibility to bring in other people to do specialized work. As we move forward, it would be helpful to note how much of each person's day over the next 18 months is available and also put people's names where their interests are with regard to which piece, the vocabulary thread or the distribution thread.
The advice from NISO is to keep the groups manageable. We can continue with the larger FTF meetings every 6 months, but the smaller threaded groups may have to meet more often. There should be someone driving each group; George's role would be to coordinate.
After we get some ideas of who will be joining, there may be a need for a process to get people up to speed who have not been involved.
One goal is to clarify the role of the Zed committee in this work.
Time: 10:00 – 11:00 EDT (1400 UTC)
Venue: telcon
Conference Recording Filename: 20080806 (call the DAISY Conference number and enter *3 for playback)
Scribe: Kathy Kahl
Last Edited: 2008 August 18
Status: Version 2, for review