Jeffrey Beck
National Center for Biotechnology Information, National Library of Medicine, US National Institutes of Health
beck@ncbi.nlm.nih.gov
Presented at JATS-Con 2012, October 17, 2012
"May I please have a fork and a spoon?"
"Here you go."
"?"
:)
"? ? ?"
:)
and ate my chicken and parfait.
And I havn't stopped talking about it after all of these years.
Until I thought about it some more.
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| Something to eat chicken and parfait with |
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| Something to eat chicken and parfait with |
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| Something to eat chicken and parfait with | Make $$$$$$$ |
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| Something to eat chicken and parfait with | Make $$$$$$$ |
| My Needs | KFC's Needs |
|---|---|
| A fork and spoon | Make customer happy |
| Something to eat chicken and parfait with | Make $$$$$$$ |
| Don't make customer too unhappy. |
Spread over all KFCs in the country is a large savings.
KFC saves ~1 jillion dollars per year (some dollar figures have been approximated)
Some idiot executive at KFC got a huge bonus for this.
They did it all with JATS, of course.
Message from Bendte Fagge, Duke University Press, earlier this year.
"Our online vendor does not provide great support for display of the <bio>
element. Our vendor suggested that we use the element <author-notes>, but
I feel that the content we want to place in <bio> fits the definition of
the <bio> element better than the <author-notes> element. (We mainly
publish humanities journals that contain author bios.)
"So, our vendor suggested that we place the <bio> tag within <back>.
However, it seems like it would be best to keep the <bio> element within
<contrib>, especially for multiple authors.
"If we do end up placing <bio> within <back>, I'm wondering if it would be
wise to use the id and rid attributes to connect a <contrib> to a <bio>
since we often have multiple contributors.
"I was wondering if anyone else has experienced this and what advice you
might have about making tagging decisions."
| Bendte's Needs | Vendor's Needs |
|---|---|
| Tag articles completely and properly | Make customer happy |
| Bendte's Needs | Vendor's Needs |
|---|---|
| Tag articles completely and properly | Make customer happy |
| Make (or save) $$$$$ |
| Bendte's Needs | Vendor's Needs |
|---|---|
| Tag articles completely and properly | Make customer happy |
| Make (or save) $$$$$ | |
| Tag articles so they will work and I don't have to worry about them anymore | Make customer not too unhappy |
She's been sporked.
"Do it this way. We already know how to do it like that and have software written for it.
"And it will make you not too unhappy."
There are a lot of people and groups out there telling you how to tag your content.
I'm not saying don't listen to these people.
But sometimes "Tag it this way and it will work" means "Tag it this way and it will work in my system and I won't have to do anything extra to make it work."
Maybe that's ok ... and maybe not
Tagging decisions are always a dialog. Make sure you understand the needs driving both sides of the choice.
You need to decide what is best for your content.
Your content is a commodity.
It is worth it to get it right.
Don't get sporked.
"The first general advice I would give about making tagging decisions is don't throw away any information if you don't have to. And I would consider which <bio> goes with which <contrib> to be important information.
"Using an ID/IDREF between <contrib> and <bio> will make them just as related (or relatable) as if <bio> was a child of <contrib>.
"I'd suggest that if your vendor can handle <bio> in the <back> and display them in a way that you are satisfied with (including moving where you want them wrt the displayed contribs or at least building a link), you are safe to not insist on <bio> being a child of <contrib>."
"I would add to what Jeff says that (just speaking personally here) I am sorry whenever I hear about vendor requirements such as this driving tagging decisions.
"I mean, I understand why it happens and I'm sympathetic. (Nor would I presume to second-guess what is essentially a business decision.) Yet on the other hand, the whole idea of tagging in XML is so that the format of your data is not forever locked into the particular requirements of one of the many applications to which it may be given over its lifetime.
"In this case, if the vendor really can't manipulate the data on their end (given an ID/IDREF relation, a simple transformation can move a bio from front matter to back or the other way again), it might be worth considering whether you couldn't maintain the data the way you want, in an arrangement optimized for your own processes, and run it through such a filter to rearrange it to the vendor's requirements for delivery to them.
"I admit that (a) this might be a lot to take on for something so minimal as this, and also (b) that it can get complicated, for example if your interchange with your vendor goes both ways.
"Yet the underlying idea remains -- and is what gives bone and muscle to Jeff's principle that you should tag it as "what it is". Plus, the fact that such transformations become easier to engineer after the first one -- while also making hitherto impractical things possible and even easy (such as -- oops! -- evolving to new vendor requirements without upsetting your own systems?) -- is a big part of what rewards the investment in this knowhow, as in the XML source code itself.
"Just $0.02 from me, in no official capacity whatsoever. :-)"