Re: definition of "publication"

> On 9 Nov 2015, at 09:42, Hiroshi Sakakibara <sakakibara.hiroshi@bpsinc.jp> wrote:
> 
> On Sat, 7 Nov 2015 14:09:25 +0100
> Ivan Herman <ivan@w3.org> wrote:
> 

<skip>
>> 
>> The DPUB IG spent a certain amount of time trying to nail down a general notion of publication, more exactly a Web Publication. See
>> 
>> http://w3c.github.io/dpub-pwp/
>> 
>> more exactly
>> 
>> http://w3c.github.io/dpub-pwp/#terminology
>> 
>> the definitions are fairly abstract, and we should add more 'meat' in the coming months, eg, to fill in details of a manifest, on URL-s, etc. But maybe it helps framing the discussion.
>> 
>> Ivan
> 
> Thank you for letting me know the PWP information.
> I read through the PWP site.  This is very informative for me.
> 
> It would be better to clarify the publication definition with PWP
> members.

More specifically, this is the Digital Publishing Interest Group (DPUB IG)

> Where can I find the current cooking status of the 'meat'?
> (Github issues?)
> 

The IG has a mailing list:

W3C Digital Publishing IG <public-digipub-ig@w3.org>

but, specifically, the PWP has indeed an issue list

https://github.com/w3c/dpub-pwp/issues

> 
> For my understanding, I illustrated an architectural figure[1].
> The items listed right-hand does not cover whole publication/PWP
> information yet.
> 

I see Daniel has already answered some questions; I do not really have anything to add to those


> This figure raises some questions and thoughts:
> 
> 1) Where dose POM position in the software architecrue?
>   For ease of use, it should not be implemented in browser. But POM
>   should interact with browser.
> 2) How should "PWP Control data" be presented?
>   Is this data a part of Web document?
>   (I'm still wondering content data and control data should be
>   devided or not.  And what "devided" means in fact..)

Daniel already referred to the fact that the UI aspect is not in scope for POM. Beyond that, what you call the control data, we currently refer to as a manifest. What exactly the manifest should include I cannot tell at this moment, we did not really work on that aspect yet. However, the EPUB example (the OPF file) gives a pretty good idea of the information that we will probably have to provide for a PWP; actually, the discussion on POM will also dictated some of these.

Ivan


> 3) (From PWP document) I want to have UI controlling mechanism for
>   contents.
>   Current EPUB have TOC. Most of EPUB viewer has TOC button, and TOC
>   meta information is listed.
>   Travel guide books or other scientific publications require
>   TOC-like button to list up or to point other information.
>   The meta information differs depending on the contents.
>   So, UI controlling way from contents to RS is needed.
>   (In fact, I talked with JP guide book publishing company and
>   Japanese classics publishing company, and both of them require such
>   mechanism.)
> 
> [1] http://www.tsukune.org/skk/tmp/pom/arch.png
> 
> 
> PWP site has a lot of information, so I'm still in constructing my
> thoughts... Sorry for kitchen sink mail.
> 
> --- Hiroshi/skk
> 
> 
>>> About haxe, don't focus too much on it. I started using it because it
>>> is compilable into both JS and c++ but that's a kitchen sink, really.
>>> 
>>> Personal note: I had health issues during the last days, hence my lack
>>> of messages here.
>>> 
>>> </Daniel>
>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>> 
>> 
>> 
>> 
> 
> --
> Sakakibara Hiroshi (skk@bpsinc.jp)
> Beyond Perspective Solutions Co., Ltd.
> Tel: +81-3-6279-4320 Fax: +81-3-6279-4450
> Web: http://www.bpsinc.jp/
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704