Skip to content
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

MEDI ELECTRONIC ambiguities #316

Closed
dthaler opened this issue May 27, 2023 · 6 comments · Fixed by #442
Closed

MEDI ELECTRONIC ambiguities #316

dthaler opened this issue May 27, 2023 · 6 comments · Fixed by #442

Comments

@dthaler
Copy link
Collaborator

dthaler commented May 27, 2023

ELECTRONIC is ambiguous since could apply to an online source or a digital source in personal possession (e.g., floppy disk, DVD, CD-ROM, hard drive, flash drive, etc.)

If you have an audio recording on a CD, is it AUDIO or ELECTRONIC?
If you have a digital photograph, is it PHOTO or ELECTRONIC?

Also, CD-ROM is another ambiguity. The fact that a source is from a CD-ROM is important in Evidence Explained since it explicitly appears in the citation text. See EE pages 283, 378, 392, 509, 711, and 799 as examples.

https://gedcom.io/specifications/FamilySearchGEDCOMv7.html#g7enumset-medi has values for, among other things: ELECTRONIC and OTHER. It is unclear what to use for a CD-ROM, such as a book on CD-ROM (BOOK is defined as only a "bound" book).

OTHER with a PHRASE of CD-ROM is of course usable but may not be reliably parsed by programs due to the various forms it might occur in ("CD", "CDROM", "CD-ROM", etc.)

Option 1 (possible for 7.1): add an enumerated value MEDI CDROM for it, just like ones exist for microfilm, microfiche, etc.
Option 2: add a Note (in 7.0) with an example using PHRASE CD-ROM with MEDI ELECTRONIC.
Option 3: add a Note with an example using PHRASE CD-ROM with MEDI OTHER.

@Norwegian-Sardines
Copy link

Norwegian-Sardines commented May 28, 2023

A digital artifact (the definition used for "Electronic") actually refers to a any item in a digital form, magazine, newspaper, music, photo, Facebook. In Library Science we often refer to things as "Born-Digital".

Yale University says:

Born-digital items are materials that are created in a digital format. This includes websites, email, digital photographs, electronic records, and more. Born-digital items are distinct from analog items that are subsequently digitized, such as paper manuscripts or photographs.

So any item on the list could be digitized (be "electronic") even a "bound book".

I think that we need to find a better term for "Electronic" for media that was "born that way" vs media that was digitized from its original format. Most family historians are looking at websites like A.com, FamilySearch, myHeritage, digitized newspapers, find a grave, and municipality websites to find all of their information. Few go to the archives to look at a paper census, newspaper, etc. All of that is "Electronic" by strict understanding. As you say All Audio and Video Recordings are "electronic" in nature, otherwise the other items in the list are "born analog" but could be digitized.

@dthaler
Copy link
Collaborator Author

dthaler commented Jun 15, 2023

Discussion 6/15/2023:

  • MEDI in SOURCE_REPOSITORY_CITATION and MEDI in MULTIMEDIA_RECORD have different meanings. In the former, it's how you might need to look for it given the CALN information. In the latter, it arguably doesn't provide real value since one might always expect it to be ELECTRONIC for example, and the FORM <MediaType> already gives the format information.
    • We could consider deprecating the ELECTRONIC value.
    • We could consider deprecating the use of MEDI in MULTIMEDIA_RECORD.
  • In SOURCE_REPOSITORY_CITATION, we should add clarifying text. For example, what physical form it is in if that matters.

For the CD-ROM issue, we might consider adding values for CD-ROM, DVD, and Tape, but then there are many formats (VHS, Beta, 8-track, ...)? or generic like "Digital Storage Medium" and "Online" (replacing ELECTRONIC)? Rather than enumerating all formats, the second approach is simpler and may be sufficient for now.

@Norwegian-Sardines
Copy link

Yes in the case of “multi-media” and the “Multmedia_Record” the term “Electronic” is assumed.

wikipedia defines multi_media as:

Multimedia is a form of communication that uses a combination of different content forms such as text, audio, images, animations, or video into a single interactive presentation, in contrast to traditional mass media, such as printed material or audio recordings, which features little to no interaction between users.

Therefore the list of media types should be enumerated but remove anything not listed above, i.e. “printed newspaper” and exchange that for “text”. I’m not sure what value of Form <MediaType> without tell us that the media is a text, image, video, etc.

On the other hand CALN.MEDI definitely requires us to indicate how the repository holds the media and electronic is one of those options.

G7:MEDI needs to be divide into two uses MultiMedia type and Repository Holding type.

@Norwegian-Sardines
Copy link

Norwegian-Sardines commented Jun 16, 2023

Unfortunately in GEDCOM V5.5.1 and the software (a web based application) I use the SOURCE_MEDIA_TYPE is used to represent what information is contained in the media (audio | book | card | electronic | fiche | film | magazine | manuscript | map | newspaper | photo | tombstone | video) and that is used in the online display of selected media. For example I only display tombstones in the widget on the home page. Other people may want the widget to display photos that they define as images of people or video or audio clips.

EDIT: I don’t recall for sure but I think we may have added a few more MEDI to the media object like “coat of arms” and “painting” to help in defining the contents of the media file.

Deleting the ability to define the content of the file would be detrimental to our use!

dthaler pushed a commit to dthaler/GEDCOM that referenced this issue Jun 22, 2023
PR FamilySearch#316 covered the part of issue FamilySearch#316 applicable to 7.0.
This PR covers the part of issue FamilySearch#316 applicable to 7.1.

Signed-off-by: Dave Thaler <[email protected]>
@tychonievich
Copy link
Collaborator

PR #317 handles recommended practice for CALN.MEDI
PR #318 handles splitting ELECTRONIC in half (for 7.1)

We need a PR to update the use of ELECTRONIC from #317's example in 7.1

We have not yet handled the use of FORM.MEDI; the steering committee discussed adding an alternative path for the use case @Norwegian-Sardines noted, but do not yet have a concrete proposal for implementing that.

@dthaler
Copy link
Collaborator Author

dthaler commented Jun 29, 2023

We need a PR to update the use of ELECTRONIC from #317's example in 7.1

That one is now done in PR #320

dthaler pushed a commit to dthaler/GEDCOM that referenced this issue Mar 7, 2024
The proposed recommendation is consistent with sample files:
* https://gedcom.io/testfiles/gedcom70/maximal70.ged has MEDIA, OTHER,
  and ELECTRONIC.
* FamilySearch/GEDCOM.io#151 adds obje-1.ged
  with PHOTO and VIDEO, as copied from
  https://github.com/gedcom7code/test-files/blob/main/7/obje-1.ged

Fixes FamilySearch#316 since it addresses the last piece that wasn't already done

Signed-off-by: Dave Thaler <[email protected]>
dthaler added a commit that referenced this issue Mar 7, 2024
The proposed recommendation is consistent with sample files:
* https://gedcom.io/testfiles/gedcom70/maximal70.ged has MEDIA, OTHER,
  and ELECTRONIC.
* FamilySearch/GEDCOM.io#151 adds obje-1.ged
  with PHOTO and VIDEO, as copied from
  https://github.com/gedcom7code/test-files/blob/main/7/obje-1.ged

Fixes #316 since it addresses the last piece that wasn't already done

Signed-off-by: Dave Thaler <[email protected]>
Co-authored-by: Dave Thaler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants