Locators and Packages

[dauwhe]

There's been email discussion of related issues, but it seems worthy of a GitHub issue. Section 4.2.2 gives us numerous locators for unpackaged, packaged, and "canonical" versions of a publication and constituent resources:

unpackaged
https://example.org/books/1/
https://example.org/books/1/img/mona_lisa.jpg
packaged
https://example.org/packed-books/1/package.zip
canonical
https://example.org/published-books/1
https://example.org/published-books/1/img/mona_lisa.jpg

What's not clear to me is, do we need locators for resources inside a packaged publication? To borrow Daniel Weck's old ! notation, do we need to have something like this?:

https://example.org/packed-books/1/package.zip!/img/mona_lisa.jpg

Another question is why do we need a separate "canonical" locator? What's the advantage of https://example.org/published-books/1/img/mona_lisa.jpg over https://example.org/books/1/img/mona_lisa.jpg?

In all of the above cases, my manifest would list the image as having an href of img/mona_lisa.jpg. This has got to be one of the best use cases for relative URLs ever! Do we really need hrefsrc?

{ "href": "img/mona_lisa.jpg", "hrefsrc": "https://example.org/books/1/img/mona_lisa.jpg" }

Both the web and EPUB don't seem to need this...

[lrosenthol]

The reason you need the URLs to resources inside a packaged publication is
if the publication is posted online in a packaged form AND there is a
desire/need to refer to something inside of it - for example, a data set in
a technical/STEM publication. (think Linked Open Data)

As to why you need hrefsrc (or the equivalent), is to enable a few of the
use cases in the UCR. For example, the packaging of a web publication
without modification or for external updates to resources.

On Wed, Nov 16, 2016 at 11:53 PM, Dave Cramer [email protected]
wrote:

There's been email discussion of related issues, but it seems worthy of a
GitHub issue. Section 4.2.2 gives us numerous locators for unpackaged,
packaged, and "canonical" versions of a publication and constituent
resources:

unpackaged
https://example.org/books/1/
https://example.org/books/1/img/mona_lisa.jpg
packaged
https://example.org/packed-books/1/package.zip
canonical
https://example.org/published-books/1
https://example.org/published-books/1/img/mona_lisa.jpg

What's not clear to me is, do we need locators for resources inside a
packaged publication? To borrow Daniel Weck's old ! notation, do we need
to have something like this?:

https://example.org/packed-books/1/package.zip!/img/mona_lisa.jpg

Another question is why do we need a separate "canonical" locator? What's
the advantage of https://example.org/published-books/1/img/mona_lisa.jpg
over https://example.org/books/1/img/mona_lisa.jpg?

In all of the above cases, my manifest would list the image as having an
href of img/mona_lisa.jpg. This has got to be one of the best use cases
for relative URLs ever! Do we really need hrefsrc?

{ "href": "img/mona_lisa.jpg", "hrefsrc": "https://example.org/books/1/img/mona_lisa.jpg" }

Both the web and EPUB don't seem to need this...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#29, or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1vNZOt5v8O9HFrCSM5FGnpz0yUgJaBks5q-93BgaJpZM4K02GY
.