Literal comments for dct:format

[tombaker]

See range_format.md. See also related Issue #24 ("Literal example for dct:language").

In DCMIMT (and in ISO 15836-1), the usage note for the properties http://purl.org/dc/elements/1.1/format and http://purl.org/dc/terms/format read:

Examples of dimensions include size and duration.  Recommended best
practice is to use a controlled vocabulary such as the list of Internet
Media Types [MIME].

[MIME] http://www.iana.org/assignments/media-types/

The ISO WG proposes to reword the existing comment, then add a comment and examples:

Best practice for description of file format is to use a controlled
vocabulary such as the list of Internet Media Types [MIME].

In addition to the specific physical or electronic media format,
information concerning the size of a resource may be included in the
content of the Format element if available. In resource discovery size,
extent or medium of the resource might be used as a criterion to select
resources of interest, since a user may need to evaluate whether they can
make use of the resource within the infrastructure available to them.

EXAMPLES text/xml
         4 kB
         40 x 512 pixels
         22 in.

Note that in both cases, Format is (already) defined as follows:

The file format, physical medium, or dimensions of the resource.

[tombaker]

Note:

• Format has a range of dcterms:MediaTypeOrExtent, which means that the values of dcterms:format should be instances of that class, or URIs.
• The list of MIME types, http://www.iana.org/assignments/media-types/, is a controlled list of strings, not a controlled list of URIs.

[tombaker]

Note that in Issue #2 (now closed), Karen commented:

Should not include both format and dimensions. Dimensions needs to be its own property because most resources can have both a format AND dimensions, so it's not either/or, and combining them in a single value makes for difficult parsing.

[rguenther52]

I've been working on the revision of the PREMIS OWL ontology and the following issue about dcterms:medium came up. See: https://github.com/PREMIS-OWL-Revision-Team/revise-premis-owl/blob/master/premis3.owl for the ontology.
We were going to make premis:hasMedium (which is the physical medium on which a digital file is stored) a subproperty of dcterms:medium, but the domain of dcterms:medium is dcterms:PhysicalResource and the range is dcterms:PhysicalMedium. Since we have a digital file, we can’t use dcterms:medium, since it specifies that the domain must be a material/physical resource. There is also the class dcterms:MediaType ("a file format or physical medium"), of which dcterms:PhysicalMedium is a subclass. dct:FileFormat is also a subclass of dcterms:MediaType. dcterms:medium is a subproperty of dc:format, which is "the file format, physical medium or dimensions". I would have expected that dcterms:medium would not be restricted in its domain and have a range of dcterms:MediaType, rather than dcterms:PhysicalMedium, so that its value could be a file format (even if MIME types don't have URIs, there could be format registries that do, e.g. PRONOM). Back in the days when refinements were first added to DC 1.1 I recall when the refinements medium and extent were added for dc:format, which ,as I remember it, was to distinguish between formats (whether physical or digital) and extent (echoing what Karen says above about separating format and dimensions), where extent will always most likely be a string and the format could easily be a URI. (There is also the point that "dimensions" may or may not be included in "extent" (which is the dcterms property), but that's another issue.) If you're interested, all the documentation for the PREMIS revision is at: http://www.loc.gov/standards/premis/ontology/owl-version3.html. We are in the process of finalizing the ontology and updating the preservation vocabularies that work with it at id.loc.gov/vocabulary/preservationdescriptions/.

[juhahakala]

Given the difficulty to specify Format, I have restored the original text, but the comment has been split into two notes, once concerning dimensions, the other file format.

[tombaker]

Updated 2018-07-19
The current ISO draft reads:

Note 1 to entry: Examples of dimensions include size and duration.

Note 2 to entry: Recommended practice is to use a controlled vocabulary
such as the list of Internet Media Types [MIME].


    EXAMPLES text/xml
             4 kB
             40 x 512 pixels
             22 in.

@rguenther52 If the domain and range of medium become domain/rangeIncludes PhysicalResource and PhysicalMedium, it will no longer be a contradiction to use the property with files.

Please comment here.

[aisaac]

@tombaker thould this really be closed? I don't even remember hearing it being discussed

[rguenther52]

I'm not sure I'm clear on what you're proposing other than editing the comment. Are you changing the domain and range of dcterms:medium so that they are more general and can be used for the medium of physical or digital? That is, take out the domain restriction and change the range to dcterms:MediaType? At this point, in the PREMIS ontology we are taking out the assertion that premis:hasMedium is a subproperty of dcterms:medium. See: PREMIS-OWL-Revision-Team/premis-owl#60

[rguenther52]

Now I'm discovering that this discussion is only concerning the changes for the ISO standard, which doesn't include the RDF-- which is what I am suggesting be changed.

[tombaker]

PROPOSED

Note 1 to entry: Recommended practice is to use a controlled vocabulary
where available. For example, for file formats one could use the list of Internet Media Types 
[MIME].

    Note 2 to entry: Examples of dimensions include size and duration.
    
    EXAMPLES text/xml
             4 kB
             40 x 512 pixels
             22 in.

[kcoyle]

I guess I'd vote +1 although I really don't approve of a value that can be format, physical medium, and/or dimensions.