This seems to still be thinking about design as a point in time, not acking deeply the inevitable change, and the unforeseeable / independently varying changes.

Glad to see the ack in changes in external factors. Hoping that climate change will be mentioned, but I'm not optimistic. (Annotating as I read . . .)

Highlighting the high variability, but it seems like this contradicts the confidence of earlier statements about design ability.

"can" but do they, and "to withstand them" at what point in time

Any way they can actually understand all the forces, really? This sounds like a stereotypical engineering claim.

It would be good to make the guidelines a bulleted list

Only the first two make sense to me, balancing the impulse to Do Something against the knowledge that humans are fallible and accidents will always* happen.

The remote monitoring idea might make sense, but this wasn't a case where the ship wasn't attended or the pilot/captain was drunk. Autonomous nav, though, are they serious? The electrical system blew. What power would the autonomous nav be running on? Why would something of this size and power take up a technology that currently has a 5x-13x greater crash rate in cars than cars not using autonomous navigation?

???

Raises a question about big maintenance issues: In a system such as this one, is it something to consider that we shouldn't(?) permit scaling up one component without identifying which other components are at risk of failure and improving them as well? I'm not saying they didn't run this scenario in Baltimore, but the philosophical x economic shift would be a big deal. What options are there for e.g. a shipbuilder if they knew they couldn't build bigger ships without also contributing to bridge upgrades?

Crux. (Also, the writer doesn't sufficiently distinguish between the ship's bridge and the Key Bridge when referring to the latter generically.)

Why?

Why was the fuel pressure insufficient?

Just a little bit more here would be nice

Italics

Yale: Same for a Publication?

