Re: [jats-list] Confirming STS metadata cardinality

["G. Ken Holman g.ken.holman@xxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Thanks, Bruce! I don't see this note in the JATS archives.

But, unfortunately, it doesn't answer the nut of my question.

I am aware that <std-meta> effectively replaces
<iso-meta>, <reg-meta>, and <nat-meta> when used
in adoption layers, and is nicely neutral. And
that the three amigos are deprecated. Not a problem.

But my question is in regard to the cardinality
of <std-meta> (and, indirectly, the others).
Could you please take a moment to re-read my original post?

The schema allows <std-meta> to be repeatable,
but I think that is an artefact of the
declaration mechanism used in lieu of the RELAX-NG concept of interleave.

Is it semantically correct for any given layer of
a NISO-STS document to have more than one <std-meta> element?

Sorry to be nit-picky, but I'm facing issues
regarding the answer to this nuanced question.

Thanks, again!

. . . . . . Ken

At 2023-06-29 20:51 +0000, Rosenblum, Bruce wrote:
> Ken: I sent this message a few weeks ago. Not sure where it got lost. Bruce
>
> ==================
>
> Hi Ken,
>
> Historically (meaning ISO STS 1.1) the DTD had
> <iso-meta> <reg-meta> or <nat-meta>. However ISO
> STS was originally designed to be used only by
> ISO network members. Once the standard moved to
> NISO, we added the more neutral <std-meta>,
> which is not meant for any specific organization
> and can be used by all organizations. So you can
> model all standards and one or more adoptions
> using <std-meta> and not use the original meta
> elements at all. However a mandate for NISO STS
> was backwards compatibility with ISO STS 1.1 and
> so the elements are still present.
>
> Should the standing committee decide in the
> future to create NISO STS 2.0 that is not
> backwards compatible with NISO STS 1.x, it would
> be my personal opinion that the original 3 elements should be deprecated.
>
> Bruce
>
> Bruce Rosenblum
>
> VP Content and Workflow Solutions
>
> Massachusetts, USA
>
> Mon-Fri, 11:00am-7:00pm Eastern (US & Canada)
>
> From: G. Ken Holman g.ken.holman@xxxxxxxxx
> <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, June 29, 2023 4:32 PM
> To: jats-list@xxxxxxxxxxxxxxxxxxxxxx <jats-list@xxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [jats-list] Confirming STS metadata cardinality
>
> b       This is an external email.
>
>
> Hello, again, everyone.
>
> 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://urldefense.com/v3/__https://www.niso-s
ts.org/TagLibrary/niso-sts-TL-1-2-html/element/front.html__;!!N11eV2iwtfs!usR
aaKroAh2tfw6h51JgDm3qqb6WFROKUWvc3GXUAsrUp4eYh9ti5KWdfCuSbZHgWDgkIocYdcxXDJF_
X_iRT1aQAhf_vhuP$>https://urldefense.com/v3/__https://www.niso-sts.org/TagLib
rary/niso-sts-TL-1-2-html/element/front.html__;!!N11eV2iwtfs!usRaaKroAh2tfw6h
51JgDm3qqb6WFROKUWvc3GXUAsrUp4eYh9ti5KWdfCuSbZHgWDgkIocYdcxXDJF_X_iRT1aQAhf_v
huP$
> >
> >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 |