W3C

Digital Publishing Interest Group Teleconference

21 Dec 2015

Agenda

Attendees

Present
Tzviya Siegman, Alan Stearns (astearns), Bill Kasdorf, Romain Deltour, Tim Cole, Ivan Herman, Charles LaPierre, Vladimir Levantovsky, Heather Flanagan, Ben De Meester, Markus Gylling, Luc Audrain
Regrets
Dave Camer, Peter Kreutzeberg, Florian Rivoal,  Nick Ruffila, Nick Barreto, Ayla Stein, Zheng Xu
Chair
Tzviya
Scribe
HeatherF

Contents


<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0109.html

ivan: hoping to have a better teleconference service for 2016

heather: it will just be bad differently

<tzviya> http://www.w3.org/2015/12/07-dpub-minutes.html

tzviya: approving last week's minutes?

markus: there has been some progress on the ARIA mapping stuff?

tzviya: discussion, yes. It will inform the testing of the information recorded in the mapping document.

mgylling: is there a timeline when this will hit this group?

tzviya: It is already a FPWD
... DPUB-ARIA will work on the testing in January/February
... DPUB will work on the samples, ARIA will work on the automation
... Minutes approved

Locators TF

<Bill_Kasdorf> http://www.w3.org/TR/2015/WD-pwp-20151126/#identification

<tzviya> https://www.w3.org/dpub/IG/wiki/Task_Forces/locators

Bill_Kasdorf: Thank you to the group that signed up for this TF
... will set up a call in early January
... There is a good description of the goals on the TF wiki
... This is a focus on locators not identifiers
... Specifically, focusing on PWP section 5.4
... In the intro to that section, with the distinction between identifiers and locators, the locator may refer to a personal copy.
... This was enlightening; publishers had been discussing a work identifier, and not any possible instance.
... So, we are talking about specific instances, and we don't have to worry about other copies of the work. That makes this very doable.
... The first note in the next section is possibly incorrect. There are million CrossRef DOIs registered for books, and those are used for citations
... Unless "citation" is being used in a different manner, there is an available, persistent, unambiguous identifier for books.

ivan: What you say is true for scholarly books. If we want to refer to a novel or something similar, then that may be incorrect.

Bill_Kasdorf: CrossRef DOIs are mainly used by scholarly literature, but there is no exclusivity requirement (they can be used for novels)
... We want the identifier to be agnostic to any particular locator service (so DOI is an interesting model, but isn't what we're talking about)

tzviya: Suggest opening an issue. While DOI is broadly used in academia, it hasn't been heard of outside that community.

Bill_Kasdorf: clarifying that you're talking about non-scholarly books is useful.

mgylling: What Tzviya said - put in an issue in git to help clarify this

ivan: To be clear, what is written in the introduction, it simplifies things but we should be careful not to suggest that all problems have been solved.
... if I make annotations on my own copy, I can do it because I have a URL to my own copy. But if I want that annotation to be valid for the work in general
... then there is a problem. I think we should ack that these problems exist. The mechanism for those solutions is outside the PWP.

Bill_Kasdorf: One other point the doc makes clear is that we should show examples of solutions where we can.
... we need to be generally agnostic to also future-proof this work.
... Another notable section is the emphasis on the manifest.
... In the example on the URL for a PWP, noted the ".pwp" extension. Have we discussed a media-type registration?

ivan: no, we have not.
... the definition of a media-type is something we can decide much later. We should leave this open for now.
... to define a media-type when content and description is defined by the W3C is fairly easy.

Bill_Kasdorf: many of the things we're talking about are not near-term things.

<daniel-weck> EPUB media type: https://www.iana.org/assignments/media-types/application/epub+zip

tzviya: You touched on the manifest. That's one of the more crucial aspect that this group needs to address.
... In order to talk about the linking mechanisms, we need to know what's in the package. We need to know how to get to the components in the manifest.
... We need to not lose sight of that.
... 'Manifest' is not just an EPUB term; it's also a ZIP term, etc.

Bill_Kasdorf: The second to last note in the section raises a question: what about the case when a given resource is a component of more than one web publication?

ivan: then it would have three, or many.
... if I compare to EPUB (web friendly version) then an EPUB on the web still reflects the current EPUB structure.
... For PWP general case, we don't want this kind of restriction. There may be a shared JS library, or a shared CSS file that's shared among several PWPs.
... So then the question is how do we get there. Don't like the idea of getting three or more URLs, but don't know how to avoid it.
... This area will need further discussion.
... We could put redirects in the manifest, but not sure if that's the right way to go about this.
... The real work here is what should be in the manifest.

mgylling: Are we happy with the goals in the wiki, or do they need to be more instrumental?

