13:19:19 <RRSAgent> RRSAgent has joined #dpub-loc
13:19:19 <RRSAgent> logging to http://www.w3.org/2016/02/03-dpub-loc-irc
13:19:26 <ivan> rrsagent, set log public
13:19:31 <Zakim> Zakim has joined #dpub-loc
13:19:52 <ivan> Meeting: DPUB IG Locator TF call
13:19:59 <ivan> Chair: Ben De Meester
13:20:21 <ivan> Agenda: http://www.w3.org/mid/CAJ-O9TtyMUbsD5SO5b20ynEtvo789jp4-8DjVJbhgHcfcYkXBQ@mail.gmail.com
14:51:43 <dauwhe> dauwhe has joined #dpub-loc
14:57:19 <rdeltour> rdeltour has joined #dpub-loc
14:59:12 <tzviya> tzviya has joined #dpub-loc
14:59:28 <bjdmeest> bjdmeest has joined #dpub-loc
15:00:42 <laudrain> laudrain has joined #dpub-loc
15:00:55 <laudrain> Presnt+ Luc
15:01:00 <tzviya> present+ Tzviya
15:01:05 <bjdmeest> Present+ Ben_De_Meester
15:01:05 <rdeltour> present+ Romain
15:01:05 <dauwhe> present+
15:01:15 <tzviya> regrets+ Ivan, Markus, Daniel
15:02:29 <dauwhe> scribenick: dauwhe
15:02:48 <dauwhe> bjdmeest: let's being
15:02:50 <tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Feb/0024.html
15:02:57 <dauwhe> s/being/begin/
15:03:09 <dauwhe> ... romain reviewed the use cases; I tried to come up with a couple
15:03:26 <dauwhe> ... do these use cases make sense?
15:03:42 <dauwhe> ... romain said we need more use cases across states
15:04:01 <dauwhe> rdeltour: thanks for use cases
15:04:07 <dauwhe> ... i think that's what we need
15:04:21 <dauwhe> ... the review I did was for existing use cases; some were outdated
15:04:25 <dauwhe> ... some are missing
15:04:35 <dauwhe> ... in terms of process, we should not write new ones to the wiki
15:04:48 <dauwhe> ... and then we edit in document or create issues
15:04:54 <dauwhe> ... directly on github
15:05:11 <dauwhe> ... I haven't reviewed your new cases yet, but they look like what we need
15:05:25 <dauwhe> bjdmeest: does it make sense to go over them now?
15:05:37 <Bill_Kasdorf> Bill_Kasdorf has joined #dpub-loc
15:05:50 <dauwhe> ... we could start locaters doc and put new use cases there
15:06:22 <dauwhe> tzviya: Ivan says we should have use cases in a single place
15:06:35 <dauwhe> ... we want these right in Romain's doc
15:06:39 <dauwhe> rdeltour: I think this is OK
15:06:59 <dauwhe> ... we can discuss use cases on calls, then when we have consensus I can add to html doc
15:07:12 <dauwhe> tzviya: we could enter use cases as issues in github
15:07:15 <dauwhe> rdeltour: that could work
15:07:27 <dauwhe> ... they won't need to be fully edited; can be just an idea
15:07:44 <dauwhe> tzviya: I'm trying to avoid having this be a once-a-week topic
15:08:02 <dauwhe> rdeltour: some epub use cases are not there
15:08:21 <dauwhe> ... there is one source file that is sent to many retailers--that's how EPUB works today
15:08:29 <Bill_Kasdorf> present+ Bill_Kasdorf
15:08:36 <Bill_Kasdorf> sorry I'm late
15:08:40 <dauwhe> ... all these retailers make the book available to customers
15:08:51 <dauwhe> ... and the epub is downloaded to devices or cloud + devices
15:09:01 <dauwhe> ... or synced to several devices
15:09:15 <dauwhe> ... or made available to customer-specific cloud
15:09:24 <dauwhe> ... and I can access this file through different applications
15:09:34 <dauwhe> ... either directly or downloaded from private cloud
15:09:54 <dauwhe> ... this epub file is duplicated many, many, many, many, many times
15:10:44 <dauwhe> ... so there are a huge number of items
15:10:57 <dauwhe> ... there is one source manifestation, one isbn identifier,
15:11:09 <dauwhe> ... there are lots of items spread across devices and buyers
15:11:24 <dauwhe> ... how will we address this in pwp?
15:11:30 <Bill_Kasdorf> thanks, Luc, this is a really core issue
15:11:42 <dauwhe> rdeltour: that's unclear to me as well
15:11:53 <dauwhe> ... we are lacking use cases about transitioning from state to state
15:12:00 <dauwhe> ... i was thinking about distribution and delivery
15:12:13 <dauwhe> ... in most of our cases we're talking about a single user
15:12:34 <dauwhe> ... what distribution model is the user using
15:12:36 <bjdmeest> +1
15:12:48 <dauwhe> laudrain: I should try to describe this use case, perhaps with small graphic
15:13:00 <dauwhe> tzviya: I think writing the use case as you described it is very clear
15:13:09 <rdeltour> +1
15:13:23 <dauwhe> ... publishers distribute one epub to many retailers, and we have to explain what this means for pwp
15:13:35 <dauwhe> ... is it the packaged state that goes to the retailer?
15:13:47 <dauwhe> ... is it up to the retailer to maintain portability?
15:13:50 <Bill_Kasdorf> q+_
15:14:05 <tzviya> q?
15:14:08 <tzviya> ack bi
15:14:12 <tzviya> ack _
15:14:15 <dauwhe> Bill_Kasdorf: it's not necessary the packaged file
15:14:30 <dauwhe> ... vitalsource might provide the unpackaged file online and not deliver a packaged state
15:14:48 <dauwhe> tzviya: we need to point out that this is how publishers work
15:14:55 <dauwhe> ... and we need to explore retail model
15:15:04 <dauwhe> ... vitalsource does both packaged and unpackaged
15:15:15 <dauwhe> Bill_Kasdorf: we need to be agnostic around package vs unpackage
15:15:47 <dauwhe> rdeltour: maybe copy/pasting the minutes into github issue is what we need
15:16:05 <dauwhe> ... but Luc's use case is about epub, may need to adapt to pwp
15:16:33 <dauwhe> laudrain: it's highly probable that publishers will produce packaged and unpackaged thing in pwp in futre
15:16:40 <dauwhe> s/futre/future/
15:17:05 <dauwhe> ... the packaged/unpackaged might not be a publisher question, but more a consumer/retailer issue
15:17:18 <dauwhe> ... publisher needs to prepare doc in advance
15:17:30 <dauwhe> ... there is a delivery function, packaged or unpackaged
15:18:05 <dauwhe> ... delivery means something coherent as a whole, maybe a single folder or a zip or something newer
15:18:13 <dauwhe> ... this delivery is of a whole
15:18:26 <dauwhe> rdeltour: that's the kind of detail we want in the use cases
15:18:37 <dauwhe> ... how does publisher want to transmit to the retailer?
15:18:46 <dauwhe> ... we must be very detailed in requirements
15:18:52 <dauwhe> ... sending a zip is sending a package
15:19:09 <dauwhe> ... if you want to allow transmitting the unpackaged publication, using ftp or rsync or something
15:19:16 <dauwhe> ...we should be explicit about that
15:19:34 <dauwhe> laudrain: it's true with canonical location we could transmit only the locater to the retailers
15:19:45 <dauwhe> ... and they would have to grab the publication
15:20:02 <dauwhe> ... not sure if we will be working like this in future
15:20:08 <dauwhe> ... question is what is the canonical location
15:20:24 <dauwhe> bjdmeest: this is something to be discussed
15:20:40 <dauwhe> ... we should start from the down-to-earth current use cases
15:20:47 <dauwhe> ... without getting lost in possible solutions first
15:20:48 <rdeltour> +1
15:21:10 <dauwhe> ... we can move to the other use cases
15:21:27 <dauwhe> ... I will add those use cases as github issues
15:21:41 <dauwhe> ... and concerning the old ones,
15:21:53 <dauwhe> ... are there any other comments?
15:22:05 <dauwhe> ... the review of romain was to the point and made sense
15:22:14 <dauwhe> ... are there other remarks on those use cases?
15:22:22 <dauwhe> ... otherwise we can focus on new use cases
15:22:35 <dauwhe> tzviya: you had some questions?
15:22:52 <dauwhe> bjdmeest: just want to wrap up use cases discussion
15:23:13 <dauwhe> (vocal and enthusiastic consent)
15:23:35 <dauwhe> ... do we agree on some sort of canonical url
15:23:58 <dauwhe> ... iif we have pwps that are the same content-wise, is there a url that binds them?
15:24:03 <dauwhe> ... doesn't have to be stateless
15:24:13 <dauwhe> ... grouping pwps that are the same but in a different state
15:24:27 <dauwhe> tzviya: someone must have an opionion about this :)
15:24:38 <dauwhe> rdeltour: not sure I agree on canonical url as we define it now
15:24:57 <Bill_Kasdorf> q+
15:24:59 <tzviya> paginated view of use case repo: http://w3c.github.io/dpub-pwp-ucr/
15:25:11 <dauwhe> ... mostly because we have 2 dedicated urls, one for package, one for unpackage, third for canonical
15:25:13 <tzviya> Use case repo: https://github.com/w3c/dpub-pwp-ucr
15:25:19 <dauwhe> ... I'm not convinced 3 urls is good design
15:25:39 <dauwhe> ... once we have unpackaged pub on the web, the url to this will be shared via social media
15:25:46 <bjdmeest> q+
15:25:48 <dauwhe> ... and users will access this unpackaged url
15:25:55 <dauwhe> ... so the canonical url is not used
15:26:04 <dauwhe> ... so where does canonical url fit
15:26:22 <dauwhe> Bill_Kasdorf: I'm confused about whether we need a canonical url
15:26:36 <dauwhe> ... or a canonical segment of a url to be shared across states
15:26:44 <dauwhe> ... I want the url to resolve to an actual thing
15:26:53 <dauwhe> ... either to packaged or unpackaged
15:26:58 <dauwhe> ... but then you can get to the other
15:27:14 <dauwhe> ... in order to do that, the url syntax must begin with something canonical across all states
15:27:22 <dauwhe> ... it's a component of all the urls for that pwp
15:28:10 <dauwhe> bjdmeest: best practice would be that canonical url refers to accessible in easiest way--unpacked online
15:28:13 <tzviya> ack bi
15:28:22 <dauwhe> Bill_Kasdorf: how is that differnet from unpacked?
15:28:30 <dauwhe> ... so you declare unpackaged as canonical?
15:28:33 <dauwhe> bjdmeest: yes
15:28:45 <dauwhe> ... inside that package you have metadata with canonical url
15:29:00 <dauwhe> ... so you have connection between all urls
15:29:18 <dauwhe> Bill_Kasdorf: are we by default saying unpacked is canonical
15:29:26 <dauwhe> ... if publisher says packed is canonical
15:29:36 <dauwhe> ... can you get online?
15:29:51 <dauwhe> tzviya: I don't think publisher defines what is canonical
15:30:06 <dauwhe> laudrain: at which stage of distribution can canonical location be defined?
15:30:24 <dauwhe> bjdmeest: I think that's a valid point
15:30:36 <dauwhe> Bill_Kasdorf: additional states might be created over time
15:30:45 <dauwhe> ... all pointing to the same canonical pwp
15:30:51 <rdeltour> q+
15:30:53 <dauwhe> tzviya: why is that a problem
15:31:05 <dauwhe> Bill_Kasdorf: zip, tar are pacakged but not same
15:31:11 <tzviya> ack bj
15:31:16 <tzviya> ack rd
15:31:28 <dauwhe> rdeltour: I'm not sure that pwp always has a canonical url
15:31:40 <dauwhe> ... if a user creates a local pwp using local tools
15:31:49 <dauwhe> ... it wouldn't have a canonical url before it's published
15:31:58 <bjdmeest> +1000
15:32:08 <dauwhe> ... I'd say it doesn't have a canonical url unless it's available online
15:32:18 <dauwhe> laudrain: we could try to define from reader POV
15:32:30 <dauwhe> ... use cases are mainly about annotations--it's a reading question
15:32:43 <dauwhe> ... maybe publisher has nothing to do with canonical url
15:33:02 <dauwhe> ... it inherits a canonical url when distributed
15:33:19 <dauwhe> tzviya: I'd hesitate to define in reader terms, as they don't have understatning
15:33:25 <dauwhe> ... should use http perspective
15:33:32 <dauwhe> laudrain: perhaps define from upstream
15:33:44 <dauwhe> ... not downstream from publisher
15:34:03 <dauwhe> bjdmeest: you know where you got the pwp from
15:34:16 <dauwhe> ... if you got it from a certain website, that's teh first location you know
15:34:19 <dauwhe> ... as a reader
15:34:32 <dauwhe> laudrain: in that case depending on where I buy this pwp
15:34:37 <dauwhe> ... it may come from different locations
15:34:41 <dauwhe> bjdmeest: I think so
15:34:48 <dauwhe> ... this relates to ivan's comments
15:34:55 <dauwhe> ... about breadcrumbs of locaters
15:35:04 <dauwhe> ... this pwp is derived from this pwp
15:35:17 <dauwhe> ... I got it from company a, from publisher b
15:35:31 <dauwhe> ... we might need more granular derivation
15:35:54 <dauwhe> ... to move forward
15:36:07 <dauwhe> ... i'll write a first definition from an upstream point of view
15:36:20 <dauwhe> ... it will probably be very bad, but we can improve
15:36:36 <dauwhe> tzviya: are we using canonical url when we mean base url
15:36:47 <dauwhe> rdeltour: we're using canonical url without consensus on what it means
15:36:54 <dauwhe> tzviya: ivan says we might not need one
15:37:03 <dauwhe> tzviya: we need to talk about what we're trying to accomplish
15:37:19 <dauwhe> ... this group is tending towards the idea of a base url, www.book.com
15:37:44 <dauwhe> ... book.com that become book.com(#|/)other things
15:37:49 <dauwhe> Bill_Kasdorf: exactly
15:38:03 <dauwhe> tzviya: we've seen those proposals, with positives and negatives
15:38:13 <dauwhe> ... right?
15:38:19 <dauwhe> bjdmeest: yes
15:38:28 <dauwhe> tzviya: let's talk about that base url structure
15:38:40 <dauwhe> ... I don't know that we need to define the state of the base url
15:38:51 <dauwhe> ... what's the technical meaning of a publication having that base url
15:39:13 <dauwhe> laudrain: instead of book.com, could we say book.isbn.com?
15:39:23 <dauwhe> tzviya: it could be laudrain.com :)
15:39:28 <dauwhe> laudrain: it's unique
15:39:35 <dauwhe> Bill_Kasdorf: let's call it pwp1.com
15:39:40 <dauwhe> laudrain: idea is it's unique
15:39:43 <dauwhe> tzviya: could be orchid
15:40:02 <dauwhe> Bill_Kasdorf: if you use actionable doi, then that could point to different states
15:40:08 <dauwhe> tzviya: I'm not happy with DOI right now
15:40:14 <dauwhe> Bill_Kasdorf: that's how it works for journals now
15:40:17 <dauwhe> tzviya: when it works
15:40:51 <Bill_Kasdorf> s / orchid / ORCiD
15:40:51 <dauwhe> rdeltour: do we want to discuss nature of canonical url
15:41:05 <dauwhe> bjdmeest: would be good to get more comments in advance
15:41:12 <dauwhe> rdeltour: can we list consensus points
15:41:27 <dauwhe> ... pwp doesn't have canonical url until it's published online
15:41:31 <bjdmeest> +1
15:41:52 <dauwhe> Bill_Kasdorf: my reservation is
15:42:06 <dauwhe> ... principle is that there is no difference between online and offline
15:42:18 <dauwhe> rdeltour: if there is no online version, what happens?
15:42:29 <dauwhe> bjdmeest: doesn't make sense to have locator to offline version
15:42:36 <dauwhe> laudrain: in pwp there is web
15:42:45 <dauwhe> Bill_Kasdorf: I was confusing online iwth unpacked
15:42:58 <tzviya> s/iwth/with
15:43:04 <dauwhe> rdeltour: there is still a need to define locators for offline pwp
15:43:10 <dauwhe> ... as users would want to annotate
15:43:19 <dauwhe> ... and we need to reach internals
15:43:21 <dauwhe> tzviya: right
15:43:34 <dauwhe> bjdmeest: we first need to locate the pwp
15:43:40 <dauwhe> ... then locate resource in that pwp
15:43:49 <dauwhe> ... base url is about locating the entire thing
15:43:57 <dauwhe> ... then need to locate resources inside pwp
15:44:03 <rdeltour> +1
15:44:06 <dauwhe> ... I don't think the two should depend on each other
15:44:17 <dauwhe> laudrain: I'd like to go back to Romain statement about offline pwp
15:44:30 <dauwhe> ... I don't think an offline pwp can exist first
15:44:39 <dauwhe> ... i think the first state is online, when it's published
15:44:50 <dauwhe> ... before it's published there's no base url or canonical url
15:44:59 <dauwhe> ... it's not finished, it's not stable
15:45:03 <bjdmeest> +1
15:45:12 <dauwhe> ... it becomes available when published on the web
15:45:20 <dauwhe> ... so it cannot be first offline
15:45:57 <dauwhe> tzviya: my concern is taht this is saying
15:46:14 <dauwhe> ... a web publication doesn't mean it has to be published on the web
15:46:22 <dauwhe> ... we want this to encompass all the things
15:46:32 <dauwhe> ... I'm not going to create a website for my business doc
15:46:47 <dauwhe> ... some companies use epub for internal documentation, possibly on an intranet
15:46:53 <dauwhe> ... but might just be shared in other ways
15:47:08 <rdeltour> +1000
15:47:10 <dauwhe> ... or if we want pwp to be used for contracts, it can't be required to be online
15:47:20 <dauwhe> bjdmeest: does this mean it can't have a url?
15:47:30 <dauwhe> laudrain: it's like a namespace
15:47:43 <dauwhe> ... which might not have a webpage, although it's a url
15:47:54 <dauwhe> bjdmeest: that's clear agreement
15:48:16 <dauwhe> ... a pwp needs to have some kind of URL
15:48:29 <dauwhe> ... so that if it's moved or copied, the URL can connect them
15:48:39 <dauwhe> laudrain: the question after that is if we do publish to the web
15:48:47 <dauwhe> ... this url is supposed to point this content
15:48:52 <dauwhe> bjdmeest: i wouldn't make it a must
15:48:56 <dauwhe> ... it's a best practice
15:49:10 <dauwhe> ... to say that the URL is dereferencable to the actual content
15:49:19 <dauwhe> .... but that might not be possible or practical
15:50:00 <dauwhe> laudrain: also retailers :)
15:51:22 <dauwhe> bjdmeest: OPDS might be related work
15:51:26 <dauwhe> ... we can close this for now
15:51:41 <dauwhe> ... try to write something up as a base for discussion
15:52:04 <dauwhe> ... the last thing is more about the discussion between ivan and bill about breadcrumbs of locators
15:52:20 <dauwhe> ... if you download a pwp, then it's different from where you downloaded it from
15:52:24 <dauwhe> ... but points to it
15:52:37 <dauwhe> Bill_Kasdorf: if you download *and change* it's no longer the same pwp
15:52:44 <dauwhe> bjdmeest: yes
15:52:53 <dauwhe> ... it's always a different object
15:53:15 <dauwhe> Bill_Kasdorf: we're saying the pwp is really focused on the item, not the manifestation
15:53:32 <dauwhe> ... but Luc's scenario... do you now have thousands of pwps?
15:53:43 <dauwhe> tzviya: that's the point of what we're doing, to avoid that
15:53:55 <dauwhe> Bill_Kasdorf: only if you change it is it a different pwp
15:53:59 <dauwhe> tzviya: but we annotate
15:54:14 <dauwhe> bjdmeest: we could say the checksum is different, than you have a non-identical pwp
15:54:24 <dauwhe> Bill_Kasdorf: does the annotation use case survive that
15:54:36 <dauwhe> bjdmeest: yes, if you don't use the anno inside the pwp
15:54:46 <dauwhe> tzviya: as long as annos are not standalone
15:54:54 <dauwhe> ... same issue with annotating websites
15:55:07 <dauwhe> Bill_Kasdorf: that's why anno spec is important
15:55:16 <dauwhe> tzviya: the data model is what ties this together
15:55:23 <dauwhe> laudrain: is annotation part of the content?
15:55:30 <dauwhe> tzviya: it's more of a philosophical question
15:55:32 <dauwhe> bjdmeest: indeed
15:55:44 <dauwhe> Bill_Kasdorf: your tech description of the checksum is a nice clean way to do that
15:55:48 <dauwhe> ... the annos are outside that
15:55:53 <dauwhe> laudrain: I have another use case
15:56:07 <dauwhe> ... pwp where I have made updates (like a travel guide)
15:56:27 <dauwhe> ... so restaurant or hotel website or email address or phone can be updated
15:56:30 <dauwhe> ... the content changes
15:56:50 <dauwhe> bjdmeest: the content of your files themselves don't chagne
15:56:59 <dauwhe> laudrain: there may be a default, an initial value
15:57:04 <dauwhe> Bill_Kasdorf: there are 2 diff use cases
15:57:14 <dauwhe> ... if you issue a new one it's diff
15:57:24 <dauwhe> ... but if you dynamically update online it's not new
15:57:36 <dauwhe> bjdmeest: in first case you can say new pwp derived from old pwp
15:57:46 <dauwhe> ... can still make annos while keeping link to old one
15:57:57 <dauwhe> ... and your annos might survive all the different versions
15:58:07 <dauwhe> Bill_Kasdorf: that's where ivan's breadcrumbs come into play
15:58:23 <dauwhe> tzviya: do we want action items
15:58:43 <dauwhe> laudrain: I'm ok to copy/paste use case to github issue
15:59:02 <dauwhe> bjdmeest: I'll try to make a first suggestion on how this canonical url can be defined
15:59:07 <tzviya> rrsagent, make logs public
15:59:28 <dauwhe> ... these last few minutes of discussion were important for the breadcrumbs idea
15:59:43 <dauwhe> bjdmeest: that's it
15:59:49 <tzviya> rrsagent, make minutes
15:59:49 <RRSAgent> I have made the request to generate http://www.w3.org/2016/02/03-dpub-loc-minutes.html tzviya
15:59:50 <dauwhe> tzviya: I'll send around minutes
15:59:54 <dauwhe> bjdmeest: thanks all
16:00:03 <laudrain> laudrain has left #dpub-loc
16:05:57 <ivan> rrsagent, draft minutes
16:05:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/02/03-dpub-loc-minutes.html ivan
16:59:54 <tzviya> tzviya has joined #dpub-loc
17:59:02 <Zakim> Zakim has left #dpub-loc
18:02:24 <tzviya> tzviya has joined #dpub-loc
18:05:14 <ivan> ivan has joined #dpub-loc