Re: [jats-list] Confirming STS metadata cardinality

["Debbie Lapeyre dalapeyre@xxxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Thank you Gerrit, well said!

--Debbie

> On Jun 29, 2023, at 6:47 PM, Imsieke, Gerrit, le-tex
gerrit.imsieke@xxxxxxxxx <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Ken,
>
> In <front>, the cardinality of <std-meta> is unbounded because you should be
able to substitute each of <iso-meta>, <reg-meta>, and <nat-meta> with
<std-meta>. I don't have an exact recollection why we specified it like this.
I think it is meant as a gateway drug for people who want to migrate from
nat-meta, reg-meta, and iso-meta in <front> to the more versatile std-meta,
still in <front>, without the need to transition to a nested adoption model
all at once.
>
> One advantage of migrating to std-meta is that you can use
std-org/std-org-abbrev instead of std-ident/originator that is only kept for
compatibility.
>
> Personally, I wouldn't do or recommend such a piecemeal transition, I'd
switch to adoptions at the same time as I switch to <std-meta>. But not every
standard is developed in such an adoption chain.
> /standard/front/std-meta+ can also be viable when a standard is co-developed
by different organizations that don't fit into an iso/reg/nat chain.
>
> Regarding the question of how to use @originator to point to a certain
organization: Each <std-meta> element should contain std-org/std-org-abbrev or
std-org-group/std-org/std-org-abbrev, and these abbreviations are typically
used as @originator attribute values. However, neither the standard nor the
non-normative documentation enforce this. The documentation only says "This
name is typically the short form name, such as bASMEb." It does not
explicitly state something like "the value of the originator attribute must
correspond to a single std-org-abbrev in the same document".
>
> As mentioned above, In ISO STS 1.1, there was std-ident/originator that had
the same loosely-coupled relationship with @originator. It can still be used
for backward compatibility.
>
> I wished that the documentation recommended more explicitly that
<std-org-abbrev> and @originator be used as ID/IDREF-like organization
identifiers and references, respectively.
>
> Gerrit
>
> On 29.06.2023 22:32, G. Ken Holman g.ken.holman@xxxxxxxxx wrote:
>> Hello, again, everyone.
>> originat
>> May I please poke someone responsible for NISO-STS regarding the question I
posted earlier regarding the cardinality of metadata elements?
>> For example, I cannot see how to put three <std-meta> elements under
<front>, say for international, regional, and national distinctions, even when
distinguished by std-meta-type=, because there are no originator= attributes
to associate front-matter sections that use originator=. Users of the data
might inconsistently derive an originator value from the possibilities found
in the metadata.
>> If my guess is correct that the semantic cardinality is limited to one
(regardless of the syntactic cardinality), then I can make a number of
assumptions for simplicity.
>> Thank you for taking a moment of your time for your observations.
>> . . . . . . Ken
>> At 2023-06-16 12:50 +0000, G. Ken Holman g.ken.holman@xxxxxxxxx wrote:
>>> Hi, folks! I enjoyed seeing everyone this week.
>>>
>>> When talking about adoptions and metadata this week at JATS-Con, it came
to mind that I've made assumptions from the documentation and probably should
confirm my assumptions while I've got my fingers in my code.
>>>
>>> Looking at a standard's front matter:
>>>
>>>
https://www.niso-sts.org/TagLibrary/niso-sts-TL-1-2-html/element/front.html
>>>
>>> I read:
>>>
>>>> (in one or more of the elements <std-meta>, <iso-meta> <reg-meta> or
<nat-meta>)
>>>
>>> ... and:
>>>
>>>> Any combination of:
>>>>  - <std-meta> NISO STS Standard Metadata
>>>>  - <iso-meta> ISO-specific Metadata
>>>>  - <reg-meta> ISO-specific Regional Metadata
>>>>  - <nat-meta> ISO-specific National-Body Metadata
>>>
>>> ... and:
>>>
>>>> (std-meta | iso-meta | reg-meta | nat-meta)*
>>>
>>> ... and I've always assumed that the multiplicity in the cardinality
applied only to the choice of elements and not to the individual elements
themselves.
>>>
>>> In RELAX-NG this would be expressed with interleave, but we all know we
don't have that in DTD-speak or W3C-speak.
>>>
>>> Moreover, I've assumed <std-meta> to be mutually exclusive with
<iso-meta>, <reg-meta>, and <nat-meta>.
>>>
>>> I based my assumptions on the cardinality of 0..1 for <std-meta> in
<adoption-front>. Using pure <std-meta> in adoption layers simply avoids the
ambiguity of multiplicity.
>>>
>>> Do I need to adjust my assumptions? Am I missing something in the semantic
definitions of these constructs?
>>>
>>> Thank you for your guidance!
>>>
>>> . . . . . . . Ken
>> --
>> Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/j/ |
>> Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
>> Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
>> Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |
>
> --
> Gerrit Imsieke
> GeschC$ftsfC<hrer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
>
> GeschC$ftsfC<hrer / Managing Directors:
> Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
>
>

================================================================
Deborah A Lapeyre		mailto:dalapeyre@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.	http://www.mulberrytech.com
Rockville, MD 20851		Phone: 301-315-9631 (USA)
----------------------------------------------------------------
Mulberry Technologies: Consultancy for XML, XSLT, and Schematron
================================================================