Linking between Canvases?

[Robert Sanderson]

A question arose today about how to link from one canvas to another, with the intended functionality being that you click on the link and it opens the referenced canvas in the display.  The use case was linking from a manuscript image to a digitized book page that describes the page or text.

So the requirements seem to be:

* A reference to the linked canvas's URI  (the page)

* A reference to a Manifest (the book) that contains the canvas

* Text for the link

* Label for the field, if it's to be part of metadata?

Thoughts?

Rob

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Drew Winget]

I think this should be the body of an annotation. That would make it possible to refer to specific regions on the canvas in the link. I remember seeing similar references made by Yale's "search by pixels" functionality. It would be useful to click a link in an annotation or metadata field and have the exact object, image, and region invoked (in context!) by the viewer.

To implement something like this, the viewer will need some indication that the link ought to be handled this way. Otherwise the browser will take over and try to open up the json (not very helpful). There are many special link types (called URI Schemes I believe) whose structure implies they should be opened with particular software (e.g.: "irc:", "mailto:", "magnet:...", etc.), or otherwise treated differently. Would this be overkill?

--
-- 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.
For more options, visit https://groups.google.com/d/optout.

[Tom Crane]

Would it be an annotation with a IIIF-specific motivation, that viewers could recognise and deal with appropriately?

[Tom Crane]

I have a related question too - given a resource (e.g., a physical manuscript, or a catalogue record for a digitised manuscript) how would I assert that it has a IIIF presentation API manifest? This would be something that you would want to assert specifically, rather than using a more general predicate for an alternative representation.

The vocabulary sc:hasManifests is available but that doesn't seem the right usage in this case, as that's really for describing collections in aggregate. 

e.g.,

<http://wellcomelibrary.org/catalogue/12345678> iiif:hasManifest <http://www.example.org/iiif/book1/manifest>

[Robert Sanderson]

Sounds like a great approach! Good thinking guys :)

There could be a special motivation, or it could be just oa:linking, and the behavior inferred from the type of the target?

For example:

{

  "@id": "http://example.org/annotations/1",

  "@type": "oa:Annotation",

  "motivation": "oa:linking",

  "label": "Link Text Here",

  "resource":  {

    "@id": "http://example.org/book1/canvas/1.json#xywh=10,10,100,100",

    "@type": "sc:Canvas"

  },

  "on": {

    "@id": "http://example.org/book2/canvas/5.json",

    "@type": "sc:Canvas"

  }

}

It does require the addition of a label to the annotation, but that's trivial as we have it everywhere else already.

It becomes a little more verbose to add the manifest, but certainly still possible without creating new predicates:

{

  "@id": "http://example.org/annotations/1",

  "@type": "oa:Annotation",

  "motivation": "oa:linking",

  "label": "Link Text Here",

  "resource":  {

    "@id": "http://example.org/book1/canvas/1.json#xywh=10,10,100,100",

    "@type": "sc:Canvas"

  },

  "on": {

    "@type": "oa:SpecificResource",

    "full": {

      "@id": "http://example.org/book2/canvas/5.json",

      "@type": "sc:Canvas"

    },

    "oa:hasScope": "http://example.org/book2/manifest.json"

  }

}

Thoughts?

Rob

On Thu, Jan 8, 2015 at 12:34 AM, Tom Crane <tom....@digirati.co.uk> wrote:

Would it be an annotation with a IIIF-specific motivation, that viewers could recognise and deal with appropriately?

--

-- 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.
For more options, visit https://groups.google.com/d/optout.

[Robert Sanderson]

Good question! We haven't considered external links to IIIF presentation API resources before.

Would it be fair to use the IANA link relation "describedBy" ?  That would give us several options both in the metadata proper:

  <http://wellcomelibrary.org/catalogue/12345678> iana:describedBy <http://www.example.org/iiif/book1/manifest>

In the HTML view of the object:

  <link rel="describedBy" href="http://www.example.org/iiif/book1/manifest" type="application/json" />

And in the HTTP headers for images (or other binary content):

  Link:  <http://www.example.org/iiif/book1/manifest>;rel="describedBy";type="application/json"

Thoughts?

Rob

--
-- 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.
For more options, visit https://groups.google.com/d/optout.

[Jon Stroop]

The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.[1]

Is it rel=describedby or just rel=alternate?

In the latter case described by Tom, where http://wellcomelibrary.org/catalogue/12345678 is a catalog record, isn't that a description of a thing as well (and the Manifest is just an alternate version)?

