iiif / website Goto Github PK

It is almost painful to hear people try to say eye-eye-eye-eff or miss an eye and say eye-eye-eff. In the specs we explain in the introductions that IIIF is pronounced triple-eye-eff. I think it would be helpful to add this to other key pages on the website like http://iiif.io/about/ and http://iiif.io/community/

http://iiif.io/community/#participating-institutions

I suspect that's far too drastic, but https://iiif.io/api/search/0.9/ always comes up in Google search and 1.0 doesn't when I look for "iiif search".

Any gentler form of nudging search engines to 1.0?

From IIIF/api#887:

How about the following structure:

• /about/presentations/
  • introduction
    • overview
    • usecases
  • api
    • image
    • presentation
    • search
    • auth
  • software
    • client
    • server
  • content
    • manuscripts
    • newspapers
    • museums
  • model
    • linked-data
    • shared-canvas
    • open-annotation
  • related

Do community groups get a space here, or do they have more fine grained control of their own community/groups/ space, and can put presentations there as desired? How would one find presentations on newspapers in IIIF, for example? I've put them here for now but that could be just a symlink or it could be a more finely curated set.

• For people publishing both Presentation 2 and 3 manifests
• For client developers

Examples of how people are doing it, pros and cons of various approaches

Client strategies, publishing strategies

To close IIIF/api#1108

See the Slack discussion in that issue ^^

This is an issue for the website, not for the validator directly. The ability to POST a manifest to the service should be documented at http://iiif.io/api/presentation/validator/service along with how to use it via GET.

Shouldn't all the issues from iiif.io be here, to be pruned down to just the website ones?

In PNG, JPG and SVG.

Replace logo on: http://iiif.io/event/2018/edinburgh/

It should be possible to see the major functionality of different implementations at a glance on the site, and for implementers to submit implementations to it.

From: IIIF/api#976

See old PR IIIF/api#1178 with change to use https for Google fonts (we forgot to move it over earlier).

@mejackreed: it seems that as a website using external resources loaded in a user's browser (iiif.io), using the HTTPS protocol version of that resource is a responsible future proof choice.

@zimeon: 👍 Will be required for #11. I don't see a reason to delay going ahead with this but will wait for another opinion

I just wanted to ask whether it might be please possible to get our new Digital Library Cloud Services software listed on iiif.io under ‘Apps and Demos’?

If you read the home page of this dedicated microsite it should give you a quick overview: https://dlcs.info. The case studies may also be of interest.

Please let me know what you think.

Best Regards,

John

John Baker
Managing Director at Digirati

I think these should all be easily findable from http://iiif.io/community/consortium/

It has come up in discussion of the TRC proposal that community members do not know quite what CoCo is (description buried in MOU) and certainly not who the current member are. We should be more transparent and make the function and membership of these groups easy to find and understand.

This page should also include the Technical Coordinator: http://iiif.io/community/consortium/#staff

This is still the case, https://iiif.io/ does not work. Current best practice is to make all websites natively https, with http open just to redirect. (Was IIIF/api#417)

With the formation of the TRC the TSG formation process has been updated in the following pull request to reflect the bare minimum of changes required to keep the two documents in sync:

#139

and is available at:

https://preview.iiif.io/root/tsg_process/community/groups/framework/#technical-specification-group-formation-and-approval

This gives an opportunity to review the formation process to see if it could be improved. Here are my suggestions:

Order of formation:

1. Community raise need and ideally but not mandatory to contact Technical coordinator to facilitate the next steps
2. Document outline scope, deliverables timescale
   2a. Coco and TRC encouraged to participate in the document creation process
3. Document sent out to the community to gauge interest and commitment of resources
4. If sufficient interest is gathered document is submitted to TRC
5. If the TRC approves the group they will assign two members of the group to support the group to ensure any specifications are consistent with other specifications. (Should one be chair?)
6. Final review from the Coordinating Committee

Changes to and proposed standards from the TSGs will be approved by the TRC before publication.

Inactivity
If the group fails to meet regularly and work does not progress the MD will discuss with the Chairs and the TRC representatives whether the group should continue or dissolve. A motion to dissolve will be approved by Coco and TRC.

This proposal would replace the requirement to have two editors and replace this with two TRC representatives allowing a wider and more diverse pool to assist in the work of TSGs. Note the TRC representatives should not be IIIF Staff and maybe not other TSG chairs to avoid conflicts of interest so would come from Editors, IIIF-C members and from the 5 community slots.

The proposed TRC process relies upon active engagement of participants and a notion of participation-based good standing in order to be able to vote. We need a transparent and lightweight process for tracking participation and good standing status in order to implement this.

e.g. from https://travis-ci.org/IIIF/api/builds/308051148

- ./_site/api/image/2.0/index.html
  *  External link https://profiles.stanford.edu/stuart-snydman failed: 500 No error
rake aborted!
HTML-Proofer found 1 failure!

Shouldn't prevent us from deploying.

Or a master PR: https://travis-ci.org/IIIF/api/builds/308053764

Hello, I'm sorry if this is the wrong place to make this request, but I'm not finding obvious contact information anywhere on iiif.io.

I'd like to get RAIS listed on the "apps and demos" page. It's been IIIF-compliant for a few years, and I've had a heck of a time figuring out who to contact to get it added.

RAIS is a high-performance IIIF Image server written in Go. It supports level 2 of IIIF Image 2.1 as well as some optional features like max image size. It has direct integration with openjpeg, making its JP2 decoding extremely fast (I posted some siege results to the IIIF group mailing list). It also has ImageMagick bindings for fast decoding of non-JP2 sources. It can optionally cache tiles to memory using a very intelligent cache (2Q LRU). And with the latest release, plugins are supported for operations like pulling from S3 on demand and adding arbitrary middleware (these features are both included as example plugins).

I don't know if RAIS needs to be tested by others to get listed, but installation is fairly straightforward. Docker is the easiest approach, but the manual instructions can be inferred from the Dockerfile. It boils down to:

1. Install Go
2. Install development packages (Make, gcc, git, etc.)
3. Install openjpeg development packages and ImageMagick development packages
4. Clone RAIS from github
5. Type "make"
6. Fire it up! e.g., ./bin/rais-server --iiif-url=http://localhost/iiif --tile-path=/var/local/images

issue copied from IIIF/api#890, originally raised by @kshawkin

There are a few things included http://showcase.iiif.io/ that are not also listed at http://iiif.io/apps-demos/ , but I'd suggest including all at http://iiif.io/apps-demos/ so that there's a single complete list. That way http://showcase.iiif.io/ would truly be a "showcase" for the best cases.

https://github.com/estebangarcia2018/publishing-scientific-images-iiif-spanish

Proposal for TRC suggests that TRC should have a role in the approval of new TSGs. The current TSG formation process has CoCo approval and community review. TRC could provide a review as part of this but should TRC have binding/veto power?

template: https://docs.google.com/document/d/1UtgKqs_Uy8shm6ErhMaecu1HeCS3wDpeEGD79Z88byg/edit?usp=sharing

The current proposal has TRC Ex Officio members and Consortium members representing IIIF-C Full members making the selection members from IIIF-C associate members and the community "with a view to maximising the diversity of representation amongst those who have previously engaged with the specification process." Do we need any addition requirement to avoid favoritism or popularity bias?

On this page the "Stanford University Libraries - Mirador demo" seems to be broken:
http://iiif.io/apps-demos/

The BL demo in that list also appears to be old and at last partially broken. And the other examples here could probably be better to show the current state of Mirador.

IIIF should update the page, incorporating new and more reliable content from the awesome-iiif list.

In randomly testing a Yale manifest, I have observed that http://www.shared-canvas.org/ns/context.json is defunct.

A non-dereferenceble IRI @context breaks JSON-LD processors. This would seem to be a limitation with JSON-LD serializations that depend on IRI @context.

IRI @context documents should continue to be highly available or a suitable deprecation should be issued so that users can make the appropriate modifications.

@kshawkin: At http://iiif.io/technical-details/ , under "step 2", you might change "presentation based metadata" to "structural metadata". I think that would be clearer.

@zimeon: I agree that "presentation based metadata" isn't good, it doesn't even really make sense. However, "structural metadata" seems too restrictive: we have technical metadata, structural metadata, and additional metadata for presentation such as labels, rights information, etc..

@kshawkin: Hmm, I see. How about "rendering metadata"?

From: IIIF/api#889

IIIF/api#1107

From @mikeapp: "A #jobs channel has been created in Slack, it would be helpful to have some mention of it on the community page."

At IIIF AV meeting -

A machine-readable/computable notion of compliance is too difficult and puts too much burden on publishers. (IIIF/api#76)

But a community-maintained page/section of the site in the style of https://caniuse.com/ would be very useful.

Naming the features will be hard, and require lots of community participation.

Originally raised by @srabun - copied from IIIF/api#1101

editorial process doc
A/V charter
any A/V or Discovery related materials

See comment for list of instances - IIIF/api#1101 (comment)

For the purpose of determining where IIIF conferences and working meetings will be held, in addition to alternating between Europe and North American for each as is current practice, what policy or process should be used to determine event locations if more than one institution/location wants to host?

intranda GmbH is the main developer of the open source software Goobi workflow and Goobi viewer. The Goobi viewer implements the IIIF image and the IIIF presentation APIs.

It would be great if the name intranda GmbH and the website https://goobi.io could be added to the participating institutions section of the community page of the website.

In the W3C JSON-LD WG, we have found a GH Project to be useful in managing the workflow across multiple repos without going out to external similar kanban boards like waffle or trello.

I propose a similar pattern for managing the TRC workflow. The chairs and editors can keep the on-deck issues up to date and ordered, and then move them to other columns such as accepted / rejected / sent-back-for-further-work once consensus in the TRC is arrived at.

As part of IIIF/api#1637 there should be:

• /community/editors/ -- editorial committee membership and role
• /community/policy/editorial/ -- editorial committee process
  and then we remove the existing https://iiif.io/api/annex/notes/editors/ and fix links in /api/

The question is: how do we do it once the translations have been reviewed?

Links to IIIF/api#824

maybe also automatically Tweet?

iiif.io/community/consortium/#the-iiif-consortium

Not the highest priority, but would be good to see if there's a way to show a 404 page more helpful than the following; nothing real heavy-weight, maybe just a template saying, check the URL you were trying to get to?

404 Not Found

    Code: NoSuchKey
    Message: The specified key does not exist.
    Key: event/2019/goettinge
    RequestId: 391D9FA2310F7AD5
    HostId: J2a22ZsgK8FqYP5kgAdb/BS2FGl8Vy9YeuXBPjaCe20vtT7T5On7IySSnL28WPPBEymJ/Grespk=

in https://iiif.io/event/2019/goettingen/wednesday/

for one of the presentations

From: IIIF/api#1002

@srabun You might consider making this an 'include'. See, e.g., at the end of this section. The line {% include copyright.md %} corresponds to the file source/_includes/copyright.md, which gets copied in when the site is built. It keeps you from having to maintain the info in multiple places. You could make something like call_info.md and do similar.

Would be nice for the website to have a brief and accessible Explainer video to introduce newcomers to IIIF, with emphasis on the value it adds for research, instruction and digital access to cultural materials. These aren't particularly cheap to produce well, but would be effective and impactful, I think.