-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design microdata to annotate link to manifest for clients to follow #557
Comments
This is a great idea! As well as microdata for visible links, is there an official type which could be used for a |
There is a discussion related to this on iiif-discuss, with an RDFa example: <a property="iana:describedBy"
resource="http://wellcomelibrary.org/iiif/b2039715x/manifest"
href="http://wellcomelibrary.org/iiif/b2039715x/manifest"
typeof="sc:manifest">IIIF Manifest</a> At Wellcome we use wdrs:describedBy where @Prefix wdrs: http://www.w3.org/2007/05/powder-s#, which is the same as the iana:describedBy in that discussion. |
If we publish recipes for linking from elsewhere to IIIF we should also provide examples of the inverse - linking from IIIF resources to library catalogue pages, for example, via the "related" term. Linked data question: what's the type or format of a resource that is open to content negotiation? {
"@id": "http://local.wellcomelibrary.org/iiif/b11933859/manifest",
"@type": "sc:Manifest",
"label": "Actors fighting by moonlight. Colour woodcut by Kunikazu, early 1860s",
"seeAlso": {
"@id": "http://local.wellcomelibrary.org/resource/b11933859",
"format": "(open to negotiation)" // ??
},
"related": {
"@id": "http://local.wellcomelibrary.org/item/b11933859",
"format": "text/html"
}
} |
In this case, could format be an array? That's not strictly a LD solution, -Js Sent via mobile. Please excuse typos, brevity, etc.
|
Obviously, all of the representations should have a Link header listing all -Js Sent via mobile. Please excuse typos, brevity, etc.
|
An array of the formats I know the resource will accept seems sensible but it feels wrong somehow! I want to say "there's RDF on the other end of this link, but you have options on format". |
@zimeon: Can you write up the drag and drop hack from Philly as a starting point? :) |
Regarding conneg, format could have an array of possible media types available. Or just omit it? Or put the expected to be most common format, and then use regular conneg to discover the media types available? |
The drag and drop hack from Philly is at: http://zimeon.github.io/iiif-dragndrop/, we should think about how this becomes an implementation note or similar at some stage --> #602 My understanding is that for drag and drop we can't use a clean microdata approach because for cross platform support the only thing one can rely on is the URI being copied over. Thus everything has to be stuffed in the URI. (Within particular browsers one can do much more...). The pattern proposed is:
where the query params convey the manifest, canvas or image URIs. |
It looks like Google supports the indexing of custom meta-data and structures. If Mirador could execute a Google search, limiting results specifically to IIIF manifests, that might be a helpful feature that would increase the effectiveness of the Mirador as research / exploration tool use case. This might make it possible for IIIF publishers to interface with Google, rather than IIIF.io, to make their resources findable. https://developers.google.com/custom-search/docs/structured_data?hl=en |
Eds: Move to discovery repo until there's something more to discuss. See IIIF/discovery#20 |
To wrap around links to manifests, iiif logo with a property containing the link, and so forth, to allow clients to search for the microdata in HTML and follow to the Manifest (or Collection).
The text was updated successfully, but these errors were encountered: