W3C home > Mailing lists > Public > public-digipub-ig@w3.org > January 2017

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

From: Paul Tykodi <ptykodi@tykodi.com>
Date: Mon, 23 Jan 2017 11:55:10 -0500
To: "'Nick Ruffilo'" <nickruffilo@gmail.com>
Cc: "'Leonard Rosenthol'" <lrosenth@adobe.com>, "'W3C Digital Publishing IG'" <public-digipub-ig@w3.org>, "'Ivan Herman'" <ivan@w3.org>
Message-ID: <02b501d27599$75f740b0$61e5c210$@tykodi.com>
Hi Nick,

 

One observation regarding accessibility.

 

I believe that the future consumers of WP and PWP content will expect the standard describing these formats to explain very concretely “how” to make WP or PWP content accessible.

 

In my opinion, this is the role the W3C played pre-merger. I believe the WCAG guidelines have been very useful in providing a framework that regulatory agencies with enforcement powers have been able to leverage when writing digital accessibility regulations.

 

It is my opinion that the Digital Publishing IG should focus on describing accepted methods for making WP and PWP content accessible so that regulatory agencies can then define appropriate accessibility rules for WP and PWP formats going forward.

 

Best Regards,

 

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi@tykodi.com <mailto:ptykodi@tykodi.com> 
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

 

This e-mail reply and any attachments are confidential and may be privileged.

If you are not the intended recipient, please notify Tykodi Consulting Services LLC 

immediately by replying to this message and destroying all copies of this message 

and any attachments. Thank you

 

From: Nick Ruffilo [mailto:nickruffilo@gmail.com] 
Sent: Monday, January 23, 2017 10:19 AM
To: Ivan Herman <ivan@w3.org>
Cc: Leonard Rosenthol <lrosenth@adobe.com>; W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: Some significant items for discussion on "What is a Web Publication?"

 

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 <mailto:ivan@w3.org> > wrote:

 

On 23 Jan 2017, at 14:42, Leonard Rosenthol <lrosenth@adobe.com <mailto: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.   <mailto:ivan@w3.org> @Ivan Herman 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 < <mailto:ivan@w3.org> ivan@w3.org>
Date: Monday, January 23, 2017 at 1:29 PM
To: Leonard Rosenthol < <mailto:lrosenth@adobe.com> lrosenth@adobe.com>
Cc: W3C Digital Publishing IG < <mailto:public-digipub-ig@w3.org> 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 < <mailto:lrosenth@adobe.com> 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 :).   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> 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 [ <http://w3c.github.io/dpub-pwp/#bib-frbr> 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/> http://www.w3.org/People/Ivan/
mobile: +31-641044153 <tel:+31%206%2041044153> 

ORCID ID:  <http://orcid.org/0000-0003-0782-2704> http://orcid.org/0000-0003-0782-2704



 

 


----
Ivan Herman, W3C 
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153 <tel:+31%206%2041044153> 

ORCID ID: http://orcid.org/0000-0003-0782-2704




 





 

-- 

- Nick Ruffilo

@NickRuffilo

Aer.io <http://Aer.io>  an INGRAM company

 
Received on Monday, 23 January 2017 16:55:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:37 UTC
https://lists.w3.org/Archives/Public/public-digipub-ig/2017Jan/0061.html
lists.w3.org
crawl=CC-MAIN-2021-43
32652
application/http; msgtype=response
sha1:M5NRKDXAY4UP2VAWE6QU4NEK3UQFJSPC
<urn:uuid:1857caac-3a76-46c8-b20e-fcb626d84088>
2021-10-17T07:35:45Z
128.30.52.41
application/xhtml+xml
sha1:JVRD3M6KNX6YMEYD55XA4OSANLPOK3LL
<urn:uuid:dfc2d438-0ec9-4bfc-8604-bd5dd9689463>
https://lists.w3.org/Archives/Public/public-digipub-ig/2017Jan/0061.html
response
<urn:uuid:a359a966-c2d2-4528-af43-3c8f18aadc8e>
isPartOf: CC-MAIN-2021-43
publisher: Common Crawl
description: Wide crawl of the web for October 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-88
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/