[Minutes] 2015-02-23 Digital Publishing Interest Group Teleconference

Hi all,

The minutes of the Digital Publishing Interest Group Teleconference 
dated 2015-02-23 are now available at

     http://www.w3.org/2015/02/23-dpub-minutes.html

These public minutes are also linked from the dpub wiki
     http://www.w3.org/dpub/IG/wiki/Meetings

Also find these minutes in a text version following, for your convenience.

Best,

Thierry Michel

---------------------------------------------


    [1]W3C

       [1] http://www.w3.org/

             Digital Publishing Interest Group Teleconference

23 Feb 2015

    [2]Agenda

       [2] http://www.w3.org/mid/54E70DB1.5050600@gmail.com

    See also: [3]IRC log

       [3] http://www.w3.org/2015/02/23-dpub-irc

Attendees

    Present
           Charles LaPierre (clapierre), Ivan Herman (ivan),
           Tzviya Siegman (tzviya), Phil Madans (philm), Dave
           Cramer (dauwhe), Ayla Stein (Ayla_Stein), Deborah Kaplan
           (dkaplan3), Heather Flanagan (HeatherF), Paul Belfanti
           (pbelfanti), Brady Duga (duga), Markus Gylling (Markus),
           Peter Kreutzberger (pkra), Karen Myers (Karen), Julie
           Morris (Julie_Morris), Luc Audrain (laudrain), Bill
           Kasdorf (Bill_Kasdorf), Ben De Meester (bjdmeest),
           Susann Keohane (Susann_Keohane), Thierry Michel
           (tmichel), Bert Bos (Bert), Matt Garrish  (mgarrish),
           Mike Miller (MikeMiller).

    Regrets
           Timothy Cole, Robert Sanderson, Vladimir Levantovsky,
           Alan Stearns.

    Chair
           Tzviya Siegman

    Scribe
           Markus Gylling (mgylling)

Contents

      * [4]Topics
          1. [5]last weeks minutes
          2. [6]identifiers TF first steps
          3. [7]overview of packaging spec
          4. [8]webapps manifest
          5. [9]F2F
      * [10]Summary of Action Items
      * [11]Summary of Resolutions
      __________________________________________________________

    scribenick mgylling

    <ivan> scribenick: mgylling

    <tzviya> agenda:
    [12]http://www.w3.org/mid/54E70DB1.5050600@gmail.com

      [12] http://www.w3.org/mid/54E70DB1.5050600@gmail.com

    scribenick mgylling

    <ivan> scribenick: mgylling

last weeks minutes

    <tzviya> [13]http://www.w3.org/2015/02/09-dpub-minutes.html

      [13] http://www.w3.org/2015/02/09-dpub-minutes.html

    tzviya: last weeks minutes approved?

    … approved.

identifiers TF first steps

    <tzviya> identification:
    [14]https://github.com/w3c/epubweb/wiki/Identification

      [14] https://github.com/w3c/epubweb/wiki/Identification

    Bill_Kasdorf: there are really two aspects: publication
    identifiers and fragment identifiers, Ivan has a starting point
    on wiki, as well as in the notes on packaging wiki page

    … markus suggested started with developing functional
    requirements for fragments, which is probably a good start

    … think that will be mostly a technical discussion after use
    cases are provided, w3c anno group is an important party here

    … publication identifier issue initially appears to be a total
    swamp

    … registries dont necessarily point to an online document or an
    epub; DOI as an example can point to anything although you can
    use DOI for this purpose

    … news is different because they have a firehose [of
    identifiers generated daily]

    … talking about all those identifiers, we need to accomodate
    any kind of publication

    … it may be that those IDs used today maybe arent relevant to
    CID

    … is this actually a metadata TF activity, or a new TF? Do we
    need to start over and recruit people from the beginning?

    tzviya: from my POV, it doesnt matter what we call the TF

    … looked at Wileys journals, found 5 different ways to do
    identifiers

    … we need to come to consensus about our recommendation, use
    cases and business requirements [???]

    ivan: dont care about the name of the task force either, but
    there is an intersection of people

    … requires a certain experience and mindset, and that’s all
    what really counts for me

    Bill_Kasdorf: we will need to recruit additional expertise

    tzviya: we need volunteers to work on this: volunteer now,
    contact BillK or add your name to the TF page

    Bill_Kasdorf: please sign up again on new wiki page

    ivan: I will be traveling this week. Thierry could you create
    this wiki ?

    tmichel: I will be on vacation starting tomorrow. Will do my
    best to create a new wiki for identifiers TF.

    <tzviya> action Thierry create new wiki for identifiers TF

    <trackbot> Created ACTION-47 - Create new wiki for identifiers
    tf [on Thierry Michel - due 2015-03-02].

