w3c / dpub-pwp-ucr

Use Cases and Requirements for (Packaged) Web Publications
https://w3c.github.io/dpub-pwp-ucr/
Other
11 stars 19 forks source link

6. Manifest should be "Metadata and Processing instructions" #122

Closed marcoscaceres closed 7 years ago

marcoscaceres commented 7 years ago

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".

marcoscaceres commented 7 years ago

This section also needs to be "unpackaged".

marcoscaceres commented 7 years ago

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.

marcoscaceres commented 7 years ago

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.

iherman commented 7 years ago

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?

iherman commented 7 years ago

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

iherman commented 7 years ago

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.

iherman commented 7 years ago

Proposed solution (after reorg):

  1. Find an alternative for the term manifest (or metadata), if possible
  2. Remove the first 'usage example'
  3. Change the second 'usage example' as follows:

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.

GarthConboy commented 7 years ago

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.

marcoscaceres commented 7 years ago

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.

iherman commented 7 years ago

(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)

lrosenthol commented 7 years ago

I agree with @iherman and @marcoscaceres that manifest is a loaded term - but for now, I left it alone in the update.

iherman commented 7 years ago

157 (and earlier versions, actually) include an entry in the intro part as some sort of a disclaimer for what we mean, in this document, by 'manifest'. I think that should be o.k. for this document.

TzviyaSiegman commented 7 years ago

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).