KBART 5.3.2: data fields

kbart_logo_small.png

5.3.2.2 Publication title


Give the full name of the publication, for example, as it appears on the print
edition or on its web homepage. Special characters should be encoded using the
UTF-8 character set. Abbreviations should be avoided. 


Leading articles in a title should be included; for instance, “The Holocene” should
be listed as “The Holocene” in its complete official form, not “Holocene”.


Previous titles of the journal should be listed as separate entries, with their own
set of coverage dates corresponding to the period of time in which that title was
used. Knowledge base developers should then ensure appropriate matching
between related titles.


Collection titles should not be given as individual titles within metadata files. Any
collections of titles (packages) should be sent as a separate file with the
collection name identified in the filename.


 

5.3.2.3 Print-format Identifier (e.g., ISSN, ISBN, etc.)


Provide the content’s standard identifier. Initially, this will likely be the ISSN
(presented with all 9 characters, including the hyphen and the check digit) or
ISBN (either ISBN-10 or ISBN-13, as available; link resolvers can convert as
necessary). In the future, this may include the ISMN, ISAN, and others.


In cases where multiple ISSN or ISBNs exist for the title, only the print-format
ISSN or ISBN should be used in this field.


 

5.3.2.4 Online-format identifier (e.g., eISSN, eISBN, etc.)


In cases where identifiers for electronic formats have been created for the title,
they should be included in this field.


 

5.3.2.5 Date of first issue available online


For journals, this field should include the date of the first issue available online, in
the format YYYY-MM-DD. Use only those fields that apply; for example, if the
journal is annual, only YYYY should be used, whereas if the journal is monthly or
quarterly, only YYYY-MM should be used. Only in cases where issues of the
journal have specified cover dates including the day should YYYY-MM-DD be
used.


For books, the publication date should be given in the format YYYY-MM-DD.
Again, use only those fields which are specifically given in the book’s publication
date.


The ISO 8601 date format should be used for all dates.


 

5.3.2.6 Number of first volume available online


For journals, give the volume number of the first issue in this field. Do not include
any labels (e.g., “vol.” or “v.”). Try to reflect the house style for citing content, and
give an alphanumeric value in this field if appropriate.


Knowledge base developers should use an equivalent logic to normalize this
data and the data provided in OpenURL queries to maximize the likelihood of a
citation being matched to a source.


For books, leave this field blank.


 

5.3.2.7 Number of first issue available online


For journals, give the issue number of the first issue. Do not include any labels
(e.g., “no.” or “n.”). Do not include supplement or part values. You should try to
reflect the house style for citing your content, and may give an alphanumeric
value in this field if appropriate.


Knowledge base developers should use an equivalent logic to normalize this
data and the data provided in OpenURL queries to maximize the likelihood of a
citation being matched to a source.


For books, leave this field blank.


 

5.3.2.8 Date of last issue available online (or blank, if coverage is to present)


For journals, indicate the date of the most recent issue available. Again, use only
those fields which are specifically given in the journal’s cover date.


For journals, this field will be left blank if the journal is available “to the present”.


For monographs, this field will always be blank.


 

5.3.2.9 Number of last volume available online (or blank, if coverage is to
present)


For journals, the volume number of the latest issue should be given in this field.
Do not include any labels (e.g., “vol.” or “v.”). You should try to reflect the house
style for citing your content, and may give an alphanumeric value in this field if
appropriate.


Knowledge base developers should use an equivalent logic to normalize this
data and the data provided in OpenURL queries to maximize the likelihood of a
citation being matched to a source.


For journals, this field will be left blank if the journal is available “to the present”.


For books, leave this field blank.


 

5.3.2.10 Number of last issue available online (or blank, if coverage is to present)


For journals, give the issue number of the latest issue. Do not include any labels
(e.g., “no.” or “n.”). Do not include supplement or part values. You should try to
reflect the house style for citing your content, and may give an alphanumeric
value in this field if appropriate.


Knowledge base developers should use an equivalent logic to normalize this
data and the data provided in OpenURL queries to maximize the likelihood of a
citation being matched to a source.


For journals, this field will be left blank if the journal is available “to the present”.


For books, leave this field blank.


 

5.3.2.11 Title-level URL


Indicate the URL of the title’s homepage. For journals, this page should be a
listing of the available volumes and issues. For books, this page should be a
table of contents.


 

5.3.2.12 First author (for monographs)


For books, give the last name of the book’s first author.


For journals, leave this field blank.


 

