Presence of id should be a SHOULD?

[iherman]

At the moment, the canonical identifier is defined, but it is left to the author to set it or not. I wonder whether we should not say that the manifest SHOULD (although not MUST!) set this value.

[iherman]

One problem I ran into is when the manifest is handled as a bona fide RDF graph (which it is). I know most User Agents will not do that, but by virtue of using JSON-LD we make this possible. The way to do that is to use a JSON-LD processor to create a set of statements stored in a triple store, and then extract information from there.

This works, except for one point. If the id value is set we do have a node in the graph that can be used as some sort of 'root' to unfold the available triples from the data store. However, if we do not have this, the 'root' is one of possibly many blank nodes, and there seems to be no way of identify the node that corresponds to the publication as a whole, which makes the handling of the data via RDF pretty complicated, if at all possible.

This just shows that having a bona fide Web identifier (ie, the id) is a fairly important thing for Web Technologies...

Realizing that if everything happens off the Web and in JSON only, this issue is not relevant, an id is certainly not a MUST.

Cc @BigBlueHat

[mattgarrish]

Another case for having some recommended properties is probably type. Not strictly necessary, but should be set for schema.org processing.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: id and type are RECOMMENDED properties

View the transcript

Presence of id should be a SHOULD? #112
Matt Garrish: #112
Matt Garrish: next issue… 112, raised by ivan… when we took out web publications, we also reduced our recommended property list… a few requirement remain, everything else became optional
… should we continue to recommend the presence of id and type? they are not strictly necessary… do you agree, disagree?
Dave Cramer: some concerns about increasing authoring burden in order to satisfy requirements of RFD processing…
… “i make the webpage, don’t have to come up with an id”
Matt Garrish: yes, and certainly why they’re not required… alternatively, we could put it into best practices
… explain why it’s useful to have them
Benjamin Young: this is also where we put canonical identifiers using JSON-LD, even if you process just as JSON, you’d want to have an id there… if I put a bunch of stuff in a bag, I want to have an identifier for that… it should be important for publishers to name your stuff
Ivan Herman: two things—on type, schema.org processors are dependent on the type of the JSON contents as a whole…
… when I use the testing tool they offer, the absence results in a bunch of errors…
… regarding id, I agree with dauwhe that it should not be required… the question is whether we should make it very difficult to use… the way I tested it, i ran the manifest through a JSON-LD processor which produced RDF triples… to see what really happens…
… that’s when I realized that there is nothing that identified the resource as a whole thing
Benjamin Young: related to what ivan said… schema.org with its type injection…. would seem to keep it in the recommended space
… the other thing that drives considerations of id is that, it is usually embedded in HTML pages, and processors will give the identifier of the document you got it from
… this would also happen with publication manifest inside a web page
… so ids in audiobook land may be another question… but it becomes a processing bungle, but it won’t catalog metadata correctly without id… as a machine, i won’t know i’ve seen it before…
Matt Garrish: there’s precedent in EPUB for unique identifier for a publication… i don’t think this would add any burden either way
… it’s complexity versus having a minimally viable manifest for what we’re expecting to be done with them… that’s the case for having them recommended
… should we put this to a vote?
Mateus Teixeira: anyone who can’t live with it?
Proposed resolution: id and type are RECOMMENDED properties (Ivan Herman)
Matt Garrish: +1
Geoff Jukes: +1
Ivan Herman: +1
Mateus Teixeira: +1
Benjamin Young: +1
Bill Kasdorf: +1
Ric Wright: +1
David Stroup: +1
Ben Schroeter: +1
Resolution #3: id and type are RECOMMENDED properties
Matt Garrish: we’ll make them RECOMMENDED properties, then

[iherman]

@mattgarrish I did not check whether it is already in the PR version of the document. If so, you should close this issue...