New term: ac:Media

[baskaufs]

In the past, the AC Maintenance Group has considered whether to mint a class term for media items. Things that would be described by Audiovisual Core properties (excluding ServiceAccessPoint and RegionOfInterest properties) would typically be instances of this class. It was decided that such a class term should be minted when a need for it was demonstrated.

The Darwin Core Data Package (DwC-DP) proposal, currently under review, includes addition of the new term dwc:Media. The DwC-DP working group feels that this term would be more appropriate in the Audiovisual Core ac: namespace than in dwc:.

Given this situation, it seems like the need for the class term ac:Media has been demonstrated and it would be prudent for us to fast-track the creation of this term before the end of the 90 day DwC-DP public comment period (lasting until at least 16 December 2025) so that it could be borrowed for use in DwC-DP, rather than necessitating the creation of dwc:Media by the Darwin Core Maintenance Group.

Here is the proposal from the dwc repository issue tracker tdwg/dwc#589 , with modifications made by the AC MG:

New term - Media

• Submitter: Darwin Core Data Package Coordination Team and Audiovisual Core Maintenance Group
• Efficacy Justification (why is this term necessary?): see Darwin Core Data Package (DwC-DP) Implementation Experience and Feature Report
• Demand Justification (name at least two organizations that independently need this term): see Darwin Core Data Package (DwC-DP) Implementation Experience and Feature Report
• Stability Justification (what concerns are there that this might affect existing implementations?): None

Proposed attributes of the new term:

• Term name (in lowerCamelCase for properties, UpperCamelCase for classes): Media
• Term label (English, not normative): Media Entity
• Organized in Class (e.g., Occurrence, Event, Location, Taxon):
• Definition of the term (normative): A digital or physical media resource.
• Usage comments (recommendations regarding content, etc., not normative): An instance of digital textual media may be better represented as a dcterms:BibliographicResource.
• Examples (not normative): dcmi:Sound; dcmi:StillImage; dcmi:MovingImage; dcmi:InteractiveResource;ac:Digital3DResource
• Refines (identifier of the broader term this term refines; normative):
• Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative):
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative):

[danstowell]

I don't think I was in the previous discussion, but I am happy to concur with this proposal.

[baskaufs]

I don't think I was in the previous discussion, but I am happy to concur with this proposal.

I think it was a long time ago when Bob Morris was the convener.

[tucotuco]

I am fine with the change in definition and the added example. I am not a fan of having a label different from the term name. To me "Item" adds nothing. We would use the label "Media" in DwC-DP in any case.

[baskaufs]

We discussed the local name and label at length. Our issue with "media" is that it is the plural of "medium". As far as I know, class names are always in the singular and "medium" did not seem appropriate to us. We considered "MediaItem" as the local name with the label "Media Item", but weren't sure if this would break some existing implementations. It is actually pretty common in AC to have a label that differs in some way from the term local name, so that's why we went with "Media Item" for the label.

[baskaufs]

We also dropped from the original proposal the "with other entities as subject matter." part of the definition. It would be perfectly appropriate in AC to create a metadata record for a sound recording that ran for 30 minutes and didn't record any organisms. In that case there would be no other entity as a subject. We figured that if DwC wanted to add an assumption of linking to other subject matter in a usage comment, that could easily be done.

[tucotuco]

In the Unified Model we called it MediaEntity to parallel MaterialEntity, but in DwC-DP we use the label "Material" for exactly the same reason, "Entity" doesn't add anything.

[ben3000]

I agree with this proposal.

[DavidFichtmueller]

No objections from my side.

For completeness sake, the ABCD 2 Term URI is http://rs.tdwg.org/abcd2/terms/MultiMediaObject (the XPath is /DataSets/DataSet/Units/Unit/MultiMediaObjects/MultiMediaObject , but the Term URI is the prefered way to refer to the concept, however the term tdwgutility:abcdEquivalence has historically been used with the XPath [this term should be retired in favor of some proper mappings between the different standards, but this is a topic for another time and Interest Group]); for ABCD3 it is: http://rs.tdwg.org/abcd/terms/MultimediaObject

[baskaufs]

For completeness sake, the ABCD 2 Term URI is http://rs.tdwg.org/abcd2/terms/MultiMediaObject (the XPath is /DataSets/DataSet/Units/Unit/MultiMediaObjects/MultiMediaObject , but the Term URI is the prefered way to refer to the concept, however the term tdwgutility:abcdEquivalence has historically been used with the XPath [this term should be retired in favor of some proper mappings between the different standards, but this is a topic for another time and Interest Group]); for ABCD3 it is: http://rs.tdwg.org/abcd/terms/MultimediaObject

Thanks for this, @DavidFichtmueller. AC has not previously used a field for ABCD equivalence, so there's no column for it in the tables that we use to generate the documentation. We have been using a field called "Definition derived from" (in RDF mapped to sawsdlrdf:modelReference) in cases where we've adopted a definition from elsewhere, but that doesn't really apply here. Maybe we can just add a note that this class is equivalent to the ABCD term. That wouldn't establish any machine-readable link, but I'm not sure that the tdwgutility:abcdEquivalence statements are actually really machine-readable either. Thoughts?

[vijaybarve]

I agree with this proposal.