search

dauwhe / epub31-bff

Straw-man spec for browser-friendly format for EPUB31
14 stars 3 forks source link

Metadata in the model. vs RDF/JSON-LD #26

Open iherman opened 8 years ago

iherman commented 8 years ago

Transferring from issue #13 comment as a separate issue.

@HadrienGardeur wrote:

We need to be more crisp than that. Is it possible to say that the metadata part of the model is the set of RDF metadata terms that are relevant for the publication (or a rendition)?

It's actually a set of RDF metadata terms that are relevant for the current collection. At a top-level metadata will be about publication, while inside renditions it'll be about the rendition it's part of.

If we say that, does that also means that, in the JSON representation of the model, that part of the information SHOULD (or MUST) be considered as a JSON-LD section, with all possibly syntactical consequences thereof? Or do we intend to consider the whole thing as one big JSON-LD (I would be a bit concerned about this)?

I previously proposed the use of a JSON-LD fragment but after discussions with you and others, dropped the idea and focused on creating a context that works for the whole document instead: https://gist.github.com/HadrienGardeur/03ab96f5770b0512233a That said, it doesn't cover all of the keys defined in the manifest, just a subset of them.

if we have a JSON-LD 'fragment', this means we have to have a special processing model/procedure to extract that part and hand it over to a bona fide JSON-LD processor

Agree, that's part of the reason why I would rather avoid this.

if the whole thing is JSON-LD, then we may have to pay a price in terms of additional complexity in term of syntax (e.g., the usage of @graph)

That's why I would like to have additional restrictions and not allow full JSON-LD.

iherman commented 8 years ago

@HadrienGardeur wrote:

if the whole thing is JSON-LD, then we may have to pay a price in terms of additional complexity in term of syntax (e.g., the usage of @graph)

That's why I would like to have additional restrictions and not allow full JSON-LD.

The problem is that there are things that we cannot restrict easily. What I am worried about, in this case is as follows: JSON-LD works well if the RDF is, sort of, roughly tree-like, ie, there is one common subject on the top. However, if there are several subjects on the top level then the usage of @graph becomes unavoidable, which is ugly.

I guess we can leave this issue pending until the model is finalized and we can see where it goes if we serialize it in proper JSON-LD. I just wanted to flag this issue for us to be careful...

HadrienGardeur commented 8 years ago

What do you have in mind when you mention that the top level might have multiple subjects in our case?

Things like authors/publishers/collections/series? I've tried to address those in the current context example that I've created so far: https://gist.github.com/HadrienGardeur/03ab96f5770b0512233a#file-metadata-complex-json

iherman commented 8 years ago

I did not have any concrete examples in mind, it is more of a general concern that may backfire. Your example is fine. But if, for some reason, we wanted to have several metadata blocks in the JSON-LD, with different id-s each (I am not sure we really want that, though, also I do not know how the, say, ISBN identifiers work with different renditions) then things may go wrong. I have been burned by JSON-LD on that issue in the past, hence my caution...