Forums
A few years ago there was this discussion regarding image numbers at FamilySearch https://www.evidenceexplained.com/node/2259
I've just discovered that FamilySearch has changed the visual handling of items inside of an IGN number. Previously, you got the entire IGN in one long sequence of images. The default now is to show the IGN broken up into the items that make up the entire film. You now get just the images in the item. However, there are numerous ways for you to select either just the item or the full IGN. This starts to get very fun with the citations.
I'll start with this image
https://www.familysearch.org/ark:/61903/3:1:3Q9M-CSD4-Q35L?view=explore&cc=3015626&lang=en&groupId=M9XY-DPH
And we note that this is image 3 of 47 in item 15. And it's a much longer URL.
Now if I do the trick of just copying to the ? the resulting page doesn't include the item number and its image 586 of 864. You also cannot convert into item view, it's flat all the time.
If I go to the ARK page for the connection of an individual to that page
https://www.familysearch.org/ark:/61903/1:1:QPJN-GGGL?lang=en
That link will take you to the item listing version which is image 3 of 47 item 15.
If you go in by IGN number, you get the full IGN but with the possibility of switching to items.
The catalog entry
https://www.familysearch.org/en/search/catalog/results?q.filmNumber=102700265
takes you into the film starting in full mode but switching to item number if you want.
There is also a catalog entry
https://www.familysearch.org/en/records/images/search-results?imageGroupNumbers=102700265
This catalog entry shows the IGN by item and you need to know which item you need. In this instance, it's not hard as it's by birth year, but others may not be so easy.
In the previous discussion, it seemed to lean towards using the shortened URL, but I'm betting that we will see more and more default use of the item number with their image number rather than the full IGN image number. I "THINK" we need to start including the item number but that makes the URL much longer and not always in use. Or is this not something to worry about as the ARK continues to get to the image, but if so what image number do I use.
Cryptoref, yes. The…
Cryptoref, yes. The architecture of the FamilySearch site confounds many. URLs for the same image do change according to how we arrived at the image. With the records I use, I most often see this difference when I access an image via one of these two approaches:
And, as you note, the latter also leads us to an intermediate page on which FamilySearch has extracted summary details from the document—creating a derivative (with a different URL) that we ordinarily would not want to cite. At that derivative page, we are then typically redirected to the original (with a different URL).
Most users of the site, arguably, are not software engineers qualified to parse the differences. However, users of the site do not have to do so to meet their needs as genealogical and historical researchers. To meet that need, we fall back on the most basic principle of citation (i.e., record identification):
We cite what we use—in a manner that permits two things
To meet this need, our relocation of online documents typically includes one or both of two things:
Evidence Style allows us to mix and match details of those two as needed to create a clear statement of how the image can be relocated. We may use one, or the other, or both. The simplest generic-rule is to cite the URL and/or path details that appears via the approach we used. EE models both.
Within this framework, why would EE 4's examples of church records imaged on line, using Templates 10 and 11, not work? Say,
I suspect that your technical mind wants more, but you'll have to get the IT explanations from a FamilySearch software engineer. If you do, many users of FamilySearch and EE would be interested in the rationales behind the current situation.
That last paragraph really…
That last paragraph really made me think. What i hate is a citation that has stale or misleading information. Just rubs me the wrong way. The FamilySearch ARC URL works just fine either short or long. You see the page one should see. What may be different is the image x of y. But that is not necessary to get back to the page if the ARK is working Which means that for an ARK URL is the image x of y, unnecessary? Are we adding info harkening back to older days when the URL took us to the first page and then we had to add the image number ourselves?
I'm looking at this now from this type of process
IF URL is ARK and points to exact image
THEN image x of y is not needed
ELSEIF URL is ARK but points to first image
THEN image x of y is mandatory
ELSE if URL is NOT ARK
THEN image x of y is mandatory
One could argue in this case that the Item number becomes more important if FamilySearch changes the viewing again. But note through all of these changes, the promise of ARK is maintained, they take you back to the image which is really what we want. If we follow my thought above, then we only put in image number when you need it. Otherwise, it is something that may become stale and not help the reader of the citation.
And for those pedantic enough to do a code review, yes, it could be done differently but this fits for illustration.
Crypto: For an ARK URL is…
Crypto: For an ARK URL is the image x of y, unnecessary?
EE: Perhaps, but it's also useful redundancy. The very form of URLs, ARKs, PALs, and all their kin—consisting of a string of numbers, letters, and symbols—facilitates typos when copied again and again. Cutting/pasting and formatting/typesetting often result in a lost or added character. Stating the path > image number is a check to make sure that all is well and it's a backup when something goes awry. (This response also applies to your subsequent check-list of mandatory/not-needed situations.)
Crypto: Are we harkening back to older days when the URL took us to the first page and then we had to add the image number ourselves?
EE: Old days? Sometimes that’s still the best way.
Crypto: [If] through all of these changes, the promise of ARK is maintained …
EE: And, in our experience with advancing technology, we have great confidence that “promises” will be “maintained”?
Crypto: [If] the promise of ARK is maintained, they take you back to the image.
EE: Yes, that would be the case, so long as we can abolish typos and other human errors.
Crypto: Otherwise, [an image number] is something that may become stale and not help the reader of the citation.
EE: Arguably, Crypto, any detail in a citation can become “stale” as access and technology changes. That’s why Evidence Style views “useful redundancy” as an aid—a backup, safeguard, and/or workaround.
For those who eventually publish their work, via a journal or book publisher, there is also the need to meet idiosyncratic editorial styles. Some editors detest long URLs because of formatting issues. Some (particularly among academic journals) want only a cryptic URL without any other details at all.
Evidence Style considers the input vs. output issue. When we create our "working citations" (i.e., input stage) it is wise to capture all details that might eventually be necessary, whether those details relate to access or source/evidence analysis. At publication (output) we then trim the citation to absolute essentials dictated by our publishers.
I like the point of input…
I like the point of input versus output stages. In input we want as much as possible to recover if we need to. If the ARK works, then all else is extra, you don't need x of y, don't need IGN, you've got the right page. If ARK garbled, for any reason, then IGN and x of y only help if we come in the right path. That points, to me, that for input use, it would be the ARK, and then for redundancy, the path to the page including IGN, item, and x of y. This gives us what you were calling out, that on the input side it's to help us get back no matter what happens, both garbles, tech changes, or any other issue, we have a way to get back to the image.
For "internal" publication by myself, I'd keep the entire full citation with all redundancies in place. For edited publications, i'd follow the editor's requirements.
What occurs to me now is that we shouldn't be mixing the info we have. Putting x of y on an ARK depends on the type of ARK and may confuse if the underlying tech changes. Quoting the ARK and then putting in a path with IGN, item, and x of y gives you redundancy that helps prevent loss of access to an image.
That means, I think, that the image layer looks like this:
layer 1 record; imaged, FamilySearch (URL [ark]), path [records > location > type ...], IGN xxx, item x, image x of y; layer 3
That to me puts the things together that work together and you should never have items out of alignment.
Agreed. One nit left to…
Agreed. One nit left to pick. You render your model as
layer 1 record; imaged, FamilySearch (URL [ark]), path [records > location > type ...], IGN xxx, item x, image x of y; layer 3
Evidence Style use > > to indicate that we're dealing with an exact path:
layer 1 record; imaged, FamilySearch (URL [ark]), path [records > location > type ...], IGN xxx > item x > image x of y; layer 3 (additional source information provided by the online site)