{person's name}

We will be using Metadata Browse, so some(?) will be linked

IMO, order should be: Browse (Explore?) People Browse Places Advanced Search News About

Fundamentally, the content space is just an HTML block (or multiple), yes?

Reverse chronology, like a blog.

Yale ppl: Do we want any suggestions pre-populated? Omeka: Can this page be brought up with the map pre-loaded to a particular place?

Ignorant Q: Is this literally all the structure of the page, or are you assuming we will add any other sections we want?

"Browse People"

somewhat like thumbnail scrubbing on the timeline

Note that no-nav doesn't mean the content is hidden or removed. YOu can use the start property to skip it in the default view.

recipe 9

Copy date and place to collection, show collection manifest, make sure to link from collectin, make sure Michael's custom viewer doesn't break

by adding

to

also adding

Should the link target be https://www.w3.org/TR/annotation-model/#classes? That seems more pertinent to me.

"close-up" (and anywhere else "close up" appears as a noun)

"property" (and elsewhere that "attribute" is used for a IIIF property)

Tagging. However,

fragment, as

Canvas id

make this into code formatting

"use" (to avoid repetition)

the correct place.

a chapter entry

As another possibility, you

For one example, in

conference, where the

be

TextualBody

When

When

AnnotationPage. To

If you go with something from Fixtures as part of adding a Service to the Manifests, this might need to get adjusted.

lowercase T

format as code

Add Annona. Though the UX is not great, it does support the principle of Collections, pulling in full Manifests from stub entries in the Collection's Manifest

Collection

Collections; however OR Collections. However

fully

"together in a unified and coherent IIIF Presentation interface."

"already has a digital representation and a Manifest,"

dele, to help readers go from realia to digital collection

Remove

=> March

"the viewer and any customizations or extensions"

Either "to group" or "to permit grouping"

"Clients have the option"

Is there a way to make connections with similar groups for technologists of color &c.?

Some cautious parallels to make with gender and disability where race is not part of the identity mix

Small wonder that white women are the primary beneficiaries of affirmative action.

A good point -- how can applications be open and welcoming to people whose names have changed? Is there a model or the start of one in the attitudes toward women who have professional experience under more than one name, where the name changes are unrelated to gender-based change?

Authors thought there was no need for this. The CC PD is for the metadata, you've got a credit/reference, and the copyright statement at the object page is Public Domain

Canvas

The Use Case seems like a good place to link out to the Presentation API 3.0 for the explanation of "content resource", but I think it should be the last sentence, which would allow you to remove this parenthetical.

Same as preceding. I lean toward "Annotations", but I won't die for that flag.

I think this should be "Annotations" to refer to the IIIF concept, but it's hard to be certain.

If I think about it, I understand why "acquisition" is here, but I think it's a distraction. I advise removing it and having "to one of a multi-spectral set of images."

"a painting detail that is only visible" (rewording in part to make clear why it takes 'that' over 'which')

"It might seem like" (cookbook does not frequently use the editorial "we" outside of the Example text)

Split into two sentences. I think I would write it this way:

We want to tag only a portion of the image and thus the motivation of the Annotation must be tagging. The body of the annotation must be a TextualBody — with a format of text/plain — that contains the text of our annotation.

"image, thus"

"must be a TextualBody"

My dictionary has either "X-ray" or "x-ray"

To go with the comment about editorial "we" and also with my comment about recipe titles over numbers:

"could be applied to images that are part of a composition, as in the recipe, 'Composition from Multiple Images'."

Better to use recipe titles, since the numbers at this point are just arbitrary associations with GitHub issue numbers: "like 'Simple Annotation — Tagging' or 'Simplest Annotation'"

Move to "Example" section

I would read this better if it were the last property in the item

specifies

The way this recipe will address that is by leveraging a IIIF image's Image Service to cover a Canvas with just the region of interest.

Remove viewers, add note about not working.

dele

2080

2080

Add UV

2080 (and in 29)

Match to cropped dimensions

Ensure structure is kept t/o recipe, see Glen's writing at https://glenrobson.github.io/iiif_stuff/meme_challenge/

Add text along the lines of "Compare this to . . ." Maybe move into

"that" (this is an American English v British English issue, I believe)

"that" (this is an American English v British English issue, I believe)

"service, which"

Redundant with first sentence of this section?

"one of many possible"

"Related Recipes", since it's an articulated section

Add note that you can have a service-less image, with the direct link to the fragment. You lose tiled zooming.

"to see an example of a non-painting annotation" or smth like that

Conform text to new use case with newspaper

Brief explanation of difference between painting annotations and non-painting

Consider whether relevant or distracting. If kept in, elaborate what kind of annotation, why this distinction matters.

Discuss contrast with annotation, difference between targeting a region and pulling in only a region

structure, to refer to a manifest property?

bound together some time after publication [printing? creation?] I don't know that it really matters for the use case per se, but it might be easier for people with modest experience with this kind of object to understand.

Sammelband, where (adding comma)

Proposed in cookbook authors' call for Maps group discussion: Mapping Canvases in a Manifest

"platform that provides the ability to [x, y, z]." Where x, y, and z are functionalities core to the distinctiveness of this recipe.

Serial comma

Original text: "This property may attach . . . "

Elixir [and elsewhere]

doesn't always

that

no hyphen

Unless I'm ignorant of something (which happens all the time), this is the British English spelling, and we are generally using US English spellings.

Awkwardly long. Maybe:

This configuration is not ideal in most cases as it offers the client no size choice. Further, if the sizes provided are too small to meet the client’s thumbnail requirements, this will have significant impact on processing time. When a client must resize thumbnails, it is more efficient to downsize an image than to request the perfect size.

"height, and width"

Capitalize

". . . Captions, and . . . "

" . . . Captions, and . . ."

I like the addition of "or their families". We are enmeshed.

Should this be in an annotations property of the Canvas, Manifest, or AnnotationPage?

"selected implementation examples with explanations and sample manifests"

"going. You can also"

"additions to the cookbook! To get"

"cookbook Slack" capitalization

channel, and propose a recipe.

"process, say"

Link to https://iiif.io/api/cookbook/recipe/ instead, I think

add " and" after semicolon

"that all clients will start"

"image"

Only need one closing double quotation mark.

"each"

dele

Written elsewhere as "timed text format". Should be consistent.

"the rendering property" "the linking property rendering"

"is"

Need type per spec?

No "@"

As an implementation note, I think we are wanting to push a little harder for our preferred case, but certainly without excluding or shaming ppl who have their reasons for doing it a different way.

Implementation Note: Using Thumbnails

Aim to drop by Editor time

Use this rather than identify

Add note about UV display adjusted for TZ

remove

"Use a midpoint for any unknown portion. For instance, if only the year is known, use a date in the middle of the year, and if the datetime is known down to a day, use noon for the time."

en-dash (et seq.)

Manifest

"nesting one items property array within another items property array"

where "property" may be sacrificed for readability, I think

Group them how / where? I'm reading this as "to present the volumes together in a IIIF viewer" or similar, with an implication later in the sentence of changing "while maintaining . . . " to something like "while allowing the user to browse each volume separately [as well]".

Serial comma, so "label, or description"

Should be https

Add to implentation notes above: "If the exact time is not known, then “00:00:00” should be used. Similarly, the month or day should be 01 if not known."

And change here to 00:00:00

"lack of viewer support for date-aware navigation for single manifests"

consumption only by

Put bit about defaulting to zeroes here.

change to "resources"

en-dash

en-dash

The seeAlso

MODS

"XML, JSON,"

"that a client will display to the end user" More active phrasing.

"the entire resource"

' "language code/array of values" pair '? Noting because to me this reads currently as "language code + language array" because of spacing.

"included as a single-string array " [only missing article "a"]

Broader reading level perhaps to say "title variants".

"other than just a Point" Not going to die about this one.

change to "implications for"

for clients to

contain these

are

dele

For which you have

I'm inclined to say "a creator field" rather than assert that the field itself is defined by the English label value.

"descriptive metadata field labels"?

dele

"with the Manifest"?

Need to use the baseURL Jekyll property?

values (or whatever way stays consistent with labels previously.

requiredStatement

"no assigned language"?

"image of the painting commonly known as . . ."

label

Legume pun FTW.