OJS DTD questions

Are you responsible for making OJS work -- installing, upgrading, migrating or troubleshooting? Do you think you've found a bug? Post in this forum.

Moderators: jmacgreg, btbell, michael, bdgregg, barbarah, asmecher

Forum rules
The Public Knowledge Project Support Forum is moving to http://forum.pkp.sfu.ca

This forum will be maintained permanently as an archived historical resource, but all new questions should be added to the new forum. Questions will no longer be monitored on this old forum after March 30, 2015.
Posts: 23
Joined: Thu Jun 15, 2006 7:23 pm

OJS DTD questions

Postby Scott » Tue May 08, 2007 11:04 pm


We're currently working on an experimental project to look at archiving and publishing journals from repositories. The context of this work is to investigate the archiving and delivery of journals from repositories, which may be useful when journal finishes, journal software is decommissioned, or where an institution may wish to manage their publication process through software (such as OJS) but deposit published journals in the repository for storage and access. In scope for this project are OJS journals, and the DSpace and Fedora repository software. As part of this project the National Library of Australia (NLA) is developing a journal METS profile which we are using as a common format to be accepted by the DSpace and Fedora repositories. The intention is that this profile will be registered on the METS site and thus available for anyone to make use of.

As part of the METS profile work a mapping from the OJS DTD to METS and MODS was undertaken. However there are some elements and attributes we seek clarification on to assist in this process. I'd really appreciate it if you could provide answers/comments on the following:
1) intent of description in issue and supplemental file - presumably just a free-form description of each?
2) open_access - presumably just a flag, if element is present the article or issue has no access rights attached?
3) public_id attribute
4) access_date - is this the date last accessed, date restricted access was lifted, or something else?
5) abbrev - what is the intent of this, are there any guidelines for the contents of this element?
6) within the indexing element, can you explain the intent for the discipline, type, subject and subject_class elements? (e.g. does subject_class indicate a controlled vocab)
7) the intent of the sample element?
8) the label element - is this just for holding a user's text against a file (e.g. PDF, HTML)
9) intent of the source element
10) in the DTD it states that "Dates should be specified as YYYY-MM-DD" - is this actually enforced via the UI or can any date value be handled?


Site Admin
Posts: 304
Joined: Fri Mar 26, 2004 9:32 am
Location: Toronto, Canada

re: OJS DTD questions

Postby mj » Wed May 09, 2007 9:09 am

Hi Scott,

I'm glad to see that someone is developing a METS profile for OJS metadata -- one of the things we want to help achieve with OJS is allowing easy export of journal metadata to various standardized schemas.

I actually developed an "OJS application profile" for part of my Masters work this spring, with the intent of standardizing the fields in a way that would facilitate development of mappings (crosswalks) between schemas. I based it on qualified Dublin Core, but one of the things I didn't get far enough to do was to hold it up against something like METS. I'm happy to share the report, if you're interested, and would warmly welcome any feedback based on your experiences with OJS metadata and METS.

Here is my attempt to clarify the definitions of the fields you list - however, Alec Smecher, who developed the original fields, may have better insight than I, so he may be able to clarify a bit better:

1) "description" fields (including for issue and supplemental files) are free-text fields.

2) "open_access" is indeed a flag; its existence indicates that an issue is currently available in an "open access" fashion.

3) "public_id" is a bit of a catch-all; it is intended to provide a free-text field for a "friendly" ID: for some journals this is something like "e25", but there are no constraints on the format.

4) "access_date" is identical to date_published; that is, the date the issue was published regardless of access policy. i think you've identified a bug, or at least a limitation, in the native export plugin here.

5) "abbrev" is a free-text field which contains the abbreviated name of a section; eg. for "Articles" this is usually "ART", likewise for "Reviews" it may be "REV", etc.

6) indexing is a bit difficult, and the subject of some discussion (see more discussion below). the "short" answer is that these are all free-text fields, and do not necessarily correlate with a controlled vocabulary, although in theory they could use terms from one or more.

"discipline" is typically a delimited (comma or semicolon) list of academic fields that pertain to the article, eg. sociology; feminist study, etc.

"subject_class" is currently a placeholder for a link (URI) to a classification scheme that is to be used for the subject field. in this respect, it could be used to point to a controlled vocabulary that's used, but again this is not strongly defined at the moment.

"subject", like discipline, is typically a delimited list of indexing terms to describe the article, eg. behaviour change; adherence; alcohol

7) "sample" is a free-text field which describes the coverage, ie. to clarify the geographical or chronological coverage elements if/as necessary.

8) "label" is, as you describe, a free-text for describing the different galleys for an article (e.g. PDF, HTML).

9) "source" is a free-text field intended to identify the source of data contained in a supplementary file; that is, the name of the study or organization that provided the data.

10) dates are automatically formatted into YYYY-MM-DD during the export process. it uses PHP's strtotime() function which "expects to be given a string containing a US English date format" - in practice, this works for most conceivable formats.

Some additional notes as they relate to OJS metadata:

- access rights are something which we need to clarify a bit further in OJS; specifically, the delineation between copyright and access rights and the granularity of each.

- indexing functionality, including linking to and enforcing controlled vocabularies, are an area of discussion (and personal interest) within OJS. at present, we give freedom to the authors and editors to populate them as they like, but in a future version I would like to develop some plugin mechanism to use Z39.50 portals or similar for embedding controlled vocabularies. there is particular benefit for, eg. journals indexed in MEDLINE to already be using the same terms as the indexers.

- we are currently working on a much more flexible structure for assigning metadata to articles in OJS. it hasn't been determined (to my knowledge, at least) whether this will be ready for the release of OJS 2.2, but it is something of a priority.

Hope this clarifies your situation. Please don't hesitate if you have any further questions.

MJ Suhonos
OJS Development Team

Posts: 23
Joined: Thu Jun 15, 2006 7:23 pm

re: OJS DTD questions

Postby Scott » Wed May 09, 2007 10:38 pm

Hi MJ,

Thanks heaps for the info, I've passed it onto the metadata person.

I'd be interested in having a read of your report, so I'll drop you a PM with my contact details. Just for your reference I can also drop you a sample OJS issue marked up in METS if you send me your email (doesn't look like I can use attachments in the forum). It's work in progress but it may be useful, and we're not far off completion


Return to “OJS Technical Support”

Who is online

Users browsing this forum: No registered users and 1 guest