overview of packaging spec

    <ivan> [15]http://w3ctag.github.io/packaging-on-the-web/

      [15] http://w3ctag.github.io/packaging-on-the-web/

    ivan: this is an editors note that evolves

    … for the time being Jeni has left the editors role to Yves
    Lafon

    … if we find somebody in this group or around us that is
    interested in being co-editor, we would be thrilled

    … the hope is that packaging in general might eventually become
    browser-native, of course not sure that it will happen, but we
    know that some browser vendors are interested in it

    <ivan>
    [16]https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

      [16] https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

    … might become the packaging format for EPUB-WEB

    <tzviya>
    [17]https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

      [17] https://github.com/w3c/epubweb/wiki/Notes-on-Packaging

    … three important parts: 1)packaging itself (how to combine
    files in a file), 2)the fragment identifier specification,
    although its not a main section in the doc and 3)link
    relationship which is defined

    … packaging is multipart mime, and [http mumbo jumbo with
    headers]

    … each part can be compressed individually

    … advantage that I see from our POV is that in fact a package
    like this is really a small website which is put in one place,
    reinforced by http

    … brings it even closer to webiness (multipart mime vs zip)

    … for example, metadata via http headers, can be used for book
    purposes

    … e.g. link header to create sequence of documents

    … one other aspect is that it is possible to do content
    negotiation for e.g. language

    … link relationship: defines a new type of linkage for packages
    for clients

    … we might imagine a scenario with a lending page that via the
    link mechanism bootstraps getting the package

    … fragment identifier: tries to solve how to get into the
    fragment of a document that is part of the package

    … is a three-step approach: 1) find a number of candidate URIs
    from within the package 2) filter 3)traditional fragment as per
    media type of filter result

    … dont know whether it covers all that we need, this is one
    thing we need to look at

    … dave cramer posted a mail

    <ivan>
    [18]https://lists.w3.org/Archives/Public/www-archive/2015Feb/at
    t-0007/mobydick.pack.zip

      [18] 
https://lists.w3.org/Archives/Public/www-archive/2015Feb/att-0007/mobydick.pack.zip

    Bill_Kasdorf: do resources need to know what packages they
    belong to?

    ivan: all resources are copied into the package

    … http header can contain expiration rules

    … you can reconstruct the original URI of a resource on the web
    using expiration

    ivan: differences vis-a-vis zip: many of concepts rely on web
    approaches, relies on tech and tools that are used on the web,
    so if the goal is to bring the document world closer to the
    web, that pays off

    … http header fields which are pretty powerful, and those are
    evolving, new headers, new header subinfo, this means that by
    inheritance we get http evolution in the package, we dont have
    to reinvent

    … for example the spine may become unnecessary

    <Bert> (Note that the document itself lists three advantages
    over zip: streamable, easier to create *well*, more metadata.)

    tzviya: the document also points out that zip is hard to create
    well, and has limited metadata

    ivan: this is much better suited for streaming than zip

    brady_duga: the packaging spec lists zip drawbacks, I think the
    metadata is the strongest. The comment that they are hard to
    create to is strange: there are tools to create zips but none
    to create these packages, also streamability can be done easily
    by subsetting zip.

    ivan: a bit sidetracking: I was at another conference in
    january, a presentation that showed that you can build up
    complicated things [???] by using http headers instead of RDF
    et.al.

    brady_duga: the intent is that you still have a full html file
    with references as usual, more of a cache use case?

    ivan: facilitating cache is clearly one use case, but
    downloading a whole web application is closer to our book use
    case

    … if epub-web goes that way, epub-web would define additional
    definitions on top (restrictions or requirements)

    <brady_duga> Sorry, lost my cell signal

    tzviya: keep in mind that publications go beyond traditional
    books (e.g. article+data sets)
    ... last point is to consider whether we want to comment on
    this spec and what we would need to layer on top

webapps manifest

    <tzviya>
    [19]https://github.com/w3c/epubweb/wiki/Notes-on-Manifest-for-W
    eb-Apps

      [19] 
https://github.com/w3c/epubweb/wiki/Notes-on-Manifest-for-Web-Apps

    tzviya: these are just notes, we’ve been asked to provide
    comments by March 5
    ... points to pay attention to: method for signalling
    installability, defines a URL for navigation scope, interesting
    to see how that interplays with packaging spec

    … impacts deep linking

    … also display mode: four specfied. And a fallback chain.
    Orientation specifiable for example.

    … members of the manifest: details on what can be included.
    Because this is deveoped for apps, deals a lot with install
    issues. But interesting for us is the scope, display and
    orientation needs to be figured out if it is sufficient

    ivan: two things: question: is the manifest file open in the
    sense that we can add additional terms, or is it closed?

    tzviya: seems to be closed, but have the request for comments

    ivan: scope: I didnt talk about that but packaging document
    also has scope, not sure how these two meet

    … you can add a scope hint

    dauwhe: title and stuff, by first reaction to this is that is
    only miminal data for apps (icon, title phrase, start)
    ... I dont think we want to turn this into the book metadata
    space

    +1

    … but dont see the need for publication metadata in here

    ivan: +1 from me too, maybe the manifest should be open so that
    various application areas can add additional terms

    … its not realistic for the webapps wg to provide metadata
    fields for everybodys needs

    dauwhe: not even sure this is the appropriate place

    tzviya: we really need to get moving on this

    <tzviya> streampub

    … also a contest for remaning epub-web

F2F

    <tzviya>
    [20]https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_
    Details

      [20] 
https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details

    tzviya: book your hotel soon!

Summary of Action Items

Summary of Resolutions

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [21]scribe.perl version
     1.142 ([22]CVS log)
     $Date: 2015-02-23 17:40:44 $

      [21] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
      [22] http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 23 February 2015 17:55:10 UTC