Re: [jats-list] Confirming STS metadata cardinality

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

Thank you, Gerrit!

On my users I will impose a mandatory cardinality of one of 
std-org/std-org-abbrev, std-org-group/std-org/std-org-abbrev, and 
std-ident/originator (in that order) in order to satisfy an 
originator= link end.

. . . . . . Ken

At 2023-06-29 22:47 +0000, Imsieke, Gerrit, le-tex 
gerrit.imsieke@xxxxxxxxx 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 "ASME"." 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 |