Extending IIIF 3.0

Extending IIIF 3.0
2018 IIIF Conference, Washington DC
David Newbury, J. Paul Getty Trust
@workergnome
Extending IIIF 3.0 — David Newbury (@workergnome) 1

Triple-eye-eff.
The IIIF Presentation API is a data model
for arranging virtual canvases, annotating them
and providing descriptive content.

Triple-eye-eff.
I'm not going to talk about images.
I'm not going talk about arranging them.
Instead, I'm going to talk about metadata.

The Paintings, Puppies, & Pustules problem
What metadata standard handles meaning across these things?

We punted.
IIIF is presentational,
not semantic.
How it looks,
not what it means.

Properties for People
Words, generally.
Lots of words.

Properties for Software
Data that needs to be
interpreted by client so!ware.

Properties for Robots
Explaining to robots
what this all means.
(Yes, this is semantic. Shhhhh.)

What comes
out of the box?

Presentation Properties for People
label
A human readable label for the resource.

summary
A short textual summary of the resource.

requiredStatement
Text that MUST be displayed.

metadata
An list of label and value entries.

Presentation Properties for Software
navDate
A date that the client can use for navigation purposes.

rights
A URL for a rights statement for the resource's content.

homepage
A link to a web page that describes the "Real World Object".

thumbnail
An content resource that represents this resource.

logo
A small image that represents an individual or organization.

posterCanvas
A Canvas-based summary of the resource.

That's all you get for embedded properties.

That's all you get for embedded properties.
You were hoping for more, weren't you.

Links & Linked Data
External resources & data.

Links for People
rendering
A non-IIIF representation
of the resource for humans--
though it might need special so!ware to view!
PDFs, OBJ ﬁles, ePub ﬁles

Links for People
{
"rendering": [{
"id": "https://example.org/1.pdf",
"type": "Text",
"format": "application/pdf",
"label": { "en": [ "PDF Rendering of Book" ] }
}]
}

Links for People
"label": Description for people.
"format": Description for so!ware.

Links for Robots
"seeAlso"
Related, external datasets.
TEI ﬁles, RDF data, XML ﬁles

Links for Robots
{
"seeAlso": [{
"id": "https://example.org/library/catalog/book1.xml",
"type": "Dataset",
"format": "text/xml",
"profile": "https://example.org/profiles/bibliographic"
}]
}

Links for Robots
"profile":
How your community's robots
recognize this data as relevant.
(your community has robots, right?)

Links for Software
"service"
External APIs that so!ware can interact with
for new functionality or information.
The Image API is common,
but there are others.

Links for Software
{
"service": [{
"id": "https://example.org/service",
"type": "Service",
"profile": "https://example.org/docs/service"
}]
}

Links for Robots
You need to know what the service does to use it.
Documentation should be available at the profile URL.

You want more?
(Never satisﬁed, are you?)

Annotations
Linking between resources via a motivation.
IIIF deﬁnes the painting & supplementing motivations,
the Web Annotation spec deﬁnes others.
(clients need to recognize them, though...)

Annotations
Annotations are the way to
provide custom content for people.
They're not very good at providing
content for so!ware, though.

Still not satisﬁed?
You really want custom, semantic,
machine-readable properties.
Even though IIIF doesn't do that.

Do what thou wilt.

Custom JSON properties.
Other properties are allowed...if a client discovers properties
that it does not understand, then it must ignore them.
IIIF lets you add new properties.

{
"@context": [
"http://www.w3.org/ns/anno.jsonld",
"http://iiif.io/api/presentation/3/context.json"
],
"id": "https://example.org/iiif/custom_props",
"type": "Manifest",
"lastModified": "2017-12-25"
...
}

Custom JSON properties.
If it’s only your manifests,
used by only your so!ware,
and nobody else ever uses it...
Then maybe it’s ok.
That's not very IIIF-y, though.

Problems with Custom JSON:
— I can't tell that you've used them.
— I can't guess what they mean.
— I might have used the same property.
— IIIF might use the same property.

The heart wants what it wants.

Fine. You win.
IIIF Extensions.

IIIF Extension best practices:
— Don't reuse existing property names
— Indicate you're using a custom property
— Use as few properties as possible
— Explain what they mean
— Share them with the community

JSON-LD Contexts
No one would accidentally reuse
{
"http://iiif.davidnewbury.com/lastModified": "2017-12-25"
}
But, man—
is it ugly.

JSON-LD Contexts
If I host a context.json ﬁle...
{
"@context": {
"@version": 1.1,
"lastModified": "http://iiif.davidnewbury.com/lastModified"
}
}

JSON-LD Contexts
...and include it into my manifest...
{
"@context": [
"http://iiif.davidnewbury.com/context.json",
],
"id": "https://example.org/iiif/book1/manifest",
"lastModified": "2017-12-25",
"type": "Manifest",
}

JSON-LD Contexts
...I can use the pretty name.
{
"@context": [
"http://iiif.davidnewbury.com/context.json",
],
"lastModified": "2017-12-25",
"type": "Manifest",
}

JSON-LD Contexts
JSON-LD Contexts do three things:
1. Map property names to URIs
2. Let so!ware know to look for new properties
3. Tell you who created the properties

Um...this didn't solve the problem of reusing properties.

JSON-LD Scoped Contexts
There are only so many good names.
A IIIF extension should only claim one property,
but many extensions need more than one.

JSON-LD Scoped Contexts
In JSON-LD 1.1, there's a way to deﬁne a context
that only applies within a particular property:
Scoped Contexts.

{
"@context": {
"@version": 1.1,
"lastModified": "http://iiif.davidnewbury.com/lastModified"
}}
can be used like
{
"@context": [
"http://iiif.davidnewbury.com/context.json"
],
"type": "Manifest",
"lastModified": "2017-12-25"
}

{
"@context": {
"@version": 1.1,
"navPlace": {
"@id" : "http://iiif.davidnewbury.com#navPlace",
"@context": {
"lat": "http://iiif.davidnewbury.com#lat",
"lng": "http://iiif.davidnewbury.com#lng"
}
}
}
}

{
"@context": [
"http://iiif.davidnewbury.com/context2.json"
],
"type": "Manifest",
"navPlace": {
"lat": 34.045,
"lng": -118.565
}
}

Documentation properties
— type
— profile
— label

This STILL didn't solve the problem of reusing properties.

The IIIF
Registries

Extending IIIF 3.0

Recommended

Recommended

More Related Content

Similar to Extending IIIF 3.0

Similar to Extending IIIF 3.0 (20)

More from David Newbury

More from David Newbury (20)

Recently uploaded

Recently uploaded (20)

Extending IIIF 3.0