Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional resources #232

Merged
merged 6 commits into from Jun 20, 2018

Conversation

Projects
None yet
5 participants
@iherman
Copy link
Member

commented Jun 18, 2018

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 #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

iherman added some commits Jun 18, 2018

Changes on the infoset section
- moved (per resolutions in Toronto) the cover and the privacy policy to the structural infoset items
- added a new entry for the list of external resources
Added the missing infoset mappings to the manifest:
- list of external resources
- cover
- privacy policy
- accessibility report
- external metadata
@HadrienGardeur

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

@TzviyaSiegman
Copy link
Contributor

left a comment

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

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

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

@iherman

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

@GarthConboy
Copy link
Contributor

left a comment

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

This comment has been minimized.

Copy link
Member Author

commented Jun 20, 2018

@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?

iherman added some commits Jun 20, 2018

Added a note on reorganization, and removed the (erroneous) remark wh…
…ereby cover, a11y report, etc, should only be in the (external) resource list.

@GarthConboy GarthConboy merged commit 8dd6539 into master Jun 20, 2018

1 check passed

ipr PR deemed acceptable.
Details

@iherman iherman deleted the additional-resources branch Jun 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.