5.3.2.13 Title ID


Give the proprietary identifier for the content title, if you use a Title ID to create
links to content. If more than one identifier exists, then supply the Title ID used
for linking. If outside parties will not need to know or use your proprietary
identifiers, or if no proprietary identifiers exist, this field may be left blank, but it
would be preferable to include a titleID if one exists.


 

5.3.2.14 Embargo


The embargo field reflects limitations on when resources become available
online, generally as a result of contractual limitations established between the
publisher and the content provider. Presenting this information to librarians
(usually via link resolver owners) is vital to ensure that link resolvers do not
generate links to content that is not yet available for users to access.


One of the biggest problems facing members of this supply chain is that multiple
kinds of embargoes exist—in some cases, coverage “to one year ago” means
that data from 365 days ago becomes available today, while in other cases it
means that the item is not available until the end of the current calendar year.


Because of the complexities of embargoes, we recommend that the ISO 8601
date syntax should be used. This is flexible enough to allow multiple types of
embargoes to be described.


The following method for specifying embargoes is derived from the ISO 8601
“duration syntax” standard, making a few additional distinctions not covered in
the standard. The embargo statement has three parts: type, length, and units.
These three parts are written in that order in a single string with no spaces.


  • Type: All embargoes involve a “moving wall”, a point in time expressed relative to
    the present (e.g., “12 months ago”). If access to the journal begins at the moving
    wall, the embargo type is “R”. If access ends at the moving wall, then the
    embargo type is “P”.

  • Length: An integer expressing the length of the embargo

  • Units: The units for the number in the “length” field: “D” for days, “M” for months,
    and “Y” for years. For simplicity, “365D” will always be equivalent to one year,
    and “30D” will always be equivalent to one month, even in leap years and months
    that do not have 30 days.


The “units” field also indicates the granularity of the embargo, that is, how
frequently the moving wall “moves”. For example, a newspaper database may
have a subscription model that gives customers access to exactly one year of
past content. Each day, a new issue is added, and the issue that was published
exactly one year ago that day is removed from the customer’s access. In this
case, the embargo statement would be “R365D”, because the date of the earliest
accessible issue changes each day.


Another journal may have a model that gives access to all issues in the current
year, starting in January. The following January, the customer loses access to all
of the previous year’s issues at once, and will only be able to access issues
published in the current year. In this case, we would say that the customer has
access to one “calendar year” of content. The embargo statement would be
“R1Y”, because the date of the earliest issue changes once a year.


Below are some common embargoes expressed according to this syntax:

  • Access to all content, except the current calendar year: P1Y
  • Access to all content in the previous and current calendar years: R2Y
  • Access to all content from exactly 6 months ago to the present: R180D
  • Access to all content, except the past 6 calendar months: P6M


In the case where there is an embargo at both the beginning and end of a
coverage range, then two embargo statements should be concatenated, the
starting embargo coming first. The two statements should be separated by a
semicolon. For example, “R10Y;P30D” describes an archive in which the past 10
calendar years of content are available, except for the most current 30 days.


 

5.3.2.15 Coverage depth


This field will indicate the extent to which content is covered within the range
given in the coverage and embargo fields. It can have one of three values:

  • fulltext: Indicates that the full text of articles is available. If the full text
    does not match the print equivalent, the “coverage notes” field can
    describe what is excluded (e.g., “excludes graphics”)
  • selected articles: Coverage includes the full text of some, but not all
    articles. The specifics of the coverage policy may be indicated in the
    “coverage notes” field.
  • abstracts: Coverage includes only abstracts of articles.


“Selected articles” should be used in this field only if a significant number of
articles are omitted, perhaps as a result of specific policy. For example, a
particular journal may only publish research articles online, and not letters or
book reviews. Other databases may only include articles in certain subject areas.
That policy should be described in the “coverage notes” field. The coverage
depth should not be set to “selected articles” in cases where only a few articles
are missing due to technical issues.


The above coverage depth values can be used in combination with a semicolon
to delimit values. For example, if coverage of a journal includes only abstracts of
selected articles (e.g., as may occur in A&I databases), this field would include
“abstracts; selected articles”. A topic-oriented full-text product would be
designated as: “selected articles”.


 

5.3.2.16 Coverage notes


This is an optional free-text field that may be supplied if the coverage depth used
requires further explanation. This field is used to describe the specifics of the
coverage policy, for example, “Excludes letters and book reviews”.


This field can be displayed verbatim in the link resolver results set so that end
users can identify exclusions in content.