- From: Bill Kasdorf <bkasdorf@apexcovantage.com>
- Date: Mon, 4 Jan 2016 22:08:53 +0000
- To: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>, "public-digipub-ig@w3.org" <public-digipub-ig@w3.org>
- Message-ID: <CY1PR0601MB14228FADB42288DDF3B6D05ADFF20@CY1PR0601MB1422.namprd06.prod.outlook.>
Both very valid points!
From: Heather Flanagan (RFC Series Editor) [mailto:rse@rfc-editor.org]
Sent: Monday, January 04, 2016 4:57 PM
To: public-digipub-ig@w3.org
Subject: Re: Musings on PWP Offline/Online Modes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 1/4/16 1:05 PM, Bill Kasdorf wrote:
>
> That's getting a little far afield, I think. Many scholarly
> publications—even as short as a single journal
article—reference
> hundreds of other publications. It would never be anybody's
intention
> to include those in a PWP.
>
In a different use case, though, such as standards publications, this is a very useful idea. I can see how a standard with normative references to other standards might be best packaged as a body of work.
>
>
> This also gets way out on thin ice on the ownership issue.
Somebody
> creating PWP 1 would run into a lot of resistance if she
pointed to
> PWP 2 and PWP 3, each authored by others, and asserted that
they are
> now part of her PWP 1. Referencing them, okay; _/including/_
them,
> not so much. Depending of course on the rights asserted for
PWP 2 and
> PWP 3; certain CC licenses would actually permit that, others
> wouldn't.
>
Well, that's a typical copyright/fair use thing. I don't think we can solve for that in the PWP spec?
- -Heather
>
>
> --Bill K
>
>
>
> *From:*Nick Ruffilo [mailto:nickruffilo@gmail.com] *Sent:*
Monday,
> January 04, 2016 3:52 PM *To:* Charles LaPierre *Cc:* DPUB
mailing
> list (public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>) *Subject:* Re: Musings on PWP
> Offline/Online Modes
>
>
>
> Another benefit would also be in instant creation of volumes.
> Imagine that you could link to an additional PWP... Lets
ignore the
> possibility for recursion and simply insanely large additions
> (because these are solvable things, although worth noting)
>
>
>
> I don't know TOO much about scholarly publishing, but I can
imagine
> being a student writing a thesis paper, and including a host
of
> referenced materials. Imagine if all of those materials
could be
> included - and THEIR references. In most cases, a link would
suffice
> (and SHOULD suffice) but there are cases where one would want
to
> include the entire reference to allow for deep-reading in an
offline
> mode given a consistent and unchanging set of data...
>
>
>
>
>
>
>
> On Mon, Jan 4, 2016 at 3:44 PM, Charles LaPierre
> <charlesl@benetech.org<mailto:charlesl@benetech.org>
<mailto:charlesl@benetech.org><mailto:charlesl@benetech.org>> wrote:
>
> 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<mailto:charlesl@benetech.org>
> <mailto:charlesl@benetech.org><mailto:charlesl@benetech.org>
>
>
>
> On Jan 4, 2016, at 9:28 AM, Nick Ruffilo
<nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>
> <mailto:nickruffilo@gmail.com><mailto: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://aerbook.com/>
>
> http://twitch.tv/TheWizardLlewyn
>
> http://ZenOfTechnology.com
<http://zenoftechnology.com/><http://zenoftechnology.com/>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> - Nick Ruffilo
>
> @NickRuffilo
>
> http://Aerbook.com
>
> http://twitch.tv/TheWizardLlewyn
>
> http://ZenOfTechnology.com
<http://zenoftechnology.com/><http://zenoftechnology.com/>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCAAGBQJWiuqfAAoJEER/xjINbZoGfIcIAJ6tacvi9Lvx6Um84tJNzQYr
s4+e8MG1F3aBDJRiJOB9IW2q1VZWxHMXkVb6wAmJj3pxrcvdA2K592COUYg9VH+v
JGoV12NmNaLDpUA4VnTRWdc8LPhfUqm4ydw1wSS2WLzzaNOpxWMJkVz98aJaUWwM
zVWFbq0ZJhWaNJDoBGydvGJCR1E6naIWlnnEcOXDoUJyowW7CPr0UkZOXSEFU9ep
hJ4L0TLBd7YFZc3Bq7QJ5GRUuCBVmPOGcUgSq4hrKheKyjeu0tWAT/EKyZTs6+kO
zklCrt0dYbhD0oSsG2N5W4vV1a77z1w+XuP5PD6k4RhCbBDcIadlwznN9a7mQ6M=
=CJIV
-----END PGP SIGNATURE-----
Received on Monday, 4 January 2016 22:09:27 UTC