Re: JSON-LD serialization and linked data support

Annotations are embedded in IIIF descriptions, which are in turn Linked
Data via JSON-LD:

They can be managed by linked data or json based systems, or just flat
files on disk.    CATCH is one end point that we use in the Mirador IIIF
client, and the expectation is that both will upgrade to the output of this
working group (both Protocol and Model/Vocab/Serialization) as soon as it

We've been discussing search of annotations:

JSON-LD lets us integrate with the Activity Streams work in the Social Web
WG.  It would work with the CSV on the Web WG.  (Note that both use @id and
@type in their JSON-LD). We need it for LDP.  _Google_ uses JSON-LD (with
@id and @type) and describes it as "JSON-LD is an easy-to-use JSON-based
linked data format" at:

If Google think that it's ready and easy for developers ...


On Wed, Aug 12, 2015 at 3:15 PM, Frederick Hirsch <> wrote:

> On today's call the topic of serializations came up and a question seemed
> to be raised over whether JSON-LD should be used (perhaps I heard
> incorrectly)
> There are some strong reasons to continue to require JSON-LD as a
> mandatory serialization, the abstract argument being the value of linked
> data on the back end.
> A specific concrete example of the value of linked data in combination
> with annotations might be "CATCH: Common Annotation, Tagging, and Citation
> at Harvard"
> [[
> It is designed to interoperate with third-party annotation tools to
> aggregate and associate contextualized annotation metadata from various
> pedagogical and research tools with reference to persistent digital media
> in repositories, such as the Harvard Library DRS. - See more at:
> ]]
> Do we have other concrete examples of how the linked data aspect of the
> Open Annotation model adds value to annotations? Pointers would be welcome.
> I'm concerned about specifying multiple serializations as we have to be
> more careful of interoperability in this case, specifically is
> round-tripping without information loss despite the serialization a
> potential issue? More serializations also mean more testing.
> In a related thought, is directly embedding JSON-LD in HTML (
> ) a
> viable option? What is the status of browser support for this? If it is
> supported (or is in progress) what is the case for HTML serialization as an
> alternative? Would it be more productive to focus on generic support for
> JSON-LD in browsers rather than a specific annotation serialization?
> The fundamental issue I heard us discuss is that even with all our efforts
> to simplify the JSON-LD serialization, there will remain some aspects that
> do not appear 'natural' to JSON developers.  The next question I have is
> whether these aspects can be managed with suitable libraries etc.
> Thanks
> regards, Frederick
> Frederick Hirsch
> @fjhirsch

Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

Received on Wednesday, 12 August 2015 22:34:55 UTC