Re: Behavioral Adpational Content cases

I'm sure that I'm preaching to the choir, but there are several challenges
with URI fragments.  Mostly I'm cribbing from our points here:
http://openannotation.org/spec/core/core.html#FragmentURIs as segments of
resources are crucial for annotation, and we struggled with the various
requirements *a lot*.

* Fragments are media type specific.  So that CFI is EPUB specific is
somewhat by requirement, though I agree it could still be /more/ generic.

* While fragments are media type specific, URIs are not.  If the same URI
content negotiates to return multiple media types ... say EPUB and PDF ...
then the same segment is identified by different, independently developed
fragment specifications.

* The same fragment can identify different segments of the same resource,
depending on the particular media type returned.  For example, see the
polysemy noted in Jeni Tenison's document:
http://www.w3.org/TR/fragid-best-practices/

* Fragments may not be consistent over time, and (apart from Memento:
http://tools.ietf.org/html/draft-vandesompel-memento-11) time is not
considered in the web architecture.


Regarding media fragments, we contacted them every few months between 2009
and when the spec went to 1.0 asking, actually begging, for a well designed
extension mechanism baked in from the beginning. Our requests were ignored,
even when some of the editors were on the OACG list.  So my perspective is
that getting anything else in to that spec should only be attempted as an
absolute last resort, or by someone carrying a bit stick.

Rob



On Fri, Nov 8, 2013 at 3:44 AM, 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
>
>
>
>
>
>