- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 8 Nov 2013 21:13:54 +0800
- To: Markus Gylling <markus.gylling@gmail.com>
- Cc: "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, Thierry Michel <tmichel@w3.org>
- Message-Id: <E5304CC8-D63C-4586-96E7-091FDED0FDBE@w3.org>
On Nov 8, 2013, at 19:41 , Markus Gylling <markus.gylling@gmail.com> wrote: > Hi all, > >>> To my knowledge, epubcfi is not yet widely used. My impression is that this is primarily because there is not a tool to generate cfis, and manually creating them is cumbersome. Markus, is this your impression as well? > > At this time and as far as I know, it is primarily used for serverside storage of bookmarks/current reading position and such. One thing to remember is that EPUBCFI when published was not really a new invention, but a second open version of an initially proprietary concept+implementation that was used in a popular reading system EPUB 2 SDK, and thusly used under the hood in many services for years now. There are service providers who have literally millions of CFIs (v1 or v2) lurking on servers as I write this. > > That said, for the problems at hand, a generic (non-epub-specific) solution is of course preferable in the long term. One WG to keep in mind here re possible future feature addition work is Media Fragments, although given what they published in version 1.0 [1] did not address text range expressions it would appear that this is not seen as a priority for the web in general, at least not yet. I do not know the history here though in terms of priorities and such... Thierry may know more about it; he will be back from his vacations and be in Shenzhen... Ivan > > And, Tzviya, feel free to zap “adaptational” — I never heard this word either… ;) > > /markus > > [1] http://www.w3.org/TR/media-frags/ > > On 08 Nov 2013, at 11:44, Ivan Herman <ivan@w3.org> wrote: > >> >> On Nov 5, 2013, at 22:44 , Jean Kaplansky <Jean.Kaplansky@aptaracorp.com> wrote: >> >>> There may be more momentum to implement EPUBCFIs as more and more publishers start to work toward enriching their content semantically beyond the concept of a body of work as we currently understand it. >>> >>> I think some of this stuff may come from RDFa and annotations work. Other parts will come from semantic concepts that publishers are just beginning to think about when they look at their content now that there is a better understanding of what everyone can do with all of this “web stuff.” >>> >>> I’ve been hearing “semantic content enrichment” a lot over the last few weeks – more so than in the past couple of years. >> >> Good:-) >> >> My _personal_ problem with EPUBCFI is that it is EPUB specific, although the problem is clearly generic. Ie, I would love to see a fragment ID scheme for the same problem but which would not depend on, say, the EPUB Spine file... I realize this is not IDPF's problem:-), but I am looking at the larger picture that would also include, say, magazine publishers who may have very similar issues... >> >> But, as I say, this is only the general standard guy talking:-) >> >> Ivan >> >>> >>> Jean Kaplansky >>> Solutions Architect >>> Aptara, Inc. >>> Email: jean.kaplansky@aptaracorp.com >>> Skype: JeanKaplansky >>> Mobile: 518 487 9670 >>> >>> <ACD331E8-87DF-4649-A68D-1AC6C320CC10[3].png> >>> >>> From: <Siegman>, Tzviya - Hoboken <tsiegman@wiley.com> >>> Date: Tuesday, November 5, 2013 at 9:05 AM >>> To: Ivan Herman <ivan@w3.org> >>> Cc: "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org> >>> Subject: RE: Behavioral Adpational Content cases >>> Resent-From: <public-digipub-ig@w3.org> >>> Resent-Date: Tuesday, November 5, 2013 at 9:06 AM >>> >>> Thanks Ivan, >>> >>> To my knowledge, epubcfi is not yet widely used. My impression is that this is primarily because there is not a tool to generate cfis, and manually creating them is cumbersome. Markus, is this your impression as well? >>> >>> I think a discussion of identifiers and fragment identifiers affects many areas (annotations, some areas of pagination - especially as we consider corrections/updates) and merits further exploration. >>> >>> Apologies for not including a link the EPUB Indexing spec [1]. This spec is still in draft form. >>> >>> The LOC public vocabulary was not considered in the IDPF spec, but it looks quite promising. The EPUB spec does establish a method for creating categories of index terms within an EPUB. Using an existing vocabulary for these terms would be excellent. >>> >>> Thanks, >>> Tzviya >>> [1] http://carpeindexum.com/idpf/spec_test/build/epub-indexes.html >>> **************************** >>> Tzviya Siegman * Senior Content Technology Specialist * John Wiley & Sons, Inc. >>> 111 River Street, MS 5-02 * Hoboken, NJ 07030-5774 * 201-748-6884 * tsiegman@wiley.com >>> >>> >>> -----Original Message----- >>> From: Ivan Herman [mailto:ivan@w3.org] >>> Sent: Tuesday, November 05, 2013 3:10 AM >>> To: Siegman, Tzviya - Hoboken >>> Cc: DPUB mailing list (public-digipub-ig@w3.org) >>> Subject: Re: Behavioral Adpational Content cases >>> >>> Tzviya, others, >>> >>> Two comments (there should be more, of course...) >>> >>> there is a common (obvious) thread through the examples, and that is the identification of text ranges in terms of, say, a URI that can then be used by vocabularies and others. The question I have is: how widely is epubcfi[1] used, implemented? What are the experiences with it? After all, on paper, it gives a way to identify ranges, which seems to be part of the problems (orthogonal to the issue we began to discuss yesterday on having a URI for the book instance itself; epubcfi could then be combined with such an ID I presume). >>> >>> This question is important because, at this moment, epubcfi is confined to ePUB structures, and cannot be used directly to cover a similar problem in an on-line magazine, for example (which is also in our interest...). This IG _may_ conclude that a separate specification, defining some sort of a fragment ID for HTML5 in general, is necessary. To be clear, at this moment no such group exists (it is currently not in scope of the HTML5 WG), so it may require a new group to be set up probably at W3C. Which is all right, if there is an interest for it, but that has to be thoroughly documented... >>> >>> I also have another question. I know there are efforts at the moment at IDPF on indexing although, shame on me, I do not know the details. Has there been any thought of providing some canonical approach to access external categories, terminologies, established by others. As an example, there is a public vocabulary (using SKOS) established by the LoC[2], which can be used as basic terminology by everyone (and is also used by libraries, afaik), and it would be good if (e)books could directly refer to those when appropriate... >>> >>> Thanks! >>> >>> Ivan >>> >>> >>> [1] http://www.idpf.org/epub/linking/cfi/epub-cfi.html >>> [2] http://id.loc.gov/authorities/subjects.html see, eg, http://id.loc.gov/authorities/subjects/sh85077507.html for the subject heading 'literature' >>> >>> >>> On Nov 4, 2013, at 22:00 , "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com> wrote: >>> >>>> Hi DPUB, >>>> >>>> Thanks to Ivan for helping me with my wiki woes. I have begun posting use cases about behavioral adaptional content. (aside: adaptional is not a word. Can we switch to adaptive?) >>>> >>>> Please take a look, add your comments and your use cases. I will add more cases as time allows this week. >>>> http://www.w3.org/dpub/IG/wiki/StructSem_UC >>>> http://www.w3.org/dpub/IG/wiki/Behavioral_UC#Behavioral_1 >>>> http://www.w3.org/dpub/IG/wiki/Behavioral_UC2#Behavioral_2 >>>> http://www.w3.org/dpub/IG/wiki/Behavioral_UC3#Behavioral_3 >>>> http://www.w3.org/dpub/IG/wiki/Behavioral_UC4#Behavioral_4 >>>> >>>> One more wiki issue - how does one get HTML tags display? I'm not writing in HTML, just trying to include some sample tags in the body of the use case, but the wiki is interpreting the tags as markup. >>>> >>>> Tzviya >>>> **************************** >>>> Tzviya Siegman * Senior Content Technology Specialist * John Wiley & Sons, Inc. >>>> 111 River Street, MS 5-02 * Hoboken, NJ 07030-5774 * 201-748-6884 * tsiegman@wiley.com >>>> >>> >>> >>> ---- >>> Ivan Herman, W3C >>> Digital Publishing Activity Lead >>> Home: http://www.w3.org/People/Ivan/ >>> mobile: +31-641044153 >>> FOAF: http://www.ivan-herman.net/foaf >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> ---- >> Ivan Herman, W3C >> Digital Publishing Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> FOAF: http://www.ivan-herman.net/foaf >> >> >> >> >> > > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf
Received on Friday, 8 November 2013 13:14:48 UTC