Presence of id should be a SHOULD?
#112
Comments
|
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 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 Cc @BigBlueHat |
|
Another case for having some recommended properties is probably |
|
This issue was discussed in a meeting.
View the transcriptPresence of id should be a SHOULD? #112Matt 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 |
|
@mattgarrish I did not check whether it is already in the PR version of the document. If so, you should close this issue... |
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.
The text was updated successfully, but these errors were encountered: