Additional resources

[iherman]

This PR implements

• some decisions in Toronto, not yet in the document (cover and privacy policy as structural items)
• adding the extra resources to the document, in case this gets accepted as proposed in yet another 'resource list' in the manifest? #225
• adding cover, privacy policy, accessibility report, and external metadata to the manifest definition using various rel values.

If and when approved, this completes the manifest definition

---

Fix #225
Fix #216

---

Preview | Diff

[HadrienGardeur]

Let's vote on this addition + the term that we should use during the call today.

[TzviyaSiegman]

Should we dictate the means of providing text descriptions for the covers? Is that best practice? I would like to double check that practice. If we allow for more than one cover image, we should provide more information.
regarding new IANA defintions- Did we agree to define a new media-type? if we do that we also have to get UAs to recognize it. I don't think this is the easiest path forward for cover or accessibility report. Perhaps we should explore https://schema.org/Role.

[llemeurfr]

I wonder why we should type extra resources with @type" : "PublicationLink".

And again, not convinced that the cover should be allowed as an extra resource (out of the boundaries of the publication) if it exists. I agree that it may be either in the reading order or in the f resource set.

[iherman]

@TzviyaSiegman

Regarding new IANA defintions- Did we agree to define a new media-type? if we do that we also have to get UAs to recognize it. I don't think this is the easiest path forward for cover or accessibility report.

We do not need a separate media type for a cover, in my view, I guess the rel value should suffice in recognizing what the 'role' is for that thing.

Perhaps we should explore https://schema.org/Role.

Do you mean using Role as a replacement for our PublicationLink? That would mean using the properties defined in https://schema.org/Role, but I am not sure it is good enough. However, LinkRole (https://pending.schema.org/LinkRole) may do it (except that it is currently 'pending'). Looking at the current specification of PublicationLink, the properties url, name, description are the same; the rel would be linkRelationship (per definition it is the same as what we want). What is missing, however, is the usage of fileFormat (which is actually strange)....

(What happens if we do not use media types?)

[iherman]

@llemeurfr

I wonder why we should type extra resources with @type" : "PublicationLink".

Well... in the Google checking tool it seems that at least the google implementation shouts at you if you do not provide an explicit type for all objects. That is why I have put it into all examples...

...not convinced that the cover should be allowed as an extra resource (out of the boundaries of the publication) if it exists.

I am flexible on that one (the PR is definitely not final, depends on these discussions.)

[TzviyaSiegman]

@iherman LinkRole (https://pending.schema.org/LinkRole) instead of PublicationLink looks like it's worth exploring. We should find out if it's pending because it is incomplete of just waiting for the next push.

[HadrienGardeur]

What is missing, however, is the usage of fileFormat (which is actually strange)....

(What happens if we do not use media types?)

I recently discovered that fileFormat is superceded by encodingFormat: https://schema.org/encodingFormat

I'll quote that page:

Media type typically expressed using a MIME format (see IANA site and MDN reference) e.g. application/zip for a SoftwareApplication binary, audio/mpeg for .mp3 etc.).
...
Unregistered or niche encoding and file formats can be indicated instead via the most appropriate URL, e.g. defining Web page or a Wikipedia/Wikidata entry.

Once again, I'm really not a big fan of the schema.org naming conventions.

[HadrienGardeur]

Well... in the Google checking tool it seems that at least the google implementation shouts at you if you do not provide an explicit type for all objects. That is why I have put it into all examples...

This can be handled in our context document, we don't need to include a type for each element listed in readingOrder, resources or links.

[iherman]

@HadrienGardeur

What is missing, however, is the usage of fileFormat (which is actually strange)....

(What happens if we do not use media types?)

I recently discovered that fileFormat is superceded by encodingFormat: https://schema.org/encodingFormat

Yep, I discovered it today. But it says that it is a property on CreativeWork. If this was RDF domain, that would have consequences, I am not sure what it means in schema.org land if I use it on a type that is not supposed to hold it...

[iherman]

To answer my own question above: the Google tool does complain if fileFormat is used on a different type than CreativeWork...

[iherman]

I propose what we do is to add an editorial note at the definition of our own PublicationList that we explore the usage of LinkRole, but we have to have a discussion with schema.org on the usage of fileFormat (or encodingFormat). Add it to our list to discuss...

[iherman]

Ref: schemaorg/schemaorg#1959

[GarthConboy]

This looks like a good step forward and we should commit and tune from here.

The notion that all these extraResources are beyond the bounds of the publication may want to be a "may be" – might an RS want to find the cover here, even said happens to be used within an HTML file within the default reading order?

[iherman]

@GarthConboy I think there should be normative statement somewhere that the three lists (reading order, resources, and extra resources) should be mutually disjoint. I guess there are some statement in the current PR that could be put in to reinforce this.

Should we open a separate issue on this?