- From: Nick Ruffilo <nickruffilo@gmail.com>
- Date: Mon, 4 Jan 2016 16:15:36 -0500
- To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
- Cc: Charles LaPierre <charlesl@benetech.org>, "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>
- Message-ID: <CA+Dds58x2qcryAR9oPByZ7c2rDrdKs3u2DZZKsfnAJu4oxq6RQ@mail.gmail.com>
Tzviya, In my theoritical model, I was assuming something like this: When the offline mode is generated, if the Mona Lisa picture is considered an "essential" for offline, it would be downloaded and have a home within the root of the PWP that is: /www.louvre.org/monalist/img.png and it's internal reference would point to that. The image would also be included in the package. -Nick On Mon, Jan 4, 2016 at 4:07 PM, Siegman, Tzviya - Hoboken < tsiegman@wiley.com> wrote: > The paragraph that Charles highlighted is exactly the point that we spent > so much time discussing today. > > > > Let’s say that the Louvre’s digital rendition of the Mona Lisa is the one > that is used in all books. When I include the Mona Lisa in my PWP, be it An > Introduction of Renaissance Art, Doctoral Thesis on Leonardo’s expression > of Smiles in Oils, or the Da Vinci Code, what is the locator in <img > src=””>? > > > > Should it be www.louvre.org/monalisa (the original locator for Mona Lisa) > or should it be https://pwp.server.com/publication1/f01 (or whatever pwp > locators looks like) (the local locator for Mona Lisa in this publication)? > If It is the latter, and we are talking not just about images (which have a > defined mechanism for locators on the web), how do we define this thing > we’ve been calling a package? > > > > This is really just a manifest – a list of locators. Online, that is a > method of organizing websites, not too different from what we see on the > web today, just a little more structured. To get to the offline state, > something has to happen to put all the things at the other end of the URLs > in a package. So, we arrive again at the importance of the manifest. > > > > > > (Maybe this is what all those people who were talking about books as APIs > should have meant 3 years ago when I was rolling my eyes because I was > tired of the term.) > > > > *Tzviya Siegman* > > Digital Book Standards & Capabilities Lead > > Wiley > > 201-748-6884 > > tsiegman@wiley.com > > > > *From:* Charles LaPierre [mailto:charlesl@benetech.org] > *Sent:* Monday, January 04, 2016 3:45 PM > *To:* Nick Ruffilo > *Cc:* DPUB mailing list (public-digipub-ig@w3.org) > *Subject:* Re: Musings on PWP Offline/Online Modes > > > > I like this idea Nick, especially the part about > > > > This could have many benefits. Imagine that there are a bunch of > scholarly publications that all reference a single image/diagram. The > web-based PWP version can reference a single online canonical URL, whereas > the offline PWP can have it's own local instance (meaning less duplication, > and the ability to update all the online PWPs at once if there is an update > to that image. This is OPTIONAL, so if someone wanted to do a snapshot, > they just reference a local image. > > > > > > Now lets say there is are extended descriptions for this image, a 3D model > of this image, and/or a Tactile representation of this image with a Tour > description explaining what the tactile image is. Now this is done only > once and all PWP’s would point to this image with its attached extended > descriptions. The packager which would create the offline version could > also grab these extended descriptions as well. Custom Elements could be > used here to interact with these alternative representations of the image. > > > > Thanks. > > > > Charles LaPierre > Sr. Software Engineer > charlesl@benetech.org > > > > On Jan 4, 2016, at 9:28 AM, Nick Ruffilo <nickruffilo@gmail.com> wrote: > > > > > > The conversation today got me thinking - and maybe it's the new year > crazies, but I got to thinking of the true value of having something of a > PWP "engine" that would provide unique value. Below are some use cases and > what I feel is an interesting way to handle those cases: > > > > *The "vanilla" fully-offline package* > > This is probably closest to what epub is today. All the files for the PWP > are located in the same base, and besides the occasional <a href=""> link > that points to an external resource, all items are contained within a > package. With little effort, the package can exist on a server and as long > as there is a reading system that can handle the manifest, the content can > be read in a linear or whatever method we end up with. > > > > I think we're all in agreement here - ignoring word choice like manifest, > etc. > > > > > > *The web-page-in-a-box* > > Fonts live on other servers, images live on other servers, CSS Frameworks > live on a CDN, It's a beautiful (messy) web. How does this become > offline? This would require heavy lifting on the part of the browser or > the server (whatever generates the document) but imagine if the packager > could take these resources offline. > > > > *Example*: I'm reading a wikipedia article, and I want to download it as > a PWP. Wikipedia could specify a list of resources (heck, even a > hyper-minified version of their CSS) as well as all the images related to > that Wikipedia article. All of those get packaged into a PWP that I can > download and read whenever. YES IT WILL BE A SNAPSHOT of the page at that > time, but that isn't necessarily a bad thing... It could even have update > instructions (or an update URL). > > > > External resources get added to the root path in some way like: > /http/somedomaincom/path/to/external/file.css > > > > This could have many benefits. Imagine that there are a bunch of > scholarly publications that all reference a single image/diagram. The > web-based PWP version can reference a single online canonical URL, whereas > the offline PWP can have it's own local instance (meaning less duplication, > and the ability to update all the online PWPs at once if there is an update > to that image. This is OPTIONAL, so if someone wanted to do a snapshot, > they just reference a local image. > > > > For publishers - they could have a common CSS framework that they could > keep up-to-date, so that if they found a bug, or decided that they wanted > body color to be bright orange, they could update it once, and all new > offline PWPs that are generated get that. > > > > Since this is 100% optional, those who wanted full control can simply opt > to create their content fully within a single root. The ability to be able > to specify certain online resources to be "critical" to an offline package > could create production benefits (and yes, I realize it could also create > some headaches). > > > > > > > -- > > - Nick Ruffilo > > @NickRuffilo > > http://Aerbook.com <http://aerbook.com/> > > http://twitch.tv/TheWizardLlewyn > > http://ZenOfTechnology.com <http://zenoftechnology.com/> > > > > > > > > > -- - Nick Ruffilo @NickRuffilo http://Aerbook.com http://twitch.tv/TheWizardLlewyn http://ZenOfTechnology.com <http://zenoftechnology.com/>
Received on Monday, 4 January 2016 21:16:06 UTC