RE: [dpub identifiers]The publication/package/fragment ID dilemma

The packaging spec addresses scope, but we haven’t yet.

There are about 30 issues that we’ve put on the table:

Scope
Range
Component + Fragment
Content type (rendition selection)
Granularity
State of content (wrt to stability of URL)
State of content (wrt accessing material)

I came up with this list in 3 minutes.  Perhaps our first step should be to organize our goals, and, as Ivan recommended identify to what extent each scheme meets these goals.


Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Matt Garrish [mailto:matt.garrish@bell.net]
Sent: Monday, March 23, 2015 5:10 PM
To: Bill Kasdorf; Siegman, Tzviya - Hoboken; public-digipub-ig@w3.org
Subject: Re: [dpub identifiers]The publication/package/fragment ID dilemma

Isn’t the problem of which rendition of the content to use missing from the discussion so far?

A CFI tells you how to get to a unique location from a given spine, but doesn’t tell you which spine it is. It’s a problem that’s been “solved” a couple of times – during the open annotation integration and for mapping documents – but adds complexity.

Or are multiple renditions of the content within a single package out of scope for this work?

Matt

From: Bill Kasdorf<mailto:bkasdorf@apexcovantage.com>
Sent: Monday, March 23, 2015 3:23 PM
To: Siegman, Tzviya - Hoboken<mailto:tsiegman@wiley.com> ; public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Subject: RE: [dpub identifiers]The publication/package/fragment ID dilemma

Yes, definitely. CFI therefore addresses two of those three aspects. To rephrase what you said a bit, it points to a component of the package (e.g., an XHTML content doc), and then further points to a fragment within that component (e.g., as granular as down to a specific word or even character).
--Bill K

From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com]
Sent: Monday, March 23, 2015 3:00 PM
To: Bill Kasdorf; public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Subject: RE: [dpub identifiers]The publication/package/fragment ID dilemma

I may be suffering from skimming too quickly, but I think one of the key points that Ivan was making is that some of the methods we’ve seen address the issue if pointing to a point in a package and then address the issue of pointing to the fragment within the package.

So, an EPUBCFI

#epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)

Everything prior to the ! indicates the location within the package. Everything after the ! indicates the location within the specific document identified.

Whether this is needed will depend on the packaging scheme.

I very much agree with Markus’s comment that the URI should look the same in all states.

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Bill Kasdorf [mailto:bkasdorf@apexcovantage.com]
Sent: Monday, March 23, 2015 12:59 PM
To: public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Subject: [dpub identifiers]The publication/package/fragment ID dilemma

On the call today (minutes at [1]) we decided to get the Identifiers TF discussion going on the list before organizing a conference call.

I'd like to start by raising a high-level issue. On the call, we discussed three different aspects of this issue:

--Identifying a fragment within a resource. The resource could be a textual document (in XML, or in HTML, or other); it could be media (e.g., a portion of a video); or it could be any number of other possible components of an EPUB-WEB publication. Ivan points out that there are already existing specific fragment identification schemes for various media, and suggests that we should be agnostic as to what scheme is used, so that a user can employ the scheme that makes the most sense. Markus pointed out that it is still useful to specify _how_ to address fragments in various EPUB-WEB components; so while that strategy acknowledges the need to tailor the fragment ID scheme to the media, it might lead to specific recommendations for specific types of media ("reference fragments in XML this way, HTML this way, video this way," etc.).

--Identifying the constituent component of a package (for an EPUB-WEB publication in the packaged state) that contains the intended fragment, and also enabling the same mechanism to be used when the EPUB-WEB publication is in the online state.

--Identifying the publication itself. Note that I strongly advocate that we standardize on the term "publication," e.g. rather than "document," because a publication can consist of many documents; and this helps people not reflexively think "book."

So here's my high-level issue: should we discuss this on the list holistically, or should we break this into three threads? Or should we start with a discussion of this way of looking at the problem, and _then_ fork it off into separate threads?

--Bill K

[1] http://www.w3.org/2015/03/23-dpub-minutes.html



Bill Kasdorf
Vice President, Apex Content Solutions
Apex CoVantage
W: +1 734-904-6252
M: +1 734-904-6252
@BillKasdorf<http://twitter.com/#!/BillKasdorf>
wlmailhtml:bkasdorf@apexcovantage.com
ISNI: 0000 0001 1649 0786
https://orcid.org/0000-0001-7002-4786<https://orcid.org/0000-0001-7002-4786?lang=en>
www.apexcovantage.com<http://www.apexcovantage.com/>

[cid:image001.jpg@01D0658C.EB991790]