-Js

1. http://www.w3.org/TR/powder-dr/#appD

[Robert Sanderson]

I assumed that the URI identified the object rather than the record, but yes, if it is the *record* it would be rel="alternate" instead.  Good catch!

R

[Tom Crane]

iana:describedBy would be fine, although it doesn't tell you directly that the object is a manifest. A manifest-specific predicate may be a great aid in discovery if widespread use was adopted.

Consider this scenario:

I can use WorldCat's data for a particular work (e.g., http://experiment.worldcat.org/entity/work/data/2983431) to find particular editions of this work (via schema.org/workExample) and libraries that hold a physical copy of the editions.

Wouldn't it be great if there was this additional data:

<http://worldcat.org/entity/work/id/2983431> iiif:hasManifest 

    <http://library1.org/iiif/book8778/manifest> , <http://library2.org/iiif/book97654/manifest> , <http://manifests-r-us.com/iiif/book01/manifest> .

Aggregators like OCLC could link to all known manifests for a work; library catalogues could assert in their bibliographic data that a manifest exists. Crawlers could spot this. If an institution provides a SPARQL endpoint then:

SELECT ?work ?manifest
WHERE {
    ?work iiif:hasManifest ?manifest .
}

I've now got a list of all the institution's manifests!

[Robert Sanderson]

Hi Tom,

I know it's a [dark] art rather than a science, but my preference would be to use common predicates and be explicit about typing, rather than inferring it from a specialized relationship.  So to say that the resource is a manifest, you'd add an rdf:type statement:

<worldcat:2983431> iana:describedBy <lib1:manifest> .

<lib1:manifest> a sc:Manifest .

And the corresponding additional clause in the SPARQL:

SELECT ?work ?manifest

WHERE {

    ?work iana:describedBy ?manifest . 

    ?manifest a sc:Manifest .

}

It makes the RDF longer, but gives more options for linking (eg HTTP and HTML links). Is there a way to add class information to <link> as well as format in the type attribute?

Rob

--

-- 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.
For more options, visit https://groups.google.com/d/optout.

[Tom Crane]

Ah yes, that's much better. Might have to add some RDFa to make the HTML work?

[Tom Crane]

To avoid ambiguity over whether the resource is the work or the catalogue entry for the work, here's one where the resource is definitely the work:

http://experiment.worldcat.org/entity/work/data/4992946

This page could have some additional HTML:

American & other drinks : upwards of two hundred of the most approved recipes for making the principal beverages used in the United States and elsewhere

Digitised versions

• View at Wellcome Library | IIIF Manifest at Wellcome Library
• some other library's version
• some other library's version
• some other library's version

<div resource="http://worldcat.org/entity/work/id/4992946">
    <h1 property="dc:title">American & other drinks : upwards of two hundred of the most approved recipes for making the principal beverages used in the United


States and elsewhere</h1>
    <!-- other info -->
    <h2>Digitised versions</h2>
    <ul>
        <li><a href="http://wellcomelibrary.org/player/b2039715x">View at Wellcome Library</a>
               | <a property="iana:describedBy"
                    resource="http://wellcomelibrary.org/package/b2039715x"
                    href="http://wellcomelibrary.org/package/b2039715x"
                    typeof="sc:manifest">IIIF Manifest at Wellcome Library</a>
        </li>
        <li>some other library's version</li>
        <li>some other library's version</li>
        <li>some other library's version</li>
    </ul>
</div>

This looks a bit odd to me but according to http://www.easyrdf.org/converter it yields the triples below. You'll have to pretend that http://wellcomelibrary.org/package/b2039715x is a manifest for now. The work itself is real: http://wellcomelibrary.org/player/b2039715x

@prefix dc: <http://purl.org/dc/terms/> .
@prefix ns0: <iana:> .

<http://worldcat.org/entity/work/id/4992946>
  dc:title "American & other drinks : upwards of two hundred of the most approved recipes for making the principal beverages used in the United States and elsewhere" ;
  ns0:describedBy <http://wellcomelibrary.org/package/b2039715x> .

<http://wellcomelibrary.org/package/b2039715x> a <sc:manifest> .

[Tom Crane]

The work mentioned above is now available as a real manifest rather than a pseudo-manifest:

http://wellcomelibrary.org/iiif/b2039715x/manifest

(experimental endpoint - please don't hit too hard!)

http://bltesters.azurewebsites.net/?manifest=http://wellcomelibrary.org/iiif/b2039715x/manifest

or load into Mirador...