Re: Some significant items for discussion on "What is a Web Publication?"

On Mon, Jan 23, 2017 at 4:19 PM, Nick Ruffilo <nickruffilo@gmail.com> wrote:

> A general comment - The more concise a definition, the better it serves
> its constituents.
>

+1

Regards,
Dave
--
David Wood

On Mon, Jan 23, 2017 at 4:19 PM, Nick Ruffilo <nickruffilo@gmail.com> wrote:

> A general comment - The more concise a definition, the better it serves
> its constituents.  The Open Web already allows content creators to do some
> amazing things.  Extending things, and taking them a step further with PWP
> is a great way to ensure certain functionality not already available
> becomes available making publications play nicer on the open web platform.
>
> For example (and this is NOT an assertion I'm making), a Textbook might
> make a great PWP but a Course (as referenced previously in this thread)
> might not fit the definition of a PWP.  But that doesn't mean that a course
> cannot live on the open web platform (in fact, tons already do).
>
> Alternatively - what *is not* is just as important as what *is *when it
> comes to a definition.  It would be good for us to be clear as to how we
> are defining what a publication is.  As we've seen with the web, content
> creators will always be super creative given the limitations and create
> products that go far beyond our imagining, but having a limited scope
> definition will yield the best results.
>
> ** stands on soapbox * *I vote that accessibility be a must.  More than
> ever, equality is a key and fundamental right.
>
> -Nick
>
> On Mon, Jan 23, 2017 at 10:01 AM, Ivan Herman <ivan@w3.org> wrote:
>
>>
>> On 23 Jan 2017, at 14:42, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>
>> > I have the advantage to be on the other side of the pond
>> >
>> Me too today, sitting in Paris…
>>
>>
>> :-) I was actually wondering before you reacted on something on the issue
>> list this morning; but I had colleagues who worked very late at night in
>> the US, I thought you are one of those...
>>
>>
>>
>> I also agree with both of you – using the later definition is good and
>> they should be merged.  @Ivan Herman <ivan@w3.org> did you want to do
>> that or should I?
>>
>>
>>
>> Let us wait until after the call. I would like to hear Dave's reaction
>> before changing things, who has originally proposed this text.
>>
>>
>> > I believe we do have to say that a WP must have a unique identifier.
>> >
>> Yes, we all agree on that…
>>
>>
>> >Maybe we should remove or change the word 'origin'?
>> >
>> It’s a special word for web folks, so we should either use it with the
>> same meaning or (my preference) not use it at all.
>>
>>
>>
>> I think the original context in which it was used is important, but I
>> would agree not to use the term. I proposed to say ""a Web Publication's
>> identity is essential information…". Remember that this is an introductory
>> text, not a formal specification.
>>
>>
>> >I believe the term 'functional' is sufficiently (and intentionally)
>> vague: it does not imply that it should have exactly the same features,
>> >it only says that it should not be impossible to consume the WP's
>> content when it is offline.
>> >
>> And I disagree.  If an author wishes to construct a WP that only works
>> when online, they should be able to.   Remember we are talking about a WP
>> here, not necessary a PWP.  And that's an important different we need to
>> remember – WP vs. PWP.
>>
>>
>>
>> Hm. "P" stands for "Packaged" these days, not "Portable", so I am not
>> sure this is relevant. I think we disagree on this, let us see what others
>> say.
>>
>>
>>
>> > Terminology put aside, I do not understand what the problem is with
>> the description of a manifest (in the more technological sense).
>> >
>> Since we don’t know what a manifest will look like or contain, other than
>> as a list of things, we shouldn't state anything about how it is (or is
>> not) used – such as ordering or presentation.
>>
>>
>>
>> And the text does not say anything about the format. However, as we have
>> seen in the discussion on the UCR, the fact that we need to make, somehow,
>> the list of resources and the default consuming order available seems to be
>> essential for a WP. The text should say (maybe another way of saying this?)
>> that conveying this type of information as part of the creation of a WP is
>> essential. (I do not want to use the word 'metadata' for this, because that
>> term is also used in different ways…)
>>
>> Ivan
>>
>>
>> Leonard
>>
>>
>> *From: *Ivan Herman <ivan@w3.org>
>> *Date: *Monday, January 23, 2017 at 1:29 PM
>> *To: *Leonard Rosenthol <lrosenth@adobe.com>
>> *Cc: *W3C Digital Publishing IG <public-digipub-ig@w3.org>
>> *Subject: *Re: Some significant items for discussion on "What is a Web
>> Publication?"
>>
>> Leonard & al,
>>
>> (I have the advantage to be on the other side of the pond, ie, that you
>> have already discussed some of the issues while I was asleep:-)
>>
>>
>> On 22 Jan 2017, at 17:16, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>
>> While working on the PWP document today, I can into a few things that I’d
>> like to raise for discussion (either via email or phone tomorrow, or both).
>>
>> Let’s start right up front with the definition of a Web Publication J.
>> It currently reads “A Web Publication (WP) is a bounded collection of
>> resources, envisioned and created as a whole”.  I would like to review the
>> second half of that sentence – about the envisioned and created as a
>> whole.  In the world of documents, the most popular feature of processing
>> applications is the ability to combine parts of other documents together to
>> create a new one.  In that use case, the resources weren’t “envisioned and
>> created as a whole”.  You could say that the author/publisher envisioned
>> that collection and intentionally collated those resources together – but
>> that’s different from what is here.  I would also put forth that the
>> application of annotations to a WP can create a new WP that also was not
>> “envisioned and created as a whole”.
>>
>>
>>
>> I tend to agree with David, that the definition elsewhere in the document
>> ("A Web Publication (WP) is a collection of one or more constituent
>> resources, organized together in a uniquely identifiable grouping, and
>> presented using standard Open Web Platform technologies.") is more precise.
>> I would probably retain that as a "formal" definition of a WP. (As an
>> aside, we should indeed avoid double definitions.)
>>
>> That being said: if I do not consider the statement above as being the
>> formal definition of a WP, but rather as a higher level description of what
>> we are after. Leonard, you seem to read the half sentence ("envisioned and
>> created as a whole") to refer to the *resources*. I actually read the
>> same half sentence as referring to the *collection*, and *not* to the
>> individual resources.  If one reads that sentence like that, then I do not
>> see any problem with all the rest of the issues you describe: the
>> additional act of creating the WP is to collect all the resources into one
>> coherent resource which *is* then considered as a whole. Whether the
>> individual resources were thought to be part of that collection from the
>> start or not is then besides the point.
>>
>> What about something like:
>>
>> "A Web Publication (WP) is a bounded collection of resources, where the
>> collection is envisioned and created as a whole"
>>
>> May be sounds a bit more convoluted, but more precise.
>>
>>
>>
>> There is a requirement that “The package must include the unique
>> identifier of the manifestation—a Web Publication’s origin is essential
>> information if a PWP becomes portable”.  Two paragraphs later it goes into
>> further detail about the origin inclusion and even mentions trust.
>> Unfortunately, that requirement seems to imply some potential
>> implementation considerations that the WebPackaging work is proving to not
>> be feasible – see https://github.com/dimich-g/webpackage/issues/7.  I
>> would like to remove the second half of that sentence (about the origin)
>> and also remove the bit about trust from the latest paragraph.  Let’s just
>> leave it open that we want a unique identifier, but that’s it, and that the
>> origin is not necessarily related to the identifier.
>>
>>
>>
>> I am not sure what you mean by "Let's just leave it open that we want a
>> unique identifier". To make it clear, I believe we do have to say that a WP
>> must have a unique identifier. But I am not sure that the word 'origin' is
>> to be taken literally here, ie, that the origin must be an HTTP address. It
>> can be a generic URN of some sort, a DOI in http form, whatever. It is an
>> 'origin' in the abstract sense. I do not see how that would imply any
>> implementation issue apart from the fact that it must be available.
>>
>> Maybe we should remove or change the word 'origin'? Simply say "a Web
>> Publication's identity is essential information…"
>>
>>
>>
>> Here’s the one where George, Charles and others are going to be scream –
>> but I believe it is an extremely important point – you can’t mandate
>> accessibility in a WP (ie. “A Web Publication must be accessible to the
>> broadest possible range of readers”). We should make it a strong
>> recommendation (a “should” vs. a “shall” in ISO terminology) and do all we
>> can to promote this direction.  However, given our goals to support not
>> only curated publications but also ad-hoc publications, it is not
>> reasonable to expect them all to be accessible.  Just as not every page on
>> the web is accessible, web publications need not be either.
>>
>>
>>
>> I am torn on that one, to be honest. Just as, I believe, we do not say
>> anywhere at W3C that a Web Page MUST be accessible, I wonder whether can do
>> anything more for a WP in general. After all, the goal of this (and
>> subsequent) work is to make WP-s first class entities on the Web,
>> minimizing the step it takes to go from a 'traditional' web site to a WP.
>>
>> We may get into a different discussion if we were to impose a MUST on
>> EPUB4, for example, but I tend to agree with Leonard on this one for
>> general WPs.
>>
>>
>>
>> Another area that we cannot mandate – but should make a strong
>> recommendation – is that “A Web Publication must be available and
>> functional while the user is offline”. An author may produce a publication
>> that is only designed to be used online – for example, one that connects to
>> an online system. We don’t wish to prevent the development of such a
>> publication.
>>
>>
>>
>> I think offline/online is one of the essential features that
>> differentiate WPs from average Web pages. I believe the term 'functional'
>> is sufficiently (and intentionally) vague: it does not imply that it should
>> have exactly the same features, it only says that it should not be
>> impossible to consume the WP's content when it is offline. (The, by now
>> evergreen, example of different fonts come to my mind.) If it connects to
>> an online system: it depends what it means. Obviously, a gmail application
>> cannot really function offline (although one could imagine a complicated
>> caching system), ie, it would not be a WP. I am fine with that. On the
>> other hand, a mathematical publication reaching out, say, to a Maple server
>> to run examples if necessary, but where the core of the publication is
>> simply the mathematical theory is fine; the necessary examples should just
>> make it clear to the user that he/she should be online to use that.
>>
>> Ie, we may want to make it clearer what 'functional' means, but I would
>> stick with the rest of the sentence.
>>
>>
>>
>> Finally, I think we say too much about the use of the manifest.  It says
>> “We also introduce the abstract concept of a manifest, which serves to
>> carry information about the constituent resources of the publication, their
>> sequence, and presentation”.  I think we should only say that it carries
>> the resources and not mention sequence and presentation. This is consistent
>> with our statement, earlier in the same section, about how we aren’t going
>> to define “manifest” (and leave it in the generic FRBR sense).
>>
>>
>>
>> I am not sure I agree. I think it is an editorial issue; the term
>> manifest in "which must be “manifested” (in the FRBR [frbr
>> <http://w3c.github.io/dpub-pwp/#bib-frbr>] sense) by having files on a
>> Web server" seems to be used in a very different way than "concept of a
>> manifest, which serves to carry information about the constituent resources
>> of the publication, their sequence, and presentation". I guess the first
>> occurrence of the term clearly refers to FRBR only, and that is different.
>> Maybe we should use a different term in the second usage although,
>> unfortunately, the terminology is there.
>>
>> Terminology put aside, I do not understand what the problem is with the
>> description of a manifest (in the more technological sense).
>>
>> Talk to you later!
>>
>> Ivan
>>
>>
>>
>>
>>
>>
>> Leonard
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Technical Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153 <+31%206%2041044153>
>>
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Technical Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153 <+31%206%2041044153>
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>
>
> --
> - Nick Ruffilo
> @NickRuffilo
> Aer.io an *INGRAM* company
>
>