Code Table Request - Need part modifiers for media parts

[Jegelewicz]

Goal Describe the type of media held

Context See AWG Meeting Notes

Table Part Modifier

Proposed Value TBD

Proposed Definition TBD

Priority [ Please choose a priority-label to the right. ]

First step is to decide what are needed. Please provide terms and definitions useful to your collection in this issue so the community can discuss.

[dustymc]

Is this aiming for '35mm slide' or 'picture of a mouse'? The former seems defensible, I'm not so sure about the latter.

See also https://github.com/ArctosDB/arctos/discussions/5250

[Jegelewicz]

totally the former

[campmlc]

Yes, so including " scanned data sheet" or some such thing. Do we want to specify field notes vs prep catalogs vs data sheets? In this case, all our MSB:Mamm records have associated scanned data sheets. . .. Do we add media parts to all?

[dustymc]

scanned

That's not parts, maybe something about https://arctos.database.museum/info/ctDocumentation.cfm?table=ctmedia_type

Do we add media parts to all?

If you have something at the catalog record level that you want to get into the object tracking system, you would. You don't so no.

[campmlc]

So this means most Rausch observation.parts will not be converted to media parts, so I have no parts at all and no way to indicate the possibility they might exist somewhere? This is not what I understood yesterday.

On Thu, Nov 3, 2022, 7:26 PM dustymc @.***> wrote:

• [EXTERNAL]*

scanned

That's not parts, maybe something about https://arctos.database.museum/info/ctDocumentation.cfm?table=ctmedia_type

Do we add media parts to all?

If you have something at the catalog record level that you want to get into the object tracking system, you would. You don't so no.

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1302847897, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBEGF7HNPZGROL4A5VTWGRQ4RANCNFSM6AAAAAARWT3FZM . You are receiving this because you commented.Message ID: @.***>

[Jegelewicz]

I think we had a great discussion about this in the TDWG MaterialSample Working Hour today that got me thinking.

Mariel has an object - a field catalog. In Arctos, we have decided that all photos, papers and such should be recorded using the part "media" (except for when the photograph is in an art or ethnology collection, when it is recorded as an "object" - hmmm....).

In the MS discussion, we agreed with @dustymc that MaterialSample(s) (parts in Arctos) are things to which you could affix a barcode or things involving atoms. Through our discussion, I asked about the printed photo of a mouse and how that might/should be reflected as MaterialSample and everyone agreed that the material was the photograph, but what was depicted was an information artefact (Sorry about the weird British spelling, but that is how the collection description group is spelling it....).

Thing is, there is a whole standard for sharing "information artefacts" - Audubon Core.

The purpose of Audubon Core is to represent metadata for biodiversity multimedia resources and collections, and to make it possible for users to determine whether those resources would be fit for some biodiversity science application before acquiring the media.

As part of that standard, there is a term - subjectPartLiteral

Definition - The portion or product of organism morphology, behaviour, environment, etc. that is either predominantly shown or particularly well exemplified by the media resource, denoted by a controlled value string..

Usage - Values SHOULD be selected from the Controlled Vocabulary for Audubon Core subjectPart. It is best practice to use ac:subjectPart instead of ac:subjectPartLiteral whenever practical.

There is a TDWG Task Group currently working on controlled vocabulary for the ac:subjectPart term - https://www.tdwg.org/community/ac/views/ Their recommendation is currently open for public comment. The interesting thing is that the vocabulary is essentially equal to parts - https://github.com/tdwg/ac/blob/master/views/code/subjectPart/subjectPart.md#3-term-index which makes sense because this was developed to assist with camera trap tagging - so it is mostly parts you can see in an image of a live thing.

Given all of that - I think that perhaps we need to be able to use the part table in more than one way. First to identify physical things in our collections, but second to identify items of interest in "media". BUT it also made me wonder if putting the type of media in a modifier makes sense. Isn't it akin to saying that we should just call all biological things "organism" and then detailing what our actual evidence is in an attribute? Why are we willing to add "hyoid apparatus" to the part list, but not "photograph"? Are we being too biology-centric?

All of that aside - for @campmlc field catalogs, this seems appropriate:

