Linking to an external metadata record

[HadrienGardeur]

We have consensus that the manifest should not deal with specialized metadata and rely instead on external metadata records.

What we haven't discussed (yet) is how we actually link to these external metadata records.

It's worth pointing out that this issue is strictly about external metadata records about the publication, and not external metadata records about a specific resource contained in the publication.

[llemeurfr]

IMO, to reference external metadata, the manifest should simple contain a link with a rel equal to "metadata" and a mime-type corresponding to the metadata dialect.

Best practice - Due to its large presence in the ebook publishing industry, ONIX will certainly be the recommended metadata scheme for this industry. I didn't find a specific mime-type representing an ONIX structure; the ONIX creators should certainly define one.

[laudrain]

I have asked EDiTEUR about any existing MIME type for ONIX message.
It will probably be application/onix+xml

[HadrienGardeur]

In EPUB 3.1, we use record, but similar values are marked as deprecated: onix-record, marc21xml-record and mods-record.

I couldn't find a good fit in the IANA link registry.

[GarthConboy]

Moved over from the largely-duplicate issues that we created from a call last week:

The likes of an ONIX feed should be able to be associated with a WP. This logically would mirror the element in EPUB 3 here.

The EPUB 3 vocabulary for properties and relationships is here. May only need the likes of ONIX and XMP, as I don't think "acquire" (from EPUB Previews) and "alternate" have gotten any traction (though not 100% sure of that).

[BigBlueHat]

I couldn't find a good fit in the IANA link registry.

Typically, describedby (or the reverse describes) are used for cases like this:
https://www.w3.org/TR/powder-dr/#appD

It's a generic link relationship (not specific to the POWDER spec where it was made) and is media-type agnostic, so could be used for all these cases.

What we should certainly avoid is creating a rel-per-format as is seen in rels like onix-record etc. You can get to an "understanding" via a combination of the rel and the type.

[HadrienGardeur]

@BigBlueHat yeah I saw that one but I'm always a little confused when the registration is very media-specific (it shouldn't). manifest suffers from the same issue by the way (it shouldn't be tied to the WAM).

[HadrienGardeur]

Our current draft now supports the ability to link to external resources, but we have yet to agree on a proper rel value for a metadata record.

[iherman]

I am afraid that the only one we can refer to is describedby if we stick to the IANA registry. We may try to register something like metadata by IANA, but I am not sure about that.

If we end up using schema.org's https://pending.schema.org/LinkRole, and we then used https://pending.schema.org/linkRelationship, we could have somewhat more freedom:

Its linkRelationship property can indicate URL-based and plain textual link types e.g. those in IANA link registry or others such as 'amphtml'.

which means that we could use the EPUB 3.1 terms after all in that case.

[llemeurfr]

+1 for using rel equal describedBy (plus the proper mime type) and move on.

[iherman]

@llemeurfr do you think this requires some explicit mention in the document? ONIX is now used in an example in https://w3c.github.io/wpub/#wp-extensibility-manifest exactly that way, though with a simple XML media type.

(Edited: the URL was wrong...)

[llemeurfr]

@iherman. Reading this part of the draft spec (on extensibility), I have an observation: the introduction in 4.8.1 is very good IMO. But the next section would be much clearer if split in "4.8.2 "Provision of linked metadata records" and "4.8.3 Inclusion of additional properties" (in sync with the intro, and preferred solution first). We don't need a sub-section "4.8.2.1 Descriptive properties", as metadata records is equivalent to descriptive properties in practice.
And we should then add in 4.8.3 a sample with an inline property added to the manifest, e.g. a Dublin Core property not retained in the infoset (subject?).

Plus we should definitively make the ONIX mime-type more precise, following Luc's recommendation (when ONIX people has given an answer).

[iherman]

@llemeurfr (and @mattgarrish) Thanks. I will try to come up with a PR later today (unless you beat me into it:-)

[mattgarrish]

Funny, this was the question I left off with in my head on Sunday. I'm fine changing the title of the existing subsection, but the reason I put it into a subsection was so that we could add another on general property extension (plus Ivan had mentioned that the restriction on identification only applies to linked records, so before it was too general).

But has there been any discussion about extending the manifest during my recent absence? Are there any desired rules for extending, or can anyone do anything they please and the only thing to be aware of is that there's no guarantee user agents will notice your new additions? Or should we just put in a placeholder note that we need to consider the issue further?

(If you know what you want to say in such a section, Ivan, feel free to cook up a PR... :)

[llemeurfr]

@mattgarrish by "extending the manifest", if you're talking about discussing the content of a "4.8.3 Inclusion of additional properties", I think this means another issue to open :-).

[iherman]

@mattgarrish and @llemeurfr see if #257 satisfy you. We can move the discussion to the PR to make it more specific...