search

tdwg / ac

Audiovisual Core
http://www.tdwg.org/standards/638
Creative Commons Attribution 4.0 International
11 stars 6 forks source link

Proposal to import term mo:sample_rate #177

Closed danstowell closed 3 years ago

danstowell commented 3 years ago

Term Name: mo:sample_rate (http://purl.org/ontology/mo/sample_rate)

Imported from: http://musicontology.com/specification/#term-sample_rate

Type: rdf:Property

Label: Sample Rate

Required: No

Repeatable: No

Definition: Associates a digital signal to its sample rate.

Usage: Numeric value in hertz (Hz)

Notes: For example, a Service Access Point may have a specific resolution, quality, or format. “Sample rate” is distinct from the related concept of “bit rate” for compressed files such as MP3, and is applicable to both uncompressed and compressed files.

Justification for the term addition: Audio sampling rate is an extremely common attribute of digitised sound recordings, and is important in search queries because it acts as a hard limit on the ability to represent sounds that occur in certain frequency ranges. It is often an indicator of the acceptability of a sound file for a particular purpose.

(Currently, “audio sampling rate” is mentioned in the unconstrained ac:resourceCreationTechnique, though this cannot support search queries very well. It is suggested that this use case is deprecated. See #179.)

Proposed by myself and @edwbaker

baskaufs commented 3 years ago

I made a cosmetic change adding the full URL since the mo: namespace is new to AC. Also, the type is the type of the term, not of the term's value, so I changed that to rdf:Property.

Let's create a separate proposal for changing the definition of ac:resourceCreationTechnique and reference it here.

baskaufs commented 3 years ago

One potential issue with importing any term from a formal ontology is that it may come with undesired entailments. I looked at the definition of mo:sample_rate and it has range and domain declarations. The range is xsd:float, which I guess is OK although I'd have to think about the difference between a literal with a datatype of xsd:float and xsd:float itself. The domain is mo:DigitalSignal, which implies that the subject resource is a digital signal. Again, I suppose that is OK, although the way we would use this would be with a subject that was a sound recording. So the question would be whether there was a problem with saying that something is both a digital signal and a sound recording. I suppose not.

baskaufs commented 3 years ago

Corrected capitalization of "hertz"

edwbaker commented 3 years ago

I don't see any issue with the domain, only digitised audio signals (rather than analogue audio) will have a sample rate. DigitalSignal also has other properties that may be of use, namely bitsPerSample and channels.

edwbaker commented 3 years ago

Is the literal/xsd:float going to make a difference to anyone using ac? If so, does it warrant minting a new term? I can't (right now at least) think of a problem.

baskaufs commented 3 years ago

Approved in Executive decision 31. Incorporated in rs.tdwg.org release 2020-10-13.