part = media (because she DOES have paper she can put her hands on and just because she isn't barcoding it doesn't mean she couldn't someday).

part modifier = subject part (defined as The portion or product of organism morphology, that is either predominantly shown or particularly well exemplified by the media resource, denoted by a controlled value string.) NOTE that I excluded behavior and environment from our definition - those would need separate attributes IMO.

subject part part modifier value - controlled by the parts table

part modifier = media type

media type value - controlled by code table media type

I know that was a lot - but I hope it is helpful....

[dustymc]

use the part table in more than one way

No. See search on https://github.com/ArctosDB/arctos/discussions/5250.

Why are we willing to add "hyoid apparatus" to the part list, but not "photograph"?

"Photograph" is more like 'bone' (or "animal bit" maybe) - we used to have dozens of media-things ('35mm color slide') no real firm technical reason we can't go back there, but that would need discussed by itself (and it wasn't much fun the first time around).

part = media

That's firmly in Worst Practices - I can't stop you, but I'm not going to be able to help you (or your successor) when this means they need to update a hundred thousand parts to move a box of paper.

NOTE that I excluded behavior and environment

That's slicing things awfully thin, especially when a bunch of these are descriptions of exactly that. (Nobody cares that squirrels have livers, the traces left by the parasites is the interesting thing.)

[campmlc]

I'm not sure I understand @dustymc 's comments. For one thing, if "we used to have dozens of media-things" - it is probably because there is a need to record these metadata. It is valuable to know whether something is a 35mm color slide or a 60 year old ledger on archival paper or a digital image. Audubon core would let us capture this?

[dustymc]

I'm not sure I understand me either, if you want to file an Issue I'll try to dredge up details. I think part of it was that nobody wants to borrow '35mm color slide,' they just care about what's represented on the slide. That was before Arctos was quite so cosmopolitan, might deserve a rethink, IDK.

record these metadata. It is valuable to know whether something is a 35mm color slide or a 60 year old ledger on archival paper

In the same way part=brain doesn't tell you anything about preservation and such (whole brain in a cyborg jar, tissue-grade subsample, slide-mounted section, ????) neither does nor should part=slide. (Both should have some data somewhere, but not embedded in part name.)

or a digital image

That will never be an appropriate part in the current model, see linked discussion. (Media or eventually "thumb drive" or "8MB XYZBrand Model ABC thumb drive" or something of the sort might be.)

Audubon core would let us capture this?

No, its an extension to an exchange standard, not a model. It does suggest that these data are media-things, as I suggested in the linked discussion. (And FWIW Arctos has shared Audubon data since before Audubon was a Standard.)

[campmlc]

From the Material Sample conversation today, and from what I understand about the new GBIF model, there seems to be a movement towards something like "MaterialEntity", a physical object, and "Digital Entity" or maybe, if this is the same thing, "Information Artefact". That means we need parts and metadata for the MaterialEntity and separate metadata for the Digital or Information Entity, and means to relate them. We need something to indicate in a MaterialEntity that the information we know about the existence of a physical object, including the organism in the wild, comes from an Information Entity or Artefact. Something that would replace "observation" as a part name, and allow us to record that according to this media or information or digital whatever, something was collected and there should be a skull somewhere. This is where I am still struggling as to how this works.

On Mon, Nov 7, 2022 at 7:12 PM dustymc @.***> wrote:

• [EXTERNAL]*

I'm not sure I understand me either, if you want to file an Issue I'll try to dredge up details. I think part of it was that nobody wants to borrow '35mm color slide,' they just care about what's represented on the slide. That was before Arctos was quite so cosmopolitan, might deserve a rethink, IDK.

record these metadata. It is valuable to know whether something is a 35mm color slide or a 60 year old ledger on archival paper

In the same way part=brain doesn't tell you anything about preservation and such (whole brain in a cyborg jar, tissue-grade subsample, slide-mounted section, ????) neither does nor should part=slide. (Both should have some data somewhere, but not embedded in part name.)

or a digital image

That will never be an appropriate part in the current model, see linked discussion. (Media or eventually "thumb drive" or "8MB XYZBrand Model ABC thumb drive" or something of the sort might be.)

Audubon core would let us capture this?