tzviya: I would like to see more definitive goals from this group. It is not clear what the actual outcome is.

Bill_Kasdorf: Is there any disagreement with the high-level ideas here?

tzviya: Not sure we can say that fragment identifiers are out of scope, but we can say they are phase 2.

mgylling: The point of the first bullet is to say we are not going t create new identifier schemes.

Bill_Kasdorf: that matches my understanding.

mgylling: They might not be entirely out of scope; we might want to suggest that we need to clarify how to use existing identifier schemes properly.

ivan: Making it clear that we are not trying to boil this ocean is a good idea.

Bill_Kasdorf: The second bullet is the big catch-all. The TF needs to get together and clarify what those details are that we're going to focus on.

tzviya: We can do some of that on this call.

Bill_Kasdorf: The manifest issue, the multiple URL issue

TimCole: The locators, to me, are in fact a new class of identifiers. So don't want to revisit ISBN, but we still do need to follow the practice of how we create these locators so they can be real identifiers.

Bill_Kasdorf: Can you talk a bit about an OCLC control number or WorldCat (identifiers in the library world)?

TimCole: This comes up frequently in the library world. Someone may want to read "Moby Dick" and any copy of the text will do.
... A scholar will want to see the 1943 version. Someone may want a specific copy in a specific library.
... The OCLC tends to talk about the specific manifestation (the 1943 edition). But the item level is what we need to talk about.
... The individual copies is finer grained than the library world tends to think about.

tzviya: This might be getting into a level of detail that the TF should discuss on its own.

Bill_Kasdorf: Tim's main point, by doing what we're doing the locator becomes a type of identifier.

rdeltour: Wants a clarification on fragment identifiers. We should not touch this in the domain of HTML, but when we're talking about pointing at a manifest, we're on different ground.

tzviya: are you talking about how to get from the package to the manifest, or something else?

rdeltour: not sure yet. Fragment identifiers are well defined in an HTML document, but when we're talking about a manifest, not sure.

tzviya: If the manifest is an HTML file, we don't have any work to do. We have to define what the manifest is.

Bill_Kasdorf: When we talk about fragment identifiers, we talk about a fragment within a component. Do we need to make a distinction between component identifier and a fragment identifier?

rdeltour: My comment was about in the PWP doc, we have an example of a URI that uses a new separator, and don't see a difference between using a new identifier scheme, and a new separator.

ivan: The fragment identifier is something we use when we get to a constituent resource. rdeltour is right; there may be content in a PWP for which there is no fragment identifier defined yet, so we may have to look at them.
... if we decide that the manifest is HTML, then we already have a fragment identifier definition, and we should use that.
... getting to the content is exactly the problem I am trying to tackle, and don't know how to solve.
... using the ! looks very much like a fragment identifier; don't like that approach and would prefer something that looks like a "real" URL, but then you have to think about reuse of resources
... One of the goals is to clarify what is the way to get to the content if we have a URI for the PWP.
... A locator becomes an identifier (correct) but we should try to keep away from defining what kind of URL patterns or style we should use.
... we have enough religious warfare in the world - don't go there.

<TimCole> +1 to Ivan's comments

mgylling: that leads us to the third bullet in the wiki. If the TF can come up with a recommendation for change on how EPUB identifiers work, that will be welcome but is not required.
... We cannot guarantee forward compatibility for EPUB 3.1 identifiers.
... Our hope is that the identifier scheme(s) can be inherited by EPUB
... what if we made a change to require one locator type identifier to be int he package, and have it be known which one it is within a group of potential identifiers? It would help with forward compatibility.
... This mission is yours, TF, if you choose to accept it.

tzviya: hope the TF is clear on the goals?

Bill_Kasdorf: We are clear that we need to become clearer.

tzviya: Because of the tie-n with EPUB 3.1, we do have a timeline. Our next step is to schedule a meeting.

ivan: suggests scheduling a doodle poll for a set call slot for a few weeks. Because of the tie-n with EPUB 3.1, we do have a timeline.

Scheduling next meeting

tzviya: Our next step is to schedule a meeting. Are people around on the 4th?

<clapierre1> 1+

<laudrain> +1

<ivan> +1

mgillying: We could give the Jan 4 slot to the Locators TF.

ivan: good idea; do that, and still set up a doodle poll for the meetings after.

Bill_Kasdorf: will send two posts to the list: one about the TF list meeting on the 4th, and a second with the doodle poll for a regular meeting (weekly/bi-weekly TBD)
... decision: weekly

<laudrain> best wishes to all!

tzviya: Use the list. Enjoy it. Love it. It will make you productive.
... how do I close out the minutes?

<ivan> thank you heather!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/21 17:43:58 $