Closed marcoscaceres closed 7 years ago
This section also needs to be "unpackaged".
The document states:
A user agent may not be able to process files beyond a certain size due to bandwidth, storage or memory limitations, or processing time expectations; this information should be available in advance.
These are implementation details. That's not a use case.
The document states:
For example, it needs to know whether it has the rights to place an image of the Mona Lisa owned by the Louvre in a package to be downloaded offline.
That's an author decision, not an application decision.
On the title of the section: I am hesitant about renaming to 'metadata'; if we do not want to use the word manifest, then we will have to use a different word (knowing the intimidating size of English vocabulary, I am sure there is a word for it:-).
For many people, at least in the library or publishing community but also elsewhere like the medical informatics world, the term 'metadata' is bound to some sort of a formal specification of terms in the form of an ontology. This may be defined in XML, in RDFS/OWL, in UML, or using other formalism: there examples for all of these. In other words, using that term may be too loaded as well.
Yes, the term 'manifest' may be loaded by now as well.
(EPUB uses the term 'package document' for this. It is even worse:-)
Any better idea?
A user agent may not be able to process files beyond a certain size due to bandwidth, storage or memory limitations, or processing time expectations; this information should be available in advance.
These are implementation details. That's not a use case.
Yes, candidate for removal! Agreed
For example, it needs to know whether it has the rights to place an image of the Mona Lisa owned by the Louvre in a package to be downloaded offline.
That's an author decision, not an application decision.
It is fundamentally true (although, of course, this may be more complicated, and may mean that a reference to the publicly available right information on the Mona Lisa should be made available. But even doing that is the author's/publisher's job indeed.
Proposed solution (after reorg):
The author/publisher should provide, when appropriate the rights of various components identified in the package; e.g., the rights relevant to the image of the Mona Lisa owned by the Louvre on whether it is permissible to download the image for offline use.
I have to say that "manifest" may have some baggage, but it is an apt description both from EPUB and, e.g., Web Apps. So, perhaps stick with the term, until/unless it's proven unneeded.
I have to say that "manifest" may have some baggage, but it is an apt description both from EPUB and, e.g., Web Apps. So, perhaps stick with the term, until/unless it's proven unneeded.
Manifest serve a use case, but they are a means to an end... they are not themselves the use case. Ultimately, yes, some kind of manifest may be the logical solution: but it can't be the starting point - that frames the whole thing backwards.
(Admin: see https://github.com/w3c/dpub-pwp-ucr/commit/8c80f753ae8b901ea211c0ac21af35ba7dac1d24 for some of the changes made, but the terminology issue keeps this issue open)
I agree with @iherman and @marcoscaceres that manifest is a loaded term - but for now, I left it alone in the update.
See http://w3c.github.io/dpub-pwp-ucr/index.html#terminology and http://w3c.github.io/dpub-pwp-ucr/index.html#technical-metadata in revised document (along with sections that discuss resources).
This section should really be called "Metadata". Manifests are concrete solutions, and basically confuse the use cases because they are a solution looking for a problem.
The section tries to pretend otherwise, by stating that "'manifest' refers to an abstract place" (heh, how meta)... but then falls back to "typically one or several files, that contain information necessary to the proper management, rendering, and so on, of the publication".