No, its an extension to an exchange standard, not a model. It does suggest that these data are media-things, as I suggested in the linked discussion. (And FWIW Arctos has shared Audubon data since before Audubon was a Standard.)

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1306517891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBGEBRBPFHZX7XBRJOLWHGZHBANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[campmlc]

And these information artefacts may be physical ledger pages, and we may also have digital scans of them as media. We need an example for how this would be represented in our model and in our UI.

On Mon, Nov 7, 2022 at 7:23 PM Mariel Campbell @.***> wrote:

From the Material Sample conversation today, and from what I understand about the new GBIF model, there seems to be a movement towards something like "MaterialEntity", a physical object, and "Digital Entity" or maybe, if this is the same thing, "Information Artefact". That means we need parts and metadata for the MaterialEntity and separate metadata for the Digital or Information Entity, and means to relate them. We need something to indicate in a MaterialEntity that the information we know about the existence of a physical object, including the organism in the wild, comes from an Information Entity or Artefact. Something that would replace "observation" as a part name, and allow us to record that according to this media or information or digital whatever, something was collected and there should be a skull somewhere. This is where I am still struggling as to how this works.

On Mon, Nov 7, 2022 at 7:12 PM dustymc @.***> wrote:

• [EXTERNAL]*

I'm not sure I understand me either, if you want to file an Issue I'll try to dredge up details. I think part of it was that nobody wants to borrow '35mm color slide,' they just care about what's represented on the slide. That was before Arctos was quite so cosmopolitan, might deserve a rethink, IDK.

record these metadata. It is valuable to know whether something is a 35mm color slide or a 60 year old ledger on archival paper

In the same way part=brain doesn't tell you anything about preservation and such (whole brain in a cyborg jar, tissue-grade subsample, slide-mounted section, ????) neither does nor should part=slide. (Both should have some data somewhere, but not embedded in part name.)

or a digital image

That will never be an appropriate part in the current model, see linked discussion. (Media or eventually "thumb drive" or "8MB XYZBrand Model ABC thumb drive" or something of the sort might be.)

Audubon core would let us capture this?

No, its an extension to an exchange standard, not a model. It does suggest that these data are media-things, as I suggested in the linked discussion. (And FWIW Arctos has shared Audubon data since before Audubon was a Standard.)

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1306517891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBGEBRBPFHZX7XBRJOLWHGZHBANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[dustymc]

"MaterialEntity", a physical object

==parts

and "Digital Entity"

==media

and separate metadata for the Digital

Yes, exactly. See "Depicted in media" in the linked discussion - I think that's what you're trying to do, but IDK.

Something that would replace "observation" as a part name, and allow us to record that according to this media or information or digital whatever, something was collected and there should be a skull somewhere

That's just an observation. There is or supposedly was a (whatever, as represented by some text or a picture or a memory or something of the sort) out there somewhere. We ain't got it, there's nothing to which one could stick barcodes in any interpretation of our possession, so it's not parts. Most mammals have skulls, I don't think that's much of an inference, I can't understand why we need to make it. ("Depicted in media"??)

And these information artefacts may be physical ledger pages,

