IIIF and Linked Data

[Stefano Cossu]

Hello,
This is a longtime train of thoughts that came into better focus to me
after yesterday's (excellent) community meeting about IIIF and Wikimedia.

IIIF seems to have been increasingly crossing its path with Linked
(Open) Data as it becomes more invested in the discovery and aggregation
of media resources on the Web rather than just their delivery.
Yesterday's Wikidata discussion was an excellent example of this
potential synergy.

I am curious to know from whomever has an opinion on this, whether and
how the IIIF community would explicitly express an affinity with Linked
Data, and whom this could benefit.

On the technical side, this could for example translate into adding
support more RDF serialization formats than only JSON-LD in the
Presentation API specs and related examples.

At a community level, I am thinking about drawing attention from other
communities involved with LOD-related projects, which seem to involve
similar actors (scholars, researchers, scientists, humanists...) and to
have very similar goals (i.e. making the Web machine-readable and
human-accessible). One simple way to do this could be mentioning this
parallel with LOD explicitly in the IIIF website or other formal
channels where relevant. Also, LOD communities could be actively sought
out to address issues that IIIF discovery may raise. I suspect this
latter case would develop naturally.

This is still a bundle of not-well-defined thoughts but I hoped it would
be useful to share. Opinions are appreciated!

Stefano


--
Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

[Simeon Warner]

Hi Stefano,

IIIF is linked (mostly open) data at its core. The current approach to
in the IIIF specifications is summarized in a number of the design
patterns. The most succinct summary is:

http://iiif.io/api/annex/notes/design_patterns/#design-for-json-ld-first

> The intent of adopting this pattern is to ensure that the
> representation of the Linked Data is as easy to use as possible
> without the need for a full RDF development suite. Developers must be
> able to treat the representation as plain JSON, with a predictable
> structure. This ease of understanding increases the likelihood of
> wide spread adoption.

In my opinion it would be a mistake for IIIF to move further in the
direction of the RDF stack and multiple serializations because that
would make the adoption of IIIF data much harder. Current IIIF clients
(certainly UV and Mirador) rely upon the (plain) JSON format of
manifests etc. -- they do not use an RDF stack and would be complicated
by doing so.

This is, of course, a balancing act but I think we are in about the
right place. All IIIF data (except the images, video, etc.) is RDF and
can be leveraged by the LOD community. I think the use of Web
Annotations is particularly important and provides great promise for
close connection with other work.

Within the library linked data community there is connection and
awareness of IIIF. For example, Mike Appleby, Tom Crane, Glen Robson and
I gave an IIIF workshop "Practical Linked Data Annotations on IIIF Image
Resources" at SWIB17 [1], and at SWIB16 I gave a tutorial explicitly
highlighting the linked data nature of IIIF [2].

I think the set of demos on Wednesday was wonderful and I hope there
will be fruitful additional connections with the wikimedia/wikidata
community.

Cheers,
Simeon

[1] https://swib.org/swib17/programme.html
[2] https://github.com/zimeon/iiif-ld-demo

[Stefano Cossu]

Simeon, thanks for the information link. I suspected that a good deal of
thought was put into this topic, so it may be just a matter of surfacing
this information more explicitly. Sessions like the one you mention are
also a great way to communicate this.

As for JSON-LD,

>> The intent of adopting this pattern is to ensure that the
>> representation of the Linked Data is as easy to use as possible
>> without the need for a full RDF development suite. Developers must be
>> able to treat the representation as plain JSON, with a predictable
>> structure. This ease of understanding increases the likelihood of
>> wide spread adoption.
>

This makes a lot of sense, and I would not advocate for changing it.
However, since JSON-LD is not the most common exchange format among
RDF-based applications (some frameworks don't even support it), adding
more "traditional" options such as Turtle or N-Triples could increase
interoperability.

I was thinking about this enhancement in the same terms as different
image formats are allowed *optionally* in the Image API specs. The goal
would be to add more options, not more restrictions. Most of the RDF
serialization libraries support multiple formats, so adding support for
the other most common ones might even come at a near-zero cost.

Best,
Stefano

[Nuno Freire]

Hi Stefano, Simeon,

Some time ago, I've faced the same questions as Stefano. IIIF and linked data are the core of my research (I'm from computer science)

Eventually, I realized that there is nothing non-linked data in IIIF. I work with IIIF responses completely based on RDF tools, actually. 

I use a JSON-LD to RDF triples parser.

IIIF output is all JSON-LD and the main resources within the IIF output have dereferenceable URIs. 

Cheers,

Nuno

[Christopher Johnson]

Hi list,

I would like to chime in here and point out that there is a significant component of the Presentation API that is not linked data per se, and that is sc:metadataLabels container.  

Rather than representing a data value with {s, p, o}, this is simplified to {(k,v)} where the range of k & v are strings.   While this works fine for display use cases, it is somewhat problematic for any aggregated cross-domain discovery or structured indexing.

I am currently working on this problem and believe that one solution is to use a dataLayer (via Google Tag Manager) where an interface mutation maps the arbitrary labels to a standard vocabulary (i.e. schema.org) and pushes a structured metadata JSON-LD object to the window.   The mutation just depends on a "universal" json object that provides the translation of all known domain labels to schema.org terms/objects.  

This allows the client to present both the human and machine readable metadata simultaneously in the same context.  The seeAlso property linking to a separate document is the conventional alternative, but this introduces a lot of complexity for a client (e.g. domain specific deserializers) who would attempt to make use of it.  Furthermore, to what is the seeAlso document back referencing, the manifest or (perhaps undefined) presentation object URI?  

Providing a clear distinction between a collection URI, a manifest URI or a presentation object URI as a "registered" contentUrl is a fuzzy area for discovery.  The persistent entity is probably the latter (if it is defined) and since Google does not index ordinary JSON documents AFAIK, it makes sense to embed the structured data there as is done currently by some domain implementations with meta tags, RDFa, or as suggested here, a window dataLayer.

Christopher Johnson

Scientific Associate

Universitätsbibliothek Leipzig

[Stefano Cossu]

Nuno, it's encouraging to know that there is such closely related work
with LD and IIIF.

Christopher, thanks for bringing the sc:metadataLabels issue up and for
offering a solution. I can see that this is mentioned in the IIIF
presentation ontology [1]:

> An rdf:List of label/value pairs providing descriptive metadata about
the resource, intended for human audience

Is that what you are referring to?

Speaking of which, I was pleasantly surprised to find out about these
IIIF ontologies [1] [2], and it would be great to document these somehow
in the main website. This is pretty much in line with what I was
suggesting earlier: it seems like the content is all there and it just
needs to be exposed.

Best,
Stefano


[1] https://iiif.io/api/presentation/2/ontology.xml
[2] https://iiif.io/api/image/2/ontology.xml

On 08/20/2018 05:10 AM, Christopher Johnson wrote:
> Hi list,
>
> I would like to chime in here and point out that there is a significant

> component of the Presentation API that is _not_ linked data /per se/,

> --
> -- You received this message because you are subscribed to the
> IIIF-Discuss Google group. To post to this group, send email to
> iiif-d...@googlegroups.com. To unsubscribe from this group, send
> email to iiif-discuss...@googlegroups.com. For more options,
> visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "IIIF Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to iiif-discuss...@googlegroups.com
> <mailto:iiif-discuss...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.