15:04:48 <RRSAgent> RRSAgent has joined #dpub-loc
15:04:48 <RRSAgent> logging to http://www.w3.org/2016/01/27-dpub-loc-irc
15:04:49 <Bill_Kasdorf> Bill_Kasdorf has joined #dpub-loc
15:05:12 <ivan> Present+ Ivan, Bill, Ben, Luc, Romain, Tzviya
15:05:18 <tzviya> tzviya has joined #dpub-loc
15:05:31 <laudrain> laudrain has joined #dpub-loc
15:05:54 <laudrain> Present+ Luc
15:05:56 <bjdmeest_> bjdmeest_ has joined #dpub-loc
15:06:22 <tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Jan/0147.html
15:06:35 <tzviya> chair: Ben_de_Meester
15:06:46 <mgylling> mgylling has joined #dpub-loc
15:07:53 <tzviya> scribe: tzviya
15:08:34 <tzviya> ben: There has been some discussion about content negotiation for canonical version of URL
15:08:49 <tzviya> ...Romain mentioned that this is not ideal
15:09:06 <DanielWeck> DanielWeck has joined #dpub-loc
15:09:28 <DanielWeck> present+ Daniel Weck
15:09:41 <mgylling> present+ Markus
15:09:41 <DanielWeck> usual pass does not work?
15:09:47 <DanielWeck> (WebEx)
15:10:45 <tzviya> Romain: What is relevance of content negotiation for PWP?
15:11:52 <tzviya> ivan: (summarizing conversation) What is frequently done with namespaces in sem web world
15:12:11 <tzviya> ...When there is a vocab in semweb, there is a namespace, which is a URI
15:12:47 <tzviya> ...The vocab is expressed in RDF and can be expressed in various serializations: turtle, JSON-LD, RDF XML
15:13:43 <tzviya> ...You have different URLs. You have the canonical URL, which is the namespace (example PROV)
15:13:45 <ivan> namespace for prov voc: http://www.w3.org/ns/prov
15:14:03 <ivan> ....prov.ttl
15:14:07 <tzviya> Ivan: This is the official URL for the Provenance vocab
15:14:12 <ivan> ....prov.rdf
15:14:30 <tzviya> ...and the other serializations have different extensions
15:15:03 <tzviya> ....What happens if you issue HTTP GET against canonical URL?
15:15:37 <tzviya> ...returns Turtle RDF, because there is server preference for turtle
15:16:03 <tzviya> ...Content negotiation works such that the client states preference for one serialization
15:16:10 <mgylling> q+
15:16:19 <tzviya> q?
15:17:16 <tzviya> Ivan: the ttl and rdf expressed the same information in different formats
15:17:30 <tzviya> ...This is the model i had in mind for PWP
15:18:17 <tzviya> ...whether archived or online, the URL of PWP is irrelevant
15:19:05 <tzviya> ...packaged or unpackaged version should be an issue for client preferences
15:19:24 <tzviya> ...Many dislike content negotiation
15:19:57 <tzviya> ...This requires apache work and caching of what?
15:20:09 <Bill_Kasdorf> +1 I really like Ivan's conceptual model
15:20:31 <tzviya> ...If I have PWP in archived, zip format, and I have it online - are these fundamentally the same or different?
15:20:53 <mgylling> q++
15:21:03 <mgylling> q?
15:21:24 <Zakim> Zakim has joined #dpub-loc
15:21:47 <tzviya> romain: I want to look at this as approaching from HTTP standpoint
15:22:09 <tzviya> ...on one hand, making GET request
15:22:21 <Bill_Kasdorf> q+
15:22:51 <tzviya> romain: this is also a question of usability
15:23:08 <tzviya> ...With RDF, most users are machines
15:23:21 <ivan> q+
15:23:43 <tzviya> ...We are talking about human users. As a human, I can't make a decision about whether to access packaged/unpackaged form
15:24:06 <tzviya> ...I think we can assume that we are talking about 2 different URLs
15:24:19 <rdeltour> rdeltour has joined #dpub-loc
15:24:39 <Bill_Kasdorf> my comment will be quick
15:25:22 <bjdmeest_> ack bill
15:25:25 <ivan> ack Bill_Kasdorf
15:25:39 <tzviya> romain: when you make a GET request from a resource, must look at semantic equiv of resource. On one hand look at HTML, on the other han it is the full resource
15:25:51 <mgylling> q+
15:26:12 <tzviya> bill_Kasdorf: we may be drawing too much a distinction between packaged/unpackaged
15:26:57 <bjdmeest_> ack ivan
15:27:12 <tzviya> ...Most PWPs will have some external resources - so we have publications that are both ends of the spectrum and in the middle
15:27:50 <tzviya> ivan: referring to romain - you make assumption that in 1 case, return the whole package, in other case, return the HTML file
15:28:07 <tzviya> ...that might not be, maybe return the manifest
15:28:22 <tzviya> ...which represent the package
15:28:30 <rdeltour> for the record: the other aspect of my comment was about usability: a user browsing the web doesn't have control on the HTTP headers when she clicks a link (unlike a piece of software accessing an RDF resource). hence a proactive-conneg-only approach cannot work in the general case, we *have to* have 2 disinct URLs.
15:28:43 <tzviya> ...this is just like the semweb case. We have different URLs for different purposes
15:29:21 <tzviya> ...There is a URL that does not make the distinction because need it for reference purposes
15:29:29 <rdeltour> q+
15:29:35 <tzviya> ...Perhaps we are not disagreeing
15:30:11 <bjdmeest_> ack mgylling
15:30:17 <tzviya> ...If I do not make the distinction bw formats, i am just referring to the content, regardless of format
15:30:40 <tzviya> markus: would we be helped by stepping back and looking at high level design goals?
15:31:06 <tzviya> ...Depending on perspective, we reach different conclusions
15:31:27 <tzviya> ...Romain's conclusions are based on effects of using HTTP - rings a bell
15:32:17 <tzviya> ...current situation is functionally awful - locating and linking is a mess for EPUB, anno, etc
15:32:33 <mgylling> Two high-level design goals:
15:32:34 <mgylling> 1) when a PWP is online at its canonical location, linking and addressing works exactly as on the web
15:32:35 <mgylling> 2) when a PWP is detached from its canonical location, linking and addressing works exactly as if the PWP was located at 1
15:32:36 <mgylling> ... a client may in case 2 have to do active intercepts to enable #2. Compare to how browser
15:34:41 <tzviya> markus: point 2 is the high level issue - must establish equivalence between the two. No user should ever realize the difference between online/offline
15:35:00 <laudrain> q+
15:35:10 <tzviya> ack rd
15:35:32 <tzviya> romain: I agree that we should look at higher level and return to use cases
15:35:40 <tzviya> ...we lack use cases around portability
15:36:12 <mgylling> s/is online/is online and unpacked/
15:36:35 <tzviya> ...We have to figure out what we mean by portability
15:37:04 <tzviya> ...If I understand correctly, the packaged version has significance when it is downloaded and moved around?
15:37:10 <tzviya> markus: yes
15:37:11 <ivan> q+
15:37:50 <bjdmeest_> ack laudrain
15:38:38 <tzviya> luc: is item 1 shared URL for all users and item 2 local address for individuals?
15:39:03 <Bill_Kasdorf> q+
15:39:33 <tzviya> ...The second one could be a unique PWP for my personal use
15:39:41 <tzviya> ack iv
15:39:50 <tzviya> ivan: I love what luc said
15:41:57 <tzviya> ...This differentiation is very important. There is a major difference between the package that is mine - the URL for this packaged format cannot be different from the canonical, and the URL for the pacakge on my disk
15:42:47 <tzviya> ...It may not be realistic to maintain the same URL throughout the life of the product for security reasons (especially once downloaded)
15:43:30 <tzviya> ...But, differentiating between downloaded and online seems to be the way to go
15:43:46 <tzviya> ...We do very badly need the use cases
15:44:04 <bjdmeest_> q?
15:44:37 <tzviya> Luc: Please clarify what Markus's case 1 is
15:45:11 <ivan> q+
15:45:44 <tzviya> ...is it that everyone from every country points to the same address? Or, is it that this URL is unique to me to annotate, etc.?
15:47:13 <bjdmeest_> ack Bill
15:47:53 <rdeltour> q+
15:48:00 <tzviya> bill_K: This is not about the state of the publication or about whether it's changed
15:48:10 <bjdmeest_> ack ivan
15:48:51 <Bill_Kasdorf> s / or about whether it's changed / but about whether it's changed
15:49:22 <tzviya> ivan: (speaking for Markus) for me, the issue is about 1 and 2 together
15:50:58 <laudrain> q+
15:51:05 <rdeltour> q-
15:51:33 <tzviya> ...as long as we are talking about the online and offline models, the offlinifaction is only relevant if I pass the publication on to someone else
15:51:47 <laudrain> what is the « canonical location »? the publisher manifestation?
15:51:59 <tzviya> ...Once I pass it on to another user, she can do with it what she wants
15:52:14 <Bill_Kasdorf> this is why we need a hierarchical model for the locator (a la FRBR)
15:52:20 <tzviya> luc: I am asking for clarification of canonical location
15:52:52 <tzviya> ...the canonical location does not belong to anyone. What happens next, such as annotations, does not belong to anyone
15:53:02 <tzviya> markus: yes, and that is both good and bad
15:53:56 <tzviya> ...canonical loc is a term that we use to say the URL that is the reference point for the publication
15:54:38 <tzviya> ...If a user clones that URL or annotates, etc, will still be able to refer to canonical URL or local
15:54:53 <tzviya> ack l
15:55:34 <tzviya> ivan: We already have this. We called this identifier
15:56:06 <rdeltour> q+
15:56:08 <tzviya> ...When I make my own copy (in a different state) and manipulate it, what happens to the URL?
15:56:51 <tzviya> ...what happens when someone in a PWP makes a cross-reference with a canonical URL?
15:57:19 <tzviya> markus: do we have to define how the URL is mutated when doing FRBR-lebel ops?
15:57:25 <tzviya> ack rd
15:57:33 <laudrain> s/lebel/item/
15:57:55 <tzviya> romain: not sure i agree that canonical URL is identifier
15:57:58 <tzviya> ivan: +1
15:59:16 <ivan> rrsagent, set log public
15:59:49 <rdeltour> I'll create gh issues as placeholders for discussion on use cases
16:00:12 <ivan> rrsagent, draft minutes
16:00:12 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/27-dpub-loc-minutes.html ivan
16:00:23 <laudrain> laudrain has left #dpub-loc
16:00:30 <rdeltour> rdeltour has left #dpub-loc
16:00:34 <DanielWeck> DanielWeck has left #dpub-loc
18:00:18 <Zakim> Zakim has left #dpub-loc