If you were to cut the pages up and barcode the "individual" slices, then you might have a reason to treat them as part. (Please don't...) Otherwise, they're better tracked at the accn/project/agent - some "lotsa records and a book" level.

We need an example

Archive collections solve a whole bunch of media-record-related problems - go click around!

[campmlc]

" That's just an observation" - is exactly why I used part = observation for this. If I lose that part, then I have no where anywhere to record this is an observation based on the information encoded in the media. I can leave off all parts, but the absence of any information is not the same as the presence of useful information. I don't want to add a part=skull, with disposition = not applicable, and "according to the media attached somewhere else, this was collected at some point but we don't know where it is or whether or not it still exists". I just want to say that this catalog record is an observation derived from media, until such time as a physical object materializes. Part = observation works for this. No one will request it for loan. From a practical rather than a philosophical point of view, this works. As a collection manager, I need practical solutions, as do the people outside of Arctos who are searching our data.

On Mon, Nov 7, 2022 at 8:17 PM dustymc @.***> wrote:

• [EXTERNAL]*

"MaterialEntity", a physical object

==parts

and "Digital Entity"

==media

and separate metadata for the Digital

Yes, exactly. See "Depicted in media" in the linked discussion https://github.com/ArctosDB/arctos/discussions/5250 - I think that's what you're trying to do, but IDK.

Something that would replace "observation" as a part name, and allow us to record that according to this media or information or digital whatever, something was collected and there should be a skull somewhere

That's just an observation. There is or supposedly was a (whatever, as represented by some text or a picture or a memory or something of the sort) out there somewhere. We ain't got it, there's nothing to which one could stick barcodes in any interpretation of our possession, so it's not parts. Most mammals have skulls, I don't think that's much of an inference, I can't understand why we need to make it. ("Depicted in media"??)

And these information artefacts may be physical ledger pages,

If you were to cut the pages up and barcode the "individual" slices, then you might have a reason to treat them as part. (Please don't...) Otherwise, they're better tracked at the accn/project/agent - some "lotsa records and a book" level.

We need an example

Archive collections solve a whole bunch of media-record-related problems - go click around!

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1306569189, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAS7IVBX55PEMBO5FDWHHA37ANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[campmlc]

I am willing to give up part = observation, but I need something to replace it with that simply and easily encodes the same information content understandable by most people. It seems like all these discussions here and elsewhere seem to center around what is the "evidence" we have for an occurrence. Physical Parts are evidence. Media is evidence. Media may be either physical or digital. The occurrences documented in the Rausch ledger are supported by evidence as physical media, which were recorded by an observer at a place and time. At some point, this media evidence may be added to by the evidence of physical parts, if we locate them. I need to record the media evidence in order to be able to search for and link to the potentially existing physical parts. So how can I record this in a way that makes that clear?

On Mon, Nov 7, 2022 at 8:24 PM Mariel Campbell @.***> wrote:

" That's just an observation" - is exactly why I used part = observation for this. If I lose that part, then I have no where anywhere to record this is an observation based on the information encoded in the media. I can leave off all parts, but the absence of any information is not the same as the presence of useful information. I don't want to add a part=skull, with disposition = not applicable, and "according to the media attached somewhere else, this was collected at some point but we don't know where it is or whether or not it still exists". I just want to say that this catalog record is an observation derived from media, until such time as a physical object materializes. Part = observation works for this. No one will request it for loan. From a practical rather than a philosophical point of view, this works. As a collection manager, I need practical solutions, as do the people outside of Arctos who are searching our data.

On Mon, Nov 7, 2022 at 8:17 PM dustymc @.***> wrote:

• [EXTERNAL]*

"MaterialEntity", a physical object

==parts

and "Digital Entity"

==media

and separate metadata for the Digital

Yes, exactly. See "Depicted in media" in the linked discussion https://github.com/ArctosDB/arctos/discussions/5250 - I think that's what you're trying to do, but IDK.

Something that would replace "observation" as a part name, and allow us to record that according to this media or information or digital whatever, something was collected and there should be a skull somewhere

That's just an observation. There is or supposedly was a (whatever, as represented by some text or a picture or a memory or something of the sort) out there somewhere. We ain't got it, there's nothing to which one could stick barcodes in any interpretation of our possession, so it's not parts. Most mammals have skulls, I don't think that's much of an inference, I can't understand why we need to make it. ("Depicted in media"??)

And these information artefacts may be physical ledger pages,

If you were to cut the pages up and barcode the "individual" slices, then you might have a reason to treat them as part. (Please don't...) Otherwise, they're better tracked at the accn/project/agent - some "lotsa records and a book" level.

We need an example

Archive collections solve a whole bunch of media-record-related problems

• go click around!

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1306569189, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAS7IVBX55PEMBO5FDWHHA37ANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[dustymc]

I need something to replace it

I'm not sure where everyone else is, but I can't quite grasp what you're trying to DO so I'm struggling to suggest a replacement. I'm positive that what you're doing cannot make sense, beyond that I'm struggling.

center around what is the "evidence" we have for an occurrence.

And I think yours is entirely "depictional." You don't have a skull, and I can't figure out why you insist on saying you do. As above, most squirrels have one at some point!

Media is evidence. Media may be either physical or digital.

AHA!, perhaps. You have a Polaroid with a picture of a squirrel. You have parts (the picture) and you have evidence (whatever's on the picture). You digitize, upload to "the cloud," and shred the picture. You no longer have parts, but the evidence has not changed. You download, save to a thumb drive, barcode it, and toss it in the collection - you have parts (something to track) again, the evidence still has not changed. (Unless you're repeatedly saving in a lossy format...)

In no case is the part (physical thing - polaroid, drive) in any way related to the evidence (what's depicted in the "media").

evidence as physical media

But not that which makes sense to track as parts. The addition of parts just seems to add confusion here. (The current situation - a nonphysical thing in the physical stuff node - can't really do anything else.)

[Jegelewicz]

use the part table in more than one way

No. See search on https://github.com/ArctosDB/arctos/discussions/5250.

I am not talking about Arctos media, I am talking about part attributes for the part name = media

[Jegelewicz]

part = media

That's firmly in https://github.com/ArctosDB/arctos/discussions/5250 - I can't stop you, but I'm not going to be able to help you (or your successor) when this means they need to update a hundred thousand parts to move a box of paper.

I really am in the dark here. We have a part called media and it is meant for just the thing @campmlc has - a sheet of paper with some words on it. There is no reason that all 500 pages in the box wouldn't just share a barcode (the container they are in), so I also don't understand the moving issue (nevermind that at this point nobody is suggesting these pages be managed that way).

[Jegelewicz]

Archive collections solve a whole bunch of media-record-related problems - go click around!

While I am completely in favor of archive collections, I also don't think we should require one for the thing @campmlc is trying to do and I'm not really sure that I see how that would solve her problem.

[campmlc]

I have the same question. In fact, I don't see why we can only have one part name for media. We have part names for every tissue type of a vertebrate, because people need to specifically search for and request "spleen". Wouldn't it be just as important to be able to search for and request 35 mm slides vs field catalogs? It works to make the part=media and the attribute "slide, 35 mm" too, but it isn't necessarily consistent with how we've treated other parts. So there seems to be some flexibility here? Or am I missing something?

On Tue, Nov 8, 2022 at 3:15 PM Teresa Mayfield-Meyer < @.***> wrote:

• [EXTERNAL]*

part = media

That's firmly in #5250 https://github.com/ArctosDB/arctos/discussions/5250 - I can't stop you, but I'm not going to be able to help you (or your successor) when this means they need to update a hundred thousand parts to move a box of paper.

I really am in the dark here. We have a part called media and it is meant for just the thing @campmlc https://github.com/campmlc has - a sheet of paper with some words on it. There is no reason that all 500 pages in the box wouldn't just share a barcode (the container they are in), so I also don't understand the moving issue (nevermind that at this point nobody is suggesting these pages be managed that way).

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1307897707, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBBPQJ56JATOMA3QL6TWHLGG5ANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[Jegelewicz]

It is becoming increasingly apparent that we are confounding digital media and physical media and I think we need to change our terms to be two different things so that we know what we are talking about at any given time.

Digital media is the stuff found here.

Physical media is this.

[campmlc]

Quite likely a record would have both, as in our case. We have a physical page of the necropsy ledger, which is the ultimate source of our observation of the occurrence of these hosts and parasites, and the complete set of primary recorded data that would allow us to confirm the existence of a physical part should one be located (which might be just a mouse in a jar with a tag with just the RLR number on it). But we have also scanned these pages digitally, associated the scans with the accession, and are working through tagging the scanned media to the catalog record, but this process will take years to complete.

On Tue, Nov 8, 2022 at 3:23 PM Teresa Mayfield-Meyer < @.***> wrote:

• [EXTERNAL]*

It is becoming increasingly apparent that we are confounding digital media and physical media and I think we need to change our terms to be two different things so that we know what we are talking about at any given time.

Digital media is the stuff found here https://arctos.database.museum/MediaSearch.cfm.

Physical media is this https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecimen_part_name#media .

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5249#issuecomment-1307913248, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAOHM3IFLPLVHKL5KDWHLHHDANCNFSM6AAAAAARWT3FZM . You are receiving this because you were mentioned.Message ID: @.***>

[dustymc]

Tabling, I don't think this is actionable, someone please reopen and clarify if I'm lost.