Wikipedia and IIIF

[Glen Robson]

Hi All,

I wanted to pass on some exciting developments regarding IIIF and Wikipedia integration.

WikiData IIIF Manifest property

Thanks to Christopher Johnson who proposed the IIIF Manifest property and this was accepted on Tuesday and is now live on WikiData. This allows you to link an item on WikiData to a IIIF manifest. For example see the following from the National Gallery of Art which is an image you might recognise from Mirador:

https://www.wikidata.org/wiki/Q9162658 

By linking WikiData items to manifests it allows the rich data on Wikidata to be queried to generate lists of Manifests that could be integrated into new IIIF tools. A couple of example queries are below:

List of all manifests in WikiData: http://tinyurl.com/yd4sjc5a 

Count of manifests in WikiData by institution: http://tinyurl.com/yc2fg8qc 

List of manifests which depict people: http://tinyurl.com/ycsuuogf 

For discussion on how to upload these manifests links to WikiData please see the discussion on the #wikipedia channel in the IIIF slack (you can use http://bit.ly/iiif-slack to join slack).

WikiMedia WishList Suggestions

Thanks to Andy Mabbett for bring this to our attention and to everyone else that has contributed to the ideas. After some discussion we decided to submit two ideas, one to suggest supporting the IIIF Presentation API and one to support the IIIF image API both for WikiCommons. Full details can be seen at:

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_IIIF_Presentation_API_in_WikiCommons

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_the_IIIF_Image_API_on_Wikimedia_Commons

These ideas are currently going through the Wiki Community Tech Review and community voting opens on Friday. If you support the above ideas please consider registering your support when voting opens. 

Thanks

Glen Robson

IIIF Technical Coordinator
International Image Interoperability Framework (IIIF) Consortium
http://iiif.io

[James Heald]

Question: should the new Wikidata property have a "formatter URL"
attached to it, so that a human being clicking on the link would be
taken to a preview of the manifest in a viewer, rather than the bare
JSON of the manifest?

eg setting the property's formatter URL to
http://universalviewer.io/uv.html?manifest=$1
would present the manifest in Universal Viewer.

What would be the best viewer with a web presence to give as a default
manifest previewer (Mirador?)

And would the viewer allow the URL of the manifest to be given as part
of its own URL (in the way that UV does above?)

-- James.

On 14/11/2018 11:17, Glen Robson wrote:
> Hi All,
>
> I wanted to pass on some exciting developments regarding IIIF and Wikipedia integration.
>
> WikiData IIIF Manifest property
> Thanks to Christopher Johnson who proposed the IIIF Manifest property and this was accepted on Tuesday and is now live on WikiData. This allows you to link an item on WikiData to a IIIF manifest. For example see the following from the National Gallery of Art which is an image you might recognise from Mirador:
>

> https://www.wikidata.org/wiki/Q9162658 <https://www.wikidata.org/wiki/Q9162658>

>
> By linking WikiData items to manifests it allows the rich data on Wikidata to be queried to generate lists of Manifests that could be integrated into new IIIF tools. A couple of example queries are below:
>

> List of all manifests in WikiData: http://tinyurl.com/yd4sjc5a <http://tinyurl.com/yd4sjc5a>
> Count of manifests in WikiData by institution: http://tinyurl.com/yc2fg8qc <http://tinyurl.com/yc2fg8qc>
> List of manifests which depict people: http://tinyurl.com/ycsuuogf <http://tinyurl.com/ycsuuogf>
>
> For discussion on how to upload these manifests links to WikiData please see the discussion on the #wikipedia channel in the IIIF slack (you can use http://bit.ly/iiif-slack <http://bit.ly/iiif-slack> to join slack).

>
> WikiMedia WishList Suggestions
> Thanks to Andy Mabbett for bring this to our attention and to everyone else that has contributed to the ideas. After some discussion we decided to submit two ideas, one to suggest supporting the IIIF Presentation API and one to support the IIIF image API both for WikiCommons. Full details can be seen at:
>

> https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_IIIF_Presentation_API_in_WikiCommons <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_IIIF_Presentation_API_in_WikiCommons>
>
> https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_the_IIIF_Image_API_on_Wikimedia_Commons <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Multimedia_and_Commons/Support_for_the_IIIF_Image_API_on_Wikimedia_Commons>

>
> These ideas are currently going through the Wiki Community Tech Review and community voting opens on Friday. If you support the above ideas please consider registering your support when voting opens.
>
> Thanks
>
> Glen Robson
> IIIF Technical Coordinator
> International Image Interoperability Framework (IIIF) Consortium
> http://iiif.io
>
>
>

---
This email has been checked for viruses by AVG.
https://www.avg.com

[Tom Crane]

Hi James,

Much as I would like all Wikidata IIIF manifest references to go to the UV, I'm not sure that would be the best thing to do in this case. But I'm "not sure", rather than in strong disagreement.

Pros: 

Something to look at, more user friendly than a screen full of JSON

Cons: 

Favours one viewer over others (although https://github.com/ProjectMirador/mirador/issues/1556). 

The anointed viewer may not support some of the features in the manifest.

Doesn't encourage the idea that a IIIF representation is a model for generating user experience, without mandating what that user experience is like.

In the past IIIF has suffered I think from first impression conflation of viewer (usually Mirador or UV) with standard. This formatter could make that problem worse. IIIF isn't one particular user experience; it's the raw material for constructing UX.

As I said, not sure rather than violently disagree, interested to hear what others think.

Tom

[Shaun Ellis]

Tom, I fully understand your trepidation, but I would be in support of Wikidata manifest references going to the UV because:

1. The UV currently supports the most variation among manifests and versions than other viewers
2. The UV currently works in more browsers than other viewers
3. The main goal of the UV is to support the basic/general use cases over the specialized
4. This initiative is less about the promotion of IIIF and more about end user access to content

Kind regards,

Shaun Ellis

UX Web Developer 

Princeton University Library

--
-- 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]

Hi Shaun,

I absolutely agree with you if this was, say, a link from a Wikipedia infobox (should that ever come to pass).

But (James can correct me if I'm wrong) we're talking about a formatter in the Wikidata result set, e.g., on http://tinyurl.com/ycsuuogf

Often I want the bare manifest URI so that I can go and do something with it (e.g., load it into something else). I don't know whether the presence of a viewer rather than the presentation data at the other end of that URI in the Wikidata results is going to help or hinder the likely users of that rendered result set.

I don't know the answer!

Tom

[James Heald]

So just to clarify:

The "Formatter URL" property doesn't change what comes out of a SPARQL
query -- eg here's an analogue of Tom's query for works with an Art UK
identifier tinyurl.com/ybw7777k

As you can see, all you get out from the Art UK query is the bare
identifier -- in the IIIF case it would be the basic manifest URL.

But where the URL formatter comes in is on the Wikidata page for the
item. (eg: https://www.wikidata.org/wiki/Q369582 )
Here the Art UK identifier is still presented as a string (right down in
the external identifiers section of the data page), that can be
copy/pasted; but it now has link to the URL of the relevant page for the
artwork at Art UK, so the string is now dressed as a blue-link.

In the case of an IIIF manifest, the original URL would be shown as the
text, but the URL-formatter would cause the link to point to its
representation in the anointed viewer.

The Art UK identifier isn't currently shown in the infobox of a category
on Wikimedia Commons (slightly more open-minded than English Wikipedia
to inclusion of material from Wikidata), eg:

https://commons.wikimedia.org/wiki/Category:Madonna_with_Child_and_Angels_by_Masaccio
but that is only because nobody has asked for it to be added yet.

If that template did include the Art UK identifier (or the IIIF manifest
URL), then the link-formatter property would be used to link it, as eg
the VIAF identifier is linked in the "Authority Control" section of the
infobox at
https://commons.wikimedia.org/wiki/Category:National_Gallery,_London
(WikiCommons category infoboxes are 100% drawn from Wikidata).


So: the URL-formatter property wouldn't affect query results; but it
would change the target of links on the Wikidata item page, and (most?)
templates that would present that information in wiki projects.

Hope that clarifies rather than further confuses,

-- James.

[Andrew Hankinson]

As a IIIF manifest publisher, and as a user of the web, I would expect a link-like thing to point to the content of the link (the manifest) and not be re-directed transparently to a third-party site that I have no control over.

As Tom mentioned, if Wikipedia wants to use the IIIF Manifest to display UV for their articles, that's great. But I don't think it's intended for the Wikidata interface to be a "User Interface" in the traditional sense. It's more a minimal UI over a big graph database than an end-user UI.

-Andrew

[KITAMOTO Asanobu]

Dear All,

I would like to suggest that iiif.io, or other groups, maintain a kind
of "resolver service" for IIIF viewers. In Wikipedia, a similar service
is used for the location information, called GeoHack.

https://tools.wmflabs.org/geohack/geohack.php?pagename=Berlin&params=52_31_N_13_23_E_type:city(3292365)_region:DE

If we had a similar service for IIIF, the site would maintain the list
of IIIF viewers with a proper link to show the manifest.

Moreover, this service can be used not only from Wikidata, but also from
other services as a general-purpose resolver.

Finally, I also agree that the formatter could be applied to Wikidata
infobox, but should not be applied to raw Wikidata data.

Asanobu KITAMOTO
Center for Open Data in the Humanities
http://codh.rois.ac.jp/

[David Beaudet]

Indeed, a resolver service that would prepare a series of links to IIIF viewers compatible with the particular manifest seems like a reasonable approach as it lets the user decide how to visualize the resource and a link to the raw json could be provided there as well. If the output could be alternatively presented as a menu within the Wikipedia page itself rather than a standalone page, that might be cleaner.

[James Heald]

A quick update on this:

As well as property P1630 ("formatter URL"), Wikidata also has another
property P3303 ("Third-party formatter URL").

The difference is that P3303 doesn't get used to add links to values on
Wikidata pages; but it is a way of recording that third-party
presentation services are available, and some software (including some
infoboxes) may link to use those services.

So for property P6108 ("IIIF manifest"),
https://www.wikidata.org/wiki/Property:P6108 , third-party formatter
URLs (P3303 values) have now been added for the Universal Viewer, for
Mirador services from the Smithsonian and the Getty, and for a Mirador
service hosted on Wikimedia's own user cluster.

The latter has been designated the "preferred" value of the P3303
statement (based on the argument that by providing a WMF hosted service,
people can click through to the viewer without their identity and
viewing being shared with anybody other than WMF. Tinfoil perhaps, but
there we go).

The first program to use this link is the Reasonator viewer for Wikidata
content, so eg clicking the IIIF manifest value from the Reasonator page
for the Alba Madonna (Q254923),
https://tools.wmflabs.org/reasonator/?q=Q254923&lang=en
now takes the reader to the presentation of the manifest in the WMF-Labs
installation of Mirador:
https://tools.wmflabs.org/mirador/?manifest=https%3A%2F%2Fwww.nga.gov%2Fapi%2Fv1%2Fiiif%2Fpresentation%2Fmanifest.json%3FcultObj%3Aid%3D26

This has been set up by a couple of Wikimedia volunteers, Users
Multichill and JeanFred, as discussed in ticket
https://phabricator.wikimedia.org/T209697

This probably represents the status quo that will be going forward for
this, at least in the immediate future.

Best regards,

James.

PS With a big batch now in for the National Gallery of Art, over 10,000
manifests now linked from Wikidata -- just in the first two days!
https://twitter.com/sanseveria/status/1063340252566306817

On 15/11/2018 11:59, 'David Beaudet' via IIIF Discuss wrote:
> Indeed, a resolver service that would prepare a series of links to IIIF viewers compatible with the particular manifest seems like a reasonable approach as it lets the user decide how to visualize the resource and a link to the raw json could be provided there as well. If the output could be alternatively presented as a menu within the Wikipedia page itself rather than a standalone page, that might be cleaner.
>