As a consumer of drag and drop, I want to have confidence that the dragged icon will appear in my viewer

[mejackreed]

For a user that is dragging an HTTP manifest into a viewer that is hosted in an HTTPS application most likely they will have problems (it will not work).

The designing of a specification is an opportunity to ask the question "should HTTP urls be drag and droppable", especially if they are going to encounter problems in HTTPS hosted viewers.

[azaroth42]

I propose that fixing HTTP/HTTPS on the web is out of scope for IIIF discovery

[beaudet]

Although it is a practical issue for drag & drop so if d&d is to remain in scope, it might have to be addressed?

[azaroth42]

I don't know what that would mean, in practice. There is no possible solution that we can provide to make it work. There's no possible way to get every organization to use HTTPS, and if there's a requirement for authentication, then there is no possible way to just only HTTP.

We can acknowledge that dragging between HTTPS/HTTP hosted systems won't work, and to request that people implement HTTPS.

[mejackreed]

Sure I agree "fixing HTTP/HTTPS on the web" should be out of scope. Let me add to my original comment (after rereading it I agree it may be not that clear).

In designing a story around user experience, I think its important to address potential problems that users will experience. D&D is introducing a new type of user action that is not a common interaction pattern. My hope is that in designing a specification (and action) we can side step some of the pitfalls that users may run into with upfront work or strong recommendations. To establish itself as a new pattern that IIIF users adopt globally, I would hope that we could have some base level of assurance that "it will work". Without that, having to explain "Well you can drag and drop this but not that, and well because HTTPS" has the potential to confuse and discourage IIIF end users.

If a D&D adopter goes through the effort of implementing, wouldn't it be a shame if that content wasn't fully interoperable? Especially if this has the chance to discourage D&D adoption.

Perhaps in the spirit of:

The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones

• https://www.w3.org/2001/tag/doc/web-https

So can D&D then "actively prefer secure communication"?

To @azaroth42's comment:

We can acknowledge that dragging between HTTPS/HTTP hosted systems won't work, and to request that people implement HTTPS.

👍 for sure we should do this at least. My suggestion is to mostly front load any specification or work to this acknowledgment. Clients also could be configured to provide helpful errors when HTTP urls are used.

[zimeon]

I agree with @mejackreed's last point too: the client can check whether it has an HTTP URI dropped onto it that won't work, so the spec could say at least that it SHOULD report a helpful error (or such).

[azaroth42]

Yes, I agree with the rephrasing of the question too! We cannot solve it, and we shouldn't say that ONLY https URLs can be dragged and dropped. Whether or not the event fires at all for a mixed content environment in order to give a helpful error needs to be determined.

[sdellis]

This is another shortcoming of the "drag and drop" approach to import. A better technical solution for import use cases would be implement a UI for the Discovery API in the client/viewer. This way any discovered resources that were not served over HTTPS (or were otherwise incompatible, like unsupported API versions) could easily be filtered/grayed out and could provide a better user experience when trying to import.

[azaroth42]

There is currently no discussion of or intent to produce a query based API that a viewer could implement a UI over top of.

[sdellis]

Why is there no intent to explore a query based Discovery API further if it could solve multiple documented use cases that currently have no proposed solutions? These use cases are mouseless users #90 , interoperability with native mobile apps #94 , and the unreliability of viewer rendering around HTTP/S and unsupported API versions #88.

[azaroth42]

Because every single time any organization has tried to standardize search, it has been either extremely specific to a single data structure or a complete failure. The CH domain's history is littered with failed attempts to do this, and even 800M pound gorilla internet companies haven't succeeded. Consider: Z39.50, Z39.92, LOC/OASIS SRU/SRW, Dienst, OpenSearch, the DPLA search API, the Europeana search API, Google's Search API, SPARQL ...etc.etc.etc.

Secondly, we need to enable the aggregation of IIIF content as easily as possible first before any meaningful query based API could be even built. Which is what we're doing.

[beaudet]

I agree that it seems logical that aggregation would need to come before search is even possible - otherwise what is there to search? However, do the use cases for search not inform the data that should be supplied through aggregation? Or does that not matter? It might be helpful to have a brief 10k (insert dimensional unit here) recap of the strategy that led to Discovery's selection in the IIIF batting order as well as it's scoping.

[azaroth42]

The data model and representation for IIIF is already set with the Image and Presentation APIs.

To quote from the charter:

This group will create specifications that improve the discovery process for IIIF resources, with a focus on leveraging existing techniques and tools, and promoting widespread adoption within the community.

Work that is out of scope for this group includes the selection or creation of any descriptive metadata formats, and the selection or creation of metadata search APIs or protocols. These are out of scope as the diverse domains represented within the IIIF community already have different standards in these spaces, and previous attempts to reconcile these specifications across domains have not been successful.

(Emphasis added)

Which basically says it all -- There's already hundreds of metadata formats, and adding yet another one is futile. As is trying to get museums, libraries, medical imaging and cat gif creators to agree upon any existing metadata standard. IIIF is about enabling access to image content, not about the rich descriptive semantics needed for search of CH objects. The flow looks like:

1. Find IIIF provider [registry of top level collections or similar]
2. Crawl and Harvest provided IIIF resources [Charter section 1]
3. Maybe harvest referenced, domain-specific semantic content [Charter section 2]
4. (Index the data, and provide some UI for searching and rendering result sets, out of scope)
5. Import selected search results into IIIF viewer for rendering to user [Charter section 4]
6. Stay up to date with changing content [Charter section 3]

Trying to standardize how search engines work at step 4 is just a losing proposition. Federated search (aka metasearch, aka distributed search) is never performant enough due to network latency, and the data is never consistent enough to be reliable. And to further clarify, the response syntax is trivial (IIIF Collection) ... it's (a) ensuring that different search implementations process the same query in the same way that is impossible given different databases and different semantic descriptions and (b) having a query language flexible enough to cover all possible domains, and rich enough to allow individual domains to distinguish between similar resources.

[beaudet]

Thanks Rob. I have no issue with search implementations being out of scope. I do however continue to question the utility of aggregating only IIIF resources if that aggregation is forced by the Discovery spec to be independent from harvesting of a collection of objects (some without IIIF resources). I fear if the spec forces this, institutions wanting to leverage a common, aggregator supported harvesting API, will just create dummy IIIF resources as placeholders in order to channel their data to aggregators at the same time - I know I would be tempted to do that. Instead, it would be nice for the spec to acknowledge that IIIF resources are representations of objects and are therefore secondary concepts within an object-oriented hierarchy. While the details of domain specific objects certainly cannot be in scope for the Discovery API, it seems that a simple vector for object conveyance, e.g. a link to a URI that represents an object or sub-collection, etc. would suffice to allow for a more natural representation of all objects in a collection as well as their IIIF representations.

[sdellis]

We need to enable the aggregation of IIIF content as easily as possible first before any meaningful query based API could be even built.

Google can already easily aggregate and index IIIF content. It also already has a query based API (Custom Search), which I believe is quite successful. It can be used to filter results as well as provide custom structured data to clients.

A viewer UI only needs three pieces of data to provide a smooth "import" experience (aka, no errors): the Resource URI, the type of Resource, and the API version. Sitemaps with Pagemaps is one of many options for allowing this data to come through in Custom Search results.

This gives implementers the freedom to decide how to best filter and represent the results data in the contexts of their applications and can also allow for the types of mixed result sets that @beaudet would like to see. We don't have to reinvent search to provide a good experience. We just need to converge on a simple, interoperable approach that covers our use cases.

[mattmcgrattan]

Vatican 2017: remove discovery tags but leave as a documentation issue.