Attribute(s) for the size tag

[gramian]

What is the problem that your suggestion solves?

Currently, the size field is hard to parse free-text. Specifically for my case, I try to find the size in Bytes (if available) of DataCite described resources, this means I need to filter for all variants to write a digital information unit. So in addition to check for all possible writings of decimal and binary prefixes for Bytes, I need to decipher if the full unit name is used (in some variants).

What solution might meet your needs?

I would most prefer to have the size field content to be numeric and have one or more attributes describing its content, for example just unit as a sole (free-text) attribute would be already helpful, an additional (optional) attribute for digital content like bytes would be the best case for me, where I would just have to parse the prefixes.

Your name

No response

Your organization

No response

What alternatives have you tried or considered?

No response

Is there anything else you would like to share?

No response

What group(s) would benefit from your suggestion?

• DataCite members registering DOIs and metadata and administering accounts
• Developers building integrations with DataCite services
• Harvesters who index DataCite DOIs and metadata
• Individuals or institutions analyzing DataCite DOIs and metadata
• DataCite staff
• Other

If other group(s), please describe.

No response

[KellyStathis]

Thanks for this suggestion, @gramian! We're also thinking about how we can make it easier to parse the contents of the size property, without restricting it solely to numeric data, and considering how a "unit" attribute could support this.

There are a couple adjacent discussions you may be interested in—if you have any feedback on these ideas, we'd love to hear from you:

• this discussion of the size property in the context of Award metadata: Support for award amounts in DataCite metadata #242
• the (re-opened) RFC for the Distribution property, which includes a byteSize attribute for contentURL: Request for comment: New Distribution property #211

[borsna]

Cross posting my comment from #242 (comment)

In addition to a free text unit-property it would be nice to add a optional unitUri for the unit similar to other fields in DataCite where a vocabulary is used e.g:

<sizes>
  <size unitUri="http://qudt.org/vocab/currency/CAD" unitCode="CAD">1000</size>
</sizes>

<sizes>
  <size unitUri="http://qudt.org/vocab/unit/BYTE" unitCode="B">1000</size>
</sizes>

<sizes>
  <size unitUri="http://dbpedia.org/resource/Hour" unitCode="Hour">40</size>
</sizes>

[drkotireddysaripalli]

Could the proposal include lossless interpretation fixtures, alongside the possible unit attributes? They would make the byte-extraction use case testable without restricting Size to numeric content.

The current 4.7 Size definition is optional, repeatable free text and includes physical extent and duration. NIST's unit definitions distinguish decimal MB from binary MiB. However, interpreting a symbol according to those definitions does not prove that an unknown legacy depositor intended that convention, or that the original measurement was exact.

For a declared SI/IEC interpretation, a conservative byte-unit-only parser could use these fixtures:

Original text, retained unchanged	Derived integer bytes	Interpretation boundary
1 MB	1000000	Decimal prefix
1 MiB	1048576	Binary prefix
1.5 MiB	1572864	Exact arithmetic under declared units
1 Mb	unset	Bit unit outside this parser's scope; do not case-fold b to B
1,5 MB	unset	Locale-dependent notation outside this grammar
20 pages / 45 minutes	unset	Preserve the non-byte extent
1000	unset	Unit unspecified
<1 MB	unset	Preserve the bound, rather than turn it into an exact count
0.1 B	unset	Non-integer byte result; do not round

Here is a narrow synthetic downstream example, not a DataCite validator or proposed XML representation. The caller must establish the convention; it is never inferred merely from the string. If that convention is unresolved, even 1 MB retains an unset derived value.

import re
from fractions import Fraction

def interpret_size(raw, unit_profile=None):
    result = {"raw": raw, "unit_profile": unit_profile, "bytes": None}
    if unit_profile != "SI/IEC":
        return {**result, "reason": "unit convention not established"}
    match = re.fullmatch(
        r"([0-9]+(?:\.[0-9]+)?)[ \t]+(B|kB|MB|GB|TB|KiB|MiB|GiB|TiB)",
        raw.strip(),
    )
    if not match:
        return {**result, "reason": "outside declared byte-unit grammar"}
    factors = {"B": 1, "kB": 10**3, "MB": 10**6, "GB": 10**9, "TB": 10**12,
               "KiB": 2**10, "MiB": 2**20, "GiB": 2**30, "TiB": 2**40}
    value = Fraction(match[1]) * factors[match[2]]
    if value.denominator != 1:
        return {**result, "reason": "non-integer byte result; do not round"}
    return {**result, "bytes": int(value), "reason": "derived under declared units"}

I checked the shown cases plus unit, whitespace and precision boundaries locally: 26 synthetic inputs, preserving the raw value and declining conversion when the convention is unestablished. This does not validate a deposit, cover all legacy notation or measure a file's actual payload.

Would the proposal preserve the original extent and make the conversion convention and unresolved state explicit? An unsupported value in this example is not a DataCite validation error. The Distribution discussion #211 remains a proposal under revision; these fixtures do not assume adoption of byteSize or new Size attributes.

Disclosure: I am founder/chairman of Bharath Healthcare (BHCL). This source-based methods contribution was prepared with Codex assistance; it does not seek endorsement of our work.