8.5 Embedded Metadata

[marcoscaceres]

An archiving service needs a reliable way to determine which, if any, PWP components contain structured descriptive metadata. Without such a mechanism, the archiving service will have to develop and maintain publisher- and/or platform-specific heuristics for locating or parsing out descriptive metadata, making archiving more expensive and decreasing the reliability of reporting.

Shrug. Cost of doing business.

Can this please be reformulated as an end-user requirement. Otherwise, please remove it.

[iherman]

I must admit that... I am not sure and that may be, nay, it is a more general discussion topic (maybe deserves a separate issue?).

When we are talking about use cases, I am not sure that only the use cases relevant directly_ to the simple reader are the only valid ones. I think it is perfectly valid to cite use cases that are relevant for the various infrastructural services that surround publishing as a whole area of discourse. Of course, at the end of the day, those services are there for the lambda users, but it is a bit convoluted (and unnecessary) to say something like "it is the end user's (or society's?) interest that the publication becomes properly archived, and therefore the author/publisher should be able to add structured descriptive metadata".

I believe that use cases that require certain features to ensure that infrastructural services like libraries, online bookshops, services like Google scholar, resellers, etc, work and develop properly are just as valid as use cases that are simply readers like you and me.

I agree that the end users' point of view should dominate. But I do not agree that that should be the only valid use case category; the archival service is probably a good example.

[lrosenthol]

Agree with @iherman completely.

Use cases apply to the entire ecosystem for publications - from authoring (which we don't talk too much about yet) to production, to publishing, to processing, to archiving. And everything in between.

On Wed, Sep 28, 2016 at 10:42 AM, Ivan Herman notifications@github.com wrote:

I must admit that... I am not sure and that may be, nay, it is a more general discussion topic (maybe deserves a separate issue?).

When we are talking about use cases, I am not sure that only the use cases relevant directly_ to the simple reader are the only valid ones. I think it is perfectly valid to cite use cases that are relevant for the various infrastructural services that surround publishing as a whole area of discourse. Of course, at the end of the day, those services are there for the lambda users, but it is a bit convoluted (and unnecessary) to say something like "it is the end user's (or society's?) interest that the publication becomes properly archived, and therefore the author/publisher should be able to add structured descriptive metadata".

I believe that use cases that require certain features to ensure that infrastructural services like libraries, online bookshops, services like Google scholar, resellers, etc, work and develop properly are just as valid as use cases that are simply readers like you and me.

I agree that the end users' point of view should dominate. But I do not agree that that should be the only valid use case category; the archival service is probably a good example.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/dpub-pwp-ucr/issues/132#issuecomment-250120755, or mute the thread https://github.com/notifications/unsubscribe-auth/AE1vNU9wr63P7VYsiaLoeX6Fk9BzbZU8ks5qujaCgaJpZM4KIYOj .

[dauwhe]

Are there perhaps several requirements here?

1. Metadata should be in some standard format.
2. It should be possible to distinguish publication metadata from component metadata.

Google, among others, seems to be relatively successful at finding metadata in web pages. I don't expect it would be hard for an archiving ingestion system to parse the components and find any schema.org or other metadata within the files. But I'd want to avoid having to put duplicate publication metadata in every component, or to confuse a component title with the publication title, etc.

@marcoscaceres wrote:

Shrug. Cost of doing business.

I think this is an area where the web could learn something from the publishing community. Librarians and others have been organizing and preserving the world's information for thousands of years. The web hasn't done such a good job on the "preserving" part. Being explicit about the importance of this in a requirements document makes sense to me.

[lrosenthol]

This has undergone major cleanup in the latest draft and I believe @marcoscaceres will be OK with it. I also aligned it with the other metadata sections.