You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 17, 2019. It is now read-only.
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:
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?:
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?
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.
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:
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?:
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?
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 needhrefsrc
?Both the web and EPUB don't seem to need this...
The text was updated successfully, but these errors were encountered: