2007 on Crossref

On Google Knol

Crossref — Fri, 14 Dec 2007 00:00:00 +0000

The recently discussed (announced?) Google Knol project could make Google Scholar look like a tiny blip in the the scholarly publishing landscape.

I love the comment an authority:

“Books have authors’ names right on the cover, news articles have bylines, scientific articles always have authors — but somehow the web evolved without a strong standard to keep authors names highlighted. We believe that knowing who wrote what will significantly help users make better use of web content.”

And so I suppose this means they are assigning author identifiers….

Zotero and the IA

Ed Pentz — Fri, 14 Dec 2007 00:00:00 +0000

Dan Cohen at Zotero reports (Zotero and the Internet Archive Join Forces) on a very interesting tie up that will allow researchers using Zotero to deposit content in the Internet Archive and have OCR done on scanned material for free under a two year Mellon grant. Each piece of content will be given a “permanent URI that includes a time and date stamp in addition to the URL” ( would Handle or DOI add value here?) and be part of Zotero Commons (things can also be kept private within a group).

Zotero Commons is related to but different from Nature Precedings and WebCite in that it’s intended focus is on public domain stuff on researchers hard drives rather than someone else’s material or website that is cited (WebCite) or preprints, datasets, technical reports that are given at least an initial screening (Nature Precedings).

STM Innovations 2007

Ed Pentz — Mon, 10 Dec 2007 00:00:00 +0000

After a busy Online Information conference, Friday was the STM Innovations Meeting in London (presentations not online yet). There was a very nice selection of tea which helped get the morning off to a good start.

Patricia Seybold kicked off with a review of Web 2.0 that mentioned lots of sites and some good case studies:

Alexander Street Press (https://alexanderstreet.com/) - user tags combined with a taxonomy.

Slideshare (http://www.slideshare.net) - share presentations

Threadless (http://www.threadless.com/) - design and vote on t-shirts

The most interesting parts of the talk were the case studies of how National Instruments and Staples have built a vibrant community of customers. Staples invited top purchasers on the their site to create product categories and sales went up 30% and now they use the categorization in physical stores and customer reviews from the web are used in stores.

NI has a whole suite of tools that allow customers to build products and get their jobs done (using NI products and services).

Five steps to Web 2.0 success –

Focus on findability
Solicit sutomers’ reviews, ratings and opinions
Empower users to classify and organize content
Nurture community, social networks, communities of practice
Get lead users to strut their stuff, using your IP to build their IP

The most useful part came in the questions when Geoffrey Bilder asked about “astroturfing” - this is a problem for Web 2.0. Interestingly, the NI and Staples examples are closed communities and other sites have to have moderators to try and track this stuff down. Often you don’t hear about these types of issues amid the web 2.0 boosterism.

Joris van Rossum gave an very good overview of Scirus’ wiki-based Topic Pages (https://web.archive.org/web/20071231210906/http://topics.scirus.com/). It’s interesting to see the creative way Elsevier is experimenting. Joris said that it is Elsevier’s vision that wiki forms a promising topic-centered platform for informal collaboration and the sharing of highly relevant info within STM in addition to the traditional peer-reviewed system. There is a critical issuem though - will researchers go to publishers for this type of thing or will they self-organize using inexpensive tools? The danger here is that publishers will do their own thing leading to a replay of the portal craze in the late 90s.

Geoffrey Bilder gave a very good talk entitled “Anonymous Bosh: Attribution in a Mashed-up World” about trust and CrossReg (contributor ID).

Simon Willison gave a very good explanation and update on OpenID. Some resources for more information - http://openid.net

http://www.openidenabled.com

https://web.archive.org/web/20070715235636/http://simonwillison.net/tags/openid/

Mark Bide wrapped things up with an update on ACAP (https://web.archive.org/web/20071019045302/http://www.the-acap.org/)- “an evolving, open, royalty-free standard for expression of permissions in machine readable form” - that was launched in November. Will the search engines pay any attention?

Overall, the day was very thought provoking.

Search Web Services Document

Tony Hammond — Fri, 09 Nov 2007 00:00:00 +0000

The OASIS Search Web Services TC has just put out the following document for public review (Nov 7- Dec 7, 2007):

_Search Web Services v1.0 Discussion Document

Editable Source: http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.doc

PDF: http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.pdf

HTML: http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.html

From the OASIS announcement:

“This document: “Search Web Services Version 1.0 - Discussion Document - 2 November 2007”, was prepared by the OASIS Search Web Services TC as a strawman proposal, for public review, intended to generate discussion and interest. It has no official status; it is not a Committee Draft. The specification is based on the SRU (Search Retrieve via URL) specification which can be found at http://www.loc.gov/standards/sru/. It is expected that this standard, when published, will deviate from SRU. How much it will deviate cannot be predicted at this time. The fact that the SRU spec is used as a starting point for development should not be cause for concern that this might be an effort to rubberstamp or fasttrack SRU. The committee hopes to preserve the useful features of SRU, eliminate those that are not considered useful, and add features that are not in SRU but are considered useful. “

DC in (X)HTML Meta/Links

Tony Hammond — Tue, 06 Nov 2007 00:00:00 +0000

This message posted out yesterday on the dc-general list (with following extract) may be of interest:

_“Public Comment on encoding specifications for Dublin Core metadata in HTML and XHTML

2007-11-05, Public Comment is being held from 5 November through 3 December 2007 on the DCMI Proposed Recommendation, “Expressing Dublin Core metadata using HTML/XHTML meta and link elements” «http://dublincore.org/documents/2007/11/05/dc-html/» by Pete Johnston and Andy Powell. Interested members of the public are invited to post comments to the DC-ARCHITECTURE mailing list «http://www.jiscmail.ac.uk/lists/dc-architecture.html» , including “[DC-HTML Public Comment]” in the subject line. Depending on comments received, the specification may be finalized after the comment period as a DCMI Recommendation.”

STIX Fonts in Beta

Tony Hammond — Tue, 06 Nov 2007 00:00:00 +0000

Well, Howard already blogged on Nascent last week about the STIX fonts (Scientific and Technical Information Exchange) being launched and now freely available in beta. And today the STM Association also have blogged this milestone mark. So, just for the record, I’m noting here on CrossTech those links for easy retrieval. As Howard says:

“I recommend all publishers download the fonts from the STIX web site at www.stixfonts.org today.”

(And for those who want to see more of Howard, he can be found in interview here on the SIIA Executive FaceTime Webcast Series. 🙂

DCMI Identifiers Community

Tony Hammond — Wed, 17 Oct 2007 00:00:00 +0000

Another DCMI invitation. And a list. Lovely.

See this message (copied below) from Douglas Campbell, National Library of New Zealand, to the dc-general mailing list.

(Continues)

_“Hi all,

I would like to alert members of this list to the new DCMI Identifiers Community established at the recent Dublin Core Metadata Initiative (DCMI) Advisory Board meeting in Singapore. It is moderated by Douglas Campbell (National Library of New Zealand).

The community is a forum for individuals and organisations with an interest in the design and use of identifiers in metadata. It also serves as a liaison channel for those involved in identifier efforts in other domains.

There was a lot of interest in identifiers at the recent DCMI conference. Identifiers are fundamental to the Web and for managing digital content, but most of us don’t know where to begin in designing and assigning them. The level of confusion can be seen in the number of meetings and workshops held just about identifiers. DCMI is in a unique position to bring together the thinking (and doing) around identifiers from multiple domains.

I would like to encourage you to share your identifier efforts and thinking amongst the DCMI community on our Identifiers wiki at:

http://dublincore.org/identifierswiki

You can join the community by signing up to our JISCMAIL list, linked from our community homepage at:

http://www.dublincore.org/groups/identifiers/

or by going direct to jiscmail:

http://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=dc-identifiers&A=1

Thanx,

Douglas”_

Hybrid

Tony Hammond — Wed, 17 Oct 2007 00:00:00 +0000

So, back on the old XMP tack. The simple vision from the XMP spec is that XMP packets are embedded in media files and transported along with them - and as such are relatively self-contained units, see Fig 1.

Fig. 1 - Media files with fully encapsulated descriptions.

But this is too simple. Some preliminary considerations lead us to to see why we might want to reference additional (i.e. external) sources of metadata from the original packet:

PDFs: PDFs are tightly structured and as such it can be difficult to write a new packet, or to update an existing packet. One solution proposed earlier is to embed a minimal packet which could then reference a more complete description in a standalone packet. (And in turn this standalone packet could reference additional sources of metadata.)
Images: While considerably simpler to write into web-delivery image formats (e.g. JPEG, GIF, PNG), it is the case that metadata pertinent to the image only is likely to be embedded. Also, of interest is the work from which the image is derived which is most likely to be presented externally to the image as a standalone document. (And in turn this standalone packet could reference additional sources of metadata.)

(Continues)

Thus the two cases - PDF documents and images - are not dissimilar. Fig. 2 shows a “wall-to-wall” XMP architecture whereby the standalone metadata documents for the work and for additional sources are expressed in XMP.

Fig. 2 - XMP “wall-to-wall” architecture.

Fig. 3 presents a variant on this theme whereby additional sources are presented as generic RDF/XML. (In the most general case only RDF need be assumed, the serialization being a matter of choice.)

Fig. 3 - XMP authority metadata with references to generic RDF/XML

And finally, Fig. 4 shows the most extreme case whereby XMP is used merely to “bootstrap” RDF descriptions for media objects. The XMP is used to embed a minimal description into the media file with references to a fuller work description and to additional sources which are presented as generic RDF/XML. That is, the metadata descriptions use generic RDF/XML exclusively and only resort to the idiomatic RDF/XML employed by XMP for embedding descriptions into binary structures.

Fig. 4 - XMP “bootstrap” only - metadata descriptions proper are generic RDF/XML.

If I were to choose I might opt for the scenario presented in Fig. 3, but the scenarios in both Figs. 2 and 4 leave room for thought. Such a hybrid solution may be a means to bridge two different concerns:

Generic RDF/XML for unconstrained descriptions.
- Idiomatic RDF/XML (aka XMP) for embedding the head of a metadata trail.
I’m not sure that I see the XMP spec loosening up any time soon to accommodate generic RDF/XML. Nor, likewise is XMP likely to be provided (or even tolerated) down the metadata trail. And the metadata is not going to be fully encapsulated within a media file. The media file will merely encapsulate the head of the metadata trail.

NLM Blog Citation Guidelines

Geoffrey Bilder — Mon, 15 Oct 2007 00:00:00 +0000

I’ve just returned from Frankfurt Book fair and noticed that there has been some recent in the The NLM Style Guide for Authors, Editors and Publishers recommendations concerning citing blogs.

Which reminds me of an issue that has periodically been raised here at Crossref- should we be doing something to try and provide a service for reliably citing more ephemeral content such as blogs, wikis, etc.?

Personally, I cringe when I see people include plain old URLs (POUs?) in citations. What’s the point? They are almost guaranteed to fail to resolve after a few years. In citing them, you are hardly helping to preserve the scholarly record. You might as well just record the metadata associated with the content.

So why don’t we simply allow individuals to assign DOIs to their content?

As Chuck Koscher says, “Crossref DOIs are only as persistent as Crossref staff.” Crossref depends on its ability to chase down and berate member publishers when they fail to update their DOI records. Its hard enough doing this with publishers, so just imagine what it would be like trying to chase down individuals. In short, it just wouldn’t scale.

But what if we provided a different service for more informal content? Recently we have been in talking with Gunther Eysenbach, the creator of the very cool WebCite service about whether Crossref could/should operate a citation caching service for ephemera.

As I said, I think WebCite is wonderful, but I do see a few problems with it in its current incarnation.

The first is that, the way it works now, it seems to effectively leech usage statistics away from the source of the content. If I have a blog entry that gets cited frequently, I certainly don’t want all the links (and their associated Google-juice) redirected away from my blog. As long as my blog is working, I want traffic coming to my copy of the content, not some cached copy of the content (gee- the same problem publishers face, no?). I would also, ideally, like that traffic to continue to come to to my blog if I move hosting providers, platforms (WordPress, Moveable Type) , blog conglomerates (Gawker, Weblogs, Inc.), etc.

The second issue I have with WebCite is simpler. I don’t really fancy having to actually recreate and run a web-caching infrastructure when there is already a formidable one in existence.

So what if we ran a service for individuals that worked like this:

For a fee, you can assign DOIs to your ephemeral, CC-licensed content.
When you assign a DOI to an item of content (or update an existing DOI), we will immediately archive said content with the Internet Archive (who, incidentally, charges for this service)
We will direct those DOIs to your web site as long as you are both:
Paying the fee
Updating your URLs to point to the correct content
If you fail in either “a” or “b”, we will then redirect said DOIs to the cached version of the content on the Internet Archive (after having warned you repeatedly via automated e-mail).

(Note, as an aside, that we could in theory provide a similar dark-archive service for publishers with non free content using something like JStore as the archive)

This approach would help to ensure that a blogger’s version of content was always linked to as long it was available. It would also preserve the “persistence” of Crossref DOIs by making sure that we could always resolve the DOI even if we were not able to get the owner of said DOI to update it.

So back to the NLM guidelines… On the one hand, I’m delighted to see that the NLM has issued guidelines on citing blogs. It seems glaringly obvious that informal (and ephemeral) content such as blogs and wikis are increasingly becoming vital parts of the scholarly record. On the other hand, it also seems to me that recommending that somebody “cite” with a broken pointer (i.e. a URL) to content verges on tokenism. This isn’t the NLM’s fault- there just isn’t a reliable mechanism for citing informal content in a manner that ensures you can then retrieve and look at said content in the future.

And this is no longer a problem confined to the Scholarly/Professional publishing space. As Jon Udell has occasionally pointed out, citation is increasingly an important currency for *any* professional writer on the web. It seems to me that a system for reliably citing blogs and wikis would benefit many communities. I could easily see commercial hosted Blog services (Blogger, WordPress) offering a “Cached-DOI” feature as a premium service to their clients.

So what do you think? What am I missing? is this something we should be looking at?

OpenDocument Adds RDF

Tony Hammond — Sun, 14 Oct 2007 00:00:00 +0000

Bruce D’Arcus left a comment here in which he linked to post of his: “OpenDocument’s New Metadata System“. Not everybody reads comments so I’m repeating it here. His post is worth reading on two counts:

He talks about the new metadata functionality for OpenDocument 1.2 which uses generic RDF. As he says:

> _&#8220;Unlike Microsoft’s custom schema support, we provide this through the standard model of RDF. What this means is that implementors can provide a generic metadata API in their applications, based on an open standard, most likely just using off-the-shelf code libraries.&#8221;_
This is great. It means that description is left up to the user rather than being restricted by any vendor limitation. (Ideally we would like to see the same for XMP. But Adobe is unlikely to budge because of the legacy code base and documents. It’s a wonder that Adobe still wants XMP to breathe.)
* He cites a wonderful passage from Rob Weir of IBM (something which I had been considering to blog but too late now) about the changing shape of documents. Can only say, go read [Bruce’s post][2] and then [Rob’s post][3]. But anyway a spoiler here:
> _&#8220;The concept of a document as being a single storage of data that lives in a single place, entire, self-contained and complete is nearing an end. A document is a stream, a thread in space and time, connected to other documents, containing other documents, contained in other documents, in multiple layers of meaning and in multiple dimensions.&#8221;_</ol>
I think the ODF initiative is fantastic and wish that Adobe could follow suit. However, I do still hold out something for XMP. After all, nobody else AFAICT is doing anything remotely similar for multimedia. Where’s the W3C and co. when you really need them? (Oh yeah, [faffing][4] about the new [Semantic Web logo][5]. 😉

I Want My XMP

Tony Hammond — Sat, 13 Oct 2007 00:00:00 +0000

Now, assuming XMP is a good idea - and I think on balance it is (as blogged earlier), why are we not seeing any metadata published in scholarly media files? The only drawbacks that occur to me are:

Hard to write - it’s too damn difficult, no tools support, etc.
- Hard to model - rigid, “simple” XMP data model, both complicates and constrains the RDF data model

Well, I don’t really believe that 1) is too difficult to overcome. A little focus and ingenuity should do the trick. I do, however, think 2) is just a crazy straitjacket that Adobe is forcing us all to wear but if we have to live with that then so be it. Better in Bedlam than without. (RSS 1.0 wasn’t so much better but allowed us to do some useful things. And that came from the RDF community itself.) We could argue this till the cows come home but I don’t see any chance of any change any time soon.

(Continues)

So, putting the RDF issue aside for the moment (as if RDF didn’t have problems of its own - XML, URI, etc.) let’s just look at the options for writing the stuff. (Btw, I’m not referencing any tools or toolkits. This is just in the round.) There are various means of publishing metadata in XMP:

 **Sidecar**
: XMP can be produced as standalone files - see [XMP Specification, (Sept. ’05)][3], p. 36. (These are called &#8220;sidecar&#8221; files if the file has the same name as the main document and is in the same directory.) The only things needed to produce these files are a text editor and a good grasp of the XMP serialization. A template will do for that. The main problem with a standalone file is that it does not travel with the media file and so risks being left behind.
Worth a note here. Not standalone as such but the [Mars][4] format (the draft XML formalization for PDF) discloses its metadata in an independent XMP file &#8220;metadata.xml&#8221; under the &#8220;META-INF/&#8221; directory. For distribution the whole directory structure is packaged up as a zip file and so the XMP is embedded in a &#8220;.mars&#8221; file, but accessed directly from the zip file or from the unpackaged directory the XMP can be manipulated just like any other XML document.
**Embedded**
: This is the normal means of distributing XMP - embedded within the media file. Some graphics formats are essentially linear (JPEG, PNG, GIF) and it is relatively straightforward to add in an XMP packet. Other formats (PDF, TIFF) have internal cross-referencing and are more difficult to deal with.
**Embedded + Sidecar**
: One possible method for dealing with the difficulty of writing XMP is to note that some media (especially PDFs) already have embedded XMP packets. As noted earlier, much if not all of the metadata in these XMP packets will be workflow-related and thus dispensible for final-form products where authority work-related metadata is desired. These packets may, or may not, be writeable and thus include additional padding whitespace. Even for read-only packets there is much (if not all) that can be discarded and also sometimes unnecesary bulk (e.g. default namespace declarations which are never used). _The bottom line is that any legacy XMP packet may typically be 2-3K in size and, just as in transplanting a cell nucleus, the XMP packet innards can be deftly substituted with a minimal XMP packet content, say 1K in size, which would be guaranteed to fit with suitable padding._ A packet that size would be sufficient to provide at minimum for a DOI and for a reference to additional metadata, e.g. a more complete standalone XMP packet. The two forms can coexist.
The third way option here allows embedding a minimal XMP packet into &#8220;difficult&#8221; packaging structures while pointing out to a fully-formed XMP packet. The &#8220;simple&#8221; packaging structures may both include a fully-formed XMP packet while also possibly referencing extended metadata sources as per my previous post [here][4].

Metadata - For the Record

Tony Hammond — Sat, 13 Oct 2007 00:00:00 +0000

Interesting post from Gunar Penikis of Adobe entitled “Permanent Metadata” Oct. ’04). ¹.

He talks about the the issues of embedding metadata in media and comes up with this:

“It may be the case that metadata in the file evolves to become a “cache of convenience” with the authoritative information living on a web service. The web service model is designed to provide the authentication and permissions needed. The link between the two provided by unique IDs. In fact, unique IDs are already created by Adobe applications and stored in the XMP - that is what the XMP Media Management properties are all about.”

An intriguing idea. Of course, Gunar’s (and Adobe’s) preoccupations with metadata revolve mainly around document workflow whereas, at least as things stand currently, scholarly publisher concerns are mainly with the dissemination of media in final form. Hence some differences in thinking:

Subject

As just noted Adobe are more interested in workflow than in work. Scholarly articles are rich in descriptive metadata about the work itself and have a well-developed ctation model. Academic interest is in the intellectual content rather than the vehicle used to carry and preserve that content - the file format.

Unique IDs

Workflow IDs are UUIDs which identify specific instances and expressions, but do not identify the abstract work. UUIDs provide a unique identifier but there is no central registry for such identifiers, hence they cannot be “looked up”. Crossref publishers should be concerned to associate closely the DOI for the underlying work with a given media file. That’s the identifier that this community is actively promoting.

Read/Write: Because of the focus on workflow, the XMP specification recommends that XMP packets be “writeable”, that is that they be marked as “writeable” and that they include padding whitespace which can accommodate updates without changing packet size. Publishers distributing final form documents are more likely to want to distribute “read-only” metadata which is authoritative and which describes the work, rather than the document format and workflow. Of course, this should not preclude additional sources of metadata which may be added “by reference” rather than “by value”. That is, a pointer to a web page (or service) may be sufficient to relate additional publisher terms and user annotations instead of embedding them directly in the file for various reasons: a) file integrity, b) limiting growth of file size, c) term authority, d) dynamic production (in forward time), and e) multiple sources.

Update Aug 2022: the blog post mentioned below was previously at blogs.adobe.com/gunar/2007/10/permanent_metadata.html but is no longer live. ↩︎

DataNet

Tony Hammond — Fri, 12 Oct 2007 00:00:00 +0000

Last week, my colleague Ian Mulvany posted on Nascent an entry about NSF’s recent call for proposals on DataNet (aka “A Sustainable Digital Data Preservation and Access Network”). Peter Brantley, of DLF, has set up a public group DataNet on Nature Network where all are welcome to join in the discussion on what NSF effectively are viewing as the challenge of dealing with “big data”. As Ian notes in a mail to me:

“It seems that for a fully integrated flow of data then publisher involvement is going to be required, and it is clear from the proposal that the NSF are also interested in rights management or at negotiating that issue.”

OTMI Applied - Means More Search Hits

Tony Hammond — Tue, 09 Oct 2007 00:00:00 +0000

(Click image to enlarge.)

Following up on previous posts on OTMI (the proposal from NPG for scholarly publishers to syndicate their full text to drive text-mining applications), Fabien Campagne from Cornell, a long-time OTMI supporter, has created an OTMI-driven search engine (based on his Twease work). This may be the first publicly accessible OTMI-based service. It currently only contains NPG content from the OTMI archive online - some 2 years worth of Nature and four other titles. (When will we begin to see other publishers on board?)

What’s happening here? Well, Twease is a web-based front-end to searching Medline abstracts. As such, a search will retrieve a set of results labeled by PMID and list all lines in the abstract where a match occurs. By contrast, with Twease-OTMI a search is run over the article full text and a will retrieve all text “snippets” (for Nature we use sentences, although other units of text are possible) which match. See the figure above where the top three results are all labeled by the same DOI and show text matches from various points within the document.

This shows that a far superior search match rate is possible using the article full text (as distributed in OTMI format) where text integrity as publishable asset is not compromised.

Mars Bar

Tony Hammond — Mon, 08 Oct 2007 00:00:00 +0000

Just noticed that there is now (as of last month) a blog for Mars (“Mars: Comments on PDF, Acrobat, XML, and the Mars file format”). See this from the initial post:

“The Mars Project at Adobe is aimed at creating an XML representation for PDF documents. We use a component-based model for representing different aspects of the document and we use the Universal Container Format (a Zip-based packaging format) to hold the pieces. Mars uses XML to represent the individual components where that makes sense, but otherwise uses industry standard formats to represent other components. Examples of these include Fonts (we use OpenType), Images (PNG, GIF, JPEG, JPEG2000), Color (ICC Color Profiles), etc.. We use SVG to represent page content, which fits as both an XML format and an industry standard.”

Scholarly DC

Tony Hammond — Fri, 05 Oct 2007 00:00:00 +0000

This This was just sent out to the DC-GENERAL mailing list about the new DCMI Community for Scholarly Communications. As Julie Allinson says:

“The aim of the group is to provide a central place for individuals and organisations to exchange information, knowledge and general discussion on issues relating to using Dublin Core for describing items of ‘scholarly communications’, be they research papers, conference presentations, images, data objects. With digital repositories of scholarly materials increasingly being established across the world, this group would like to offer a home for exploring the metadata issues faced.”

There’s also a DC-SCHOLAR mailing list (subscribe here). Not too much there yet, but it may be useful to track - or even to participate. 🙂

The Names Project

Tony Hammond — Fri, 05 Oct 2007 00:00:00 +0000

Was reminded to blog about this after reading Lorcan’s post on the Names Project being run by JISC. From the blurb:

_“The project is going to scope the requirements of UK institutional and subject repositories for a service that will reliably and uniquely identify names of individuals and institutions.

It will then go on to develop a prototype service which will test the various processes involved. This will include determining the data format, setting up an appropriate database, mapping data from different sources, populating the database with records and testing the use of the data.”_

One immediate project tangible is the landscape report (‘A review of the current landscape in relation to a proposed Name Authority Service for UK repositories of research outputs’) which summarizes some current initiatives in author identification from a UK perspective, including inter alia Elsevier’s Scopus Author Identifier.

InChIKey

Tony Hammond — Tue, 02 Oct 2007 00:00:00 +0000

The InChI (International Chemical Identifier from IUPAC) has been blogged earlier here. RSC have especially taken this on board in their Project Prospect and now routinely syndicate InChI identifiers in their RSS feeds as blogged here.

As reported variously last month (see here for one such review) IUPAC have now released a new (1.02beta) version of their software which allows hashed versions (fixed length 25-character) of the InChI, so-called InChIKey’s, to be generated which are much more search engine friendly. Compare a regular InChI identifier:

InChI=1/C49H70N14O11/c1-26(2)39(61-42(67)33(12-8-18-55 -49(52)53)57-41(66)32(50)23-38(51)65)45(70)58-34(20-29-1 4-16-31(64)17-15-29)43(68)62-40(27(3)4)46(71)59-35(22-30 -24-54-25-56-30)47(72)63-19-9-13-37(63)44(69)60-36(48(7 3)74)21-28-10-6-5-7-11-28/h5-7,10-11,14-17,24-27,32-3 7,39-40,64H,8-9,12-13,18-23,50H2,1-4H3,(H2,51,65)(H,54,56 )(H,57,66)(H,58,70)(H,59,71)(H,60,69)(H,61,67)(H,62,68)(H,73,74) (H4,52,53,55)/f/h56-62,73H,51-53H2

with its InChIKey counterpart:

InChIKey=JYPVVOOBQVVUQV-UHFFFAOYAR

That’s some saving.

Oh No, Not You Again!

Tony Hammond — Tue, 02 Oct 2007 00:00:00 +0000

Oh dear. Yesterday’s post “Using ISO URNs” was way off the mark. I don’t know. I thought that walk after lunch had cleared my mind. But apparently not. I guess I was fixing on eyeballing the result in RDF/N3 rather than the logic to arrive at that result.

(Continues.)

There are three namespace cases (and I was only wrong in two out of the three, I think):

“pdf:”

I was originally going to suggest the use of “data:” for the PDF information dictionary terms here but then lunged at using an HTTP URI (the URI of the page for the PDF Reference manual on the Adobe site) for regular orthodox conformancy and good churchgoing:

@prefix pdf: <http://www.adobe.com/devnet/pdf/pdf_reference.html> .

This was wrong on two counts:

a) Afaik no such use for this URI as a namespace has ever been made by Adobe. And it is in the gift of the DNS tenant (elsewhere called “owner”) to mint URIs under that namespace and to ascribe meanings to those URIs.

b) Also the URI is not best suited to a role as namespace URI since RDF namespaces typically end in “/” or “#” to make the division between namespace and term clearer. (In XML it doesn’t make a blind bit of difference as XML namespaces are just a scoping mechanism.) So to have a property URI as

http://www.adobe.com/devnet/pdf/pdf_reference.htmlAuthor

does the job but looks pretty rough and more importantly precludes (at least, complicates) the possibility of dereferencing the URI to return a page with human or machine readable semantics. Better in RDF terms is one of the following:

a) http://www.adobe.com/devnet/pdf/pdf_reference/Author
b) http://www.adobe.com/devnet/pdf/pdf_reference#Author
c) http://www.adobe.com/devnet/pdf/pdf_reference.html#Author

In the absence of any published namespace from Adobe for these terms, I think it would have been more prudent to fall back on “data:” URIs. So

@prefix pdf: <data:,> .

leading to

data:,Author
data:,CreationDate
data:,Creator
etc.

This is correct (afaict) and merely provides a URI representation for bare strings.

Had we wanted to relate those terms to the PDF Reference we might have tried something like:

data:,PDF%20Reference:Author
data:,PDF%20Reference:CreationDate
data:,PDF%20Reference:Creator
etc.

And if we had wanted to make those truly secondary RDF resources related to a primary RDF resource for the “namespace” we could have attempted something like:

data:,PDF%20Reference#Author
data:,PDF%20Reference#CreationDate
data:,PDF%20Reference#Creator
etc.

Note though that the “data:” specification is not clear about the implications of using “#”. (Is it allowed, or isn;t it?) We must suspect that it is not allowed, but see this mail from Chris Lilley (W3C) which is most insightful.

“pdfx:”

The example was just for demo purposes, but (as per 1a above) it is incumbent on the namespace authority (here ISO) to publish a URI for the term to be used. Anyhow, the namespace URI I cited

@prefix pdfx: <urn:iso:std:iso-iec:15930:-1:2001> .

would not have been correct and would have led to these mangled URIs:

urn:iso:std:iso-iec:15930:-1:2001GTS_PDFXVersion
urn:iso:std:iso-iec:15930:-1:2001GTS_PDFXConformance

It should have been something closer to

@prefix pdfx: <urn:iso:std:iso-iec:15930:-1:2001:> .

leading to

urn:iso:std:iso-iec:15930:-1:2001:GTS_PDFXVersion
urn:iso:std:iso-iec:15930:-1:2001:GTS_PDFXConformance

“_usr:”

This was the one correct call in yesterday’s post.

@prefix _usr: <data:,> .

The only problem here would be to differentiate these terms from the terms listed in the PDF Reference manual, although the PDF information dictionary makes no such distinction itself.

To sum up, perhaps the best way of rendering the PDF information dictionary keys in RDF would be to use “data:” URIs for all (i.e. a methodology for URI-ifying strings) and to bear in mind that at some point ISO might publish URNs for the PDF/X mandated keys: ‘GTS_PDFXVersion‘ and ‘GTS_PDFXConformance‘. So,

# document infodict (object 58: 476983):
@prefix: pdfx: <data:,> .
@prefix: pdf: <data:,> .
@prefix: _usr: <data:,> .
<> _usr:Apag_PDFX_Checkup "1.3";
pdf:Author "Scott B. Tully";
pdf:CreationDate "D:20020320135641Z";
pdf:Creator "Unknown";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
pdf:Keywords "PDF/X-1";
pdf:ModDate "D:20041014121049+10'00'";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdf:Subject "A document from our PDF archive. ";
pdf:Title "Tully Talk November 2001";
pdf:Trapped "False" .

Using ISO URNs

Tony Hammond — Mon, 01 Oct 2007 00:00:00 +0000

(Update - 2007.10.02: Just realized that there were some serious flaws in the post below regarding publication and form of namespace URIs which I’ve now addressed in a subsequent post here.)

By way of experimenting with a use case for ISO URNs, below is a listing of the document metadata for an arbitrary PDF. (You can judge for yourselves whether the metadata disclosed here is sufficient to describe the document.) Here, the metadata is taken from the information dictionary and from the document metadata stream (XMP packet).

The metadata is expressed in RDF/N3. That may not be a surprise for the XMP packet which is serialized in RDF/XML, as it’s just a hop, skip and a jump to render it as RDF/N3 with properties taken from schema whose namespaces are identified by URI. What may be more unusual is to see the document information dictionary metadata (the “normal” metadata in a PDF) rendered as RDF/N3 since the information dictionary is not nodelled on RDF, not expressed in XML, and not namespaced. Here, in addition to the trusty HTTP URI scheme, I’ve made use of two particular URI schemes: “iso:” URN namespaces, and “data:” URIs.

(Continues.)

As far as I am aware, there is no formal identifier for entries in the document information dictionary as specified by the PDF Reference from Adobe Systems, so it may be appropriate to use the HTTP URI for the Adobe homepage for the PDF Reference manual, from which specific editions are available.

For the PDF/X keys which are specified in the ISO standard ISO 15930-1 2001, I have used an ISO URN. (I don’t expect this to be correct in all details but it should give some idea of how it might be used. It may be that the URI should express the term itself, rather than the document from which the term was defined.) And finally, for the one additional user-supplied key here I have made use of a “data:” URI with no body (i.e. I’m speechless). One could have provided some text within the body of the “data:” URI if one wanted to differentiate between alternate user keys or to otherwise annotate these keys.

Note that the prefixes used in the information dictionary and in the metadata stream are unrelated, as are the mappings of property elements to schemas.

Well, that’s all really just for fun but it may show two things: 1) how a general description might be described with RDF and how general properties can be mapped to URIs (with possibly limited machine utility), and 2) how an ISO URN might be used.

# document infodict (object 58: 476983):
@prefix: pdfx: <urn:iso:std:iso-iec:15930:-1:2001> .
@prefix: pdf: <http://www.adobe.com/devnet/pdf/pdf_reference.html> .
@prefix: _usr: <data:,> .
<> _usr:Apag_PDFX_Checkup "1.3";
pdf:Author "Scott B. Tully";
pdf:CreationDate "D:20020320135641Z";
pdf:Creator "Unknown";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
pdf:Keywords "PDF/X-1";
pdf:ModDate "D:20041014121049+10'00'";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdf:Subject "A document from our PDF archive. ";
pdf:Title "Tully Talk November 2001";
pdf:Trapped "False" .
# document metadata stream (object 41: 472418):
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix pdf: <http://ns.adobe.com/pdf/1.3/> .
@prefix pdfx: <http://ns.adobe.com/pdfx/1.3/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpMM: <http://ns.adobe.com/xap/1.0/mm/> .
<> pdf:Keywords "PDF/X-1";
pdf:Producer "Acrobat Distiller 4.05 for Macintosh";
pdfx:Apag_PDFX_Checkup "1.3";
pdfx:GTS_PDFXConformance "PDF/X-1a:2001";
pdfx:GTS_PDFXVersion "PDF/X-1:2001";
xmp:CreateDate "2002-03-20T13:56:41Z";
xmp:CreatorTool "Unknown";
xmp:MetadataDate "2004-10-14T12:10:49+10:00";
xmp:ModifyDate "2004-10-14T12:10:49+10:00";
xmpMM:DocumentID "uuid:bd7ae9a1-1110-43c0-8e84-632f2dbb55ab";
dc:creator [
a rdf:Seq;
rdf:_1 "Scott B. Tully" ];
dc:description [
a rdf:Alt;
rdf:_1 "A document from our PDF archive. "@x-default ];
dc:format "application/pdf";
dc:title [
a rdf:Alt;
rdf:_1 "Tully Talk November 2001"@x-default ] .

Whole Lotta ID

Tony Hammond — Mon, 01 Oct 2007 00:00:00 +0000

ISO has registered with the IANA a URN namespace identifier (“iso:”) for ISO persistent resources. From the Internet-Draft:

“This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources).”

The toplevel grammar rules (ABNF) give some indication of scope:

NSS = std-nss

std-nss = “std:” docidentifier *supplement *docelement [addition]

Just wanted to quote here one of the funkier examples cited in the document:

urn:iso:std:iso:9999:-1:ed-1:v1-amd1.v1:en,fr:amd:2:v2:en:clause:3.1,a.2-b.9

“refers to (sub)clauses 3.1 and A.2 to B.9 in the corrected version of Amendment 2, in English, which amends the document comprising the 1st version of edition 1 of ISO 9999-1 incorporating the 1st version of Amendment 1, in English/French (bilingual document)”

Wow! That’s some ID. That’s something else.

As far as DOI is concerned there is nothing obvious to be learned. It is interesting to see such a level of granularity supported though. And since all these documents issue from a central publisher they can be prescriptive about the identifier syntax. Something which cannot be mandated for the many Crossref publishers with their own commercial arrangements. Hence DOI is generally agnostic about suffix strings.

Seems to be a little confusion about the registration though. The NID was approved Jan. 15, ’07 by the IESG and the IANA Registry of URN Namespaces (last updated Aug. 22, ’07) lists the namespace “iso” with the provisional (unnumbered) RFC labelled “RFC-goodwin-iso-urn-01.txt” (being the -01 draft). However, the IETF I-D Tracker reports this status for draft-goodwin-iso-urn, which shows that a new I-D (an -02 draft) was submitted in Sept. 7, ’07:

“A Uniform Resource Name (URN) Namespace for the International organisation for Standardization (ISO), draft-goodwin-iso-urn-02.txt“

Authors in Context?

Tony Hammond — Sun, 30 Sep 2007 00:00:00 +0000

On the subject of author IDs (a subject Crossref is interested in and on which held a meeting earlier this year, as blogged about here), this post by Karen Coyle “Name authority control, aka name identification” may be worth a read. She starts off with this:

“Libraries do something they call “name authority control”. For most people in IT, this would be called “assigning unique identifiers to names.” Identifying authors is considered one of the essential aspects of library cataloging, and it isn’t done in any other bibliographic environment, as far as I know.”

and concludes thus:

“Perhaps the days of looking at lists of authors’ names is over. Maybe users need to see a cloud of authors connected to topic areas in which they have published, or related to books titles or institutional affiliations. In this time of author abundance, names are not meaningful without some context.”

XMP-Ville

Tony Hammond — Tue, 25 Sep 2007 00:00:00 +0000

Been so busy looking into the technical details of XMP that I almost forgot to check out the current landcsape. Luckily I chanced on these articles by Ron Roszkiewicz for The Seybold Report (and apologies for lifting the title of this post from his last). The articles about XMP are well worth reading and chart the painful progress made to date:

The Brief Tortured Life of XMP (July ’05)
- [Thought Leaders Hammer out Metadata Standard] (April ’07)
  - [Metadata Persistence and “Save for Web…”] (July ’07)
  From the earlier characterization of XMP as “underachieving teenager” Roszkiewicz is cautiously optimistic that IDEAlliance’s XMP Open initiative (an initiative to advance XMP as an open industry specification) will help outreach and foster adoption of this fledgling technology.
  
  (Continues.)

There has been some activity here. Following on from an industry open day event last year:

 * [IDEAlliance XMP Open Day][5], New York, March ’06</ul>
there have been two metadata summits earlier this year co-sponsored by Adobe Systems and IDEAlliance:
* [Metadata Directions in Advertising and Branding][6], San Francisco, January ’07
* [Content Metadata Summit 1.1][7] New York, March ’07</ul>
Promising bestirrings. (And also with the recent public airing of the PRISM 2.0 draft with its support for XMP which was reviewed at the PRISM WG F2F last week for publication as a standard.) But generally the state of XMP-Ville at this time is rather sleepy. There’s not much by way of news on the [XMP Open][8] website. At least promise, if no promises.
Back to the articles. The really interesting thing of note (to me at any rate) in Roszkiewicz’s review of the last summit is the almost total absence of any mention of the Web. It is as if XMP users (both consumers and providers) would be content to play within the walled garden of the CS3 product portfolio. I don’t get that. The Web changes everything.
Although XMP maps its native data model to RDF (and RDF is an inherently open technology allowing arbitrary schemas to be mixed at will), XMP betrays its application roots by seeming to want to impose some kind of veto on the schemas to be used. Or rather, how they are to be used. It also seems to be all fussed up by centralized notions such as a cross-mapping schema registry. (As if that were part of its remit.)
As Roszkiewicz notes:
> _&#8220;The consortia [IDEAlliance and the stakeholders] will have ownership responsibility for name space registry, cross-map definition and support, standards group outreach and coordination, compliance certification and logo and the “XMP Open” brand.&#8221;_
And elsewhere:
> _&#8220;So while the standard for XMP might be defined, the data that will be fed into files is not, for want of an IDEAlliance-like standards management body to filter and rationalize the many [schema] into a few.&#8221;_
And then more worryingly, this:
> _&#8220;That schema should be managed by a government agency such as the Library of Congress which could manage the dictionaries and schema, certify them, register the namespace and provide a centralized location to distribute them.&#8221;_
Well, I don’t see what this matters to the core technology of XMP which is just a specification for the sneaking in of an XML document into arbitrary media files. And the use of RDF/XML would seem to be a further indication that XMP is to be independent of the schema used. The use of both RDF plus XML technologies should allow XMP to present itself as a framework or &#8220;platform&#8221; for metadata exchange and to get out of the way of what is actually carried by the XMP packets. App neutrality, if you will.
Again the notion of Web as just an alternate channel is apparent in the third of the articles where Roszkiewicz talks about the Device Central tool which allows a user of a CS3 product to &#8220;Save for Web or Devices&#8230;&#8221;. This article talks about the clumsy handling of metadata in such device saves, whereby the packet may be abbreviated - and metadata terms dropped - when printing to small footprint devices. Not a feature to be retained for too long, I would hope.
So, where are we currently with XMP? According to Roszkiewicz:
> _&#8220;As the developer of a suite of applications that relies on XMP as the vehicle for managing metadata, Adobe has too much invested in its development to allow any substantive changes by outsiders. So “open” primarily will mean open to suggestions, with an official channel in place to process them.&#8221;_
And as to that channel?
> _&#8220;As the principal conduit to Adobe for changes to XMP, IDEAlliance will act as a gateway and support organisation to the user community - a role for which it is well-suited. &#8230; As a sponsor-supported, not-for-profit organisation, IDEAlliance can serve as a credible buffer for Adobe to the user community and synchronize and standardize third-party development efforts.&#8221;_
And goes on:
> _&#8220;The principal unanswered questions at this point are: Will the stakeholders represent all of the key industries; will Adobe provide timely support for considering user input and updating the XMP Toolkit; and can Adobe, IDEAlliance and IDEAlliance workgroups manage all of the responsibilities that will fall upon them when the deal is struck. The hand-over doesn’t seem to have taken place yet, and we are still examining the scope and feasibility of the proposal.&#8221;_
It seems to me that Adobe is the party girl, IDEAlliance is the special guest, and Crossref publishers are the neighbourly gatecrashers who want to play with the toys. And not perhaps too nicely neither. I just hope that the toys aren’t taken away from us. They’re too much fun.
Ironic really that we’re on the outside of this since scholarly publishers have a very clearcut grasp of what to do with metadata and a ready application in terms of citation linking. XMP is worth it.

The Name’s The Thing

Tony Hammond — Thu, 20 Sep 2007 00:00:00 +0000

I’m always curious about names and where they come from and what they mean. Hence, my interest was aroused with the constant references to “XAP” in XMP. As the XMP Specification (Sept. 2005) says:

“NOTE: The string “XAP” or “xap” appears in some namespaces, keywords, and related names in this document and in stored XMP data. It reflects an early internal code name for XMP; the names have been preserved for compatibility purposes.”

Actually, it occurs in most of the core namespaces: XAP, rather than XMP.

(Continues.)

An earlier XMP Specification from 2001 (v. 1.5 - and see here for an earlier post of mine about XMP’s missing version numbers, and here about Adobe’s lack of archiving for XMP specifications) says almost the same thing:

“NOTE: Many namespaces, keywords, and related names in this document are prefaced with the string “XAP”, which was an early internal code name for XMP metadata. Because the Acrobat 5.0 product shipped using those names and keywords, they were retained for compatibility purposes.”

So, there’s no indication in either of these specifications as to what the original name signified.

But then I turned up this issue in the Adobe Developer Knowledgebase:

_“Known Issue: The metadate framework name was changed from XAP to XMP

Summary

XAP (Extensible Authoring Publishing) was an early internal code name for XMP (Extensible Metadata Platform).

Issue

Why are many namespaces, keywords, data structures, and related names in the documents and XMP toolkit code prefaced with the string “XAP” rather than “XMP”?

Solution

XAP (Extensible Authoring and Publishing) was an early internal code name for XMP (Extensible Metadata Platform) metadata. Because Acrobat 5.0 used those names, they were retained for compatibility purposes. XMP is the formal name used the framework specification.”_

Aha! Now it’s all clear. And now I’m also wondering if this original name still reflects Adobe’s thinking on the purpose of XMP that it be primarily an authoring utility rather than a workflow utility. That is, is Adobe’s XMP more geared to individual authors of Adobe’s Creative Suite products entering in metadata by hand as part of the authoring act, rather than as a batch entry process within an automated publishing workflow? The emphasis that Adobe put on Custom File Info panels for their CS products would seem to foster the view that Adobe see XMP as an interactive authoring device for adding metadata. But what about the publishers and their workflows? The SDK is a rather poor effort at garnering any widespread support of XMP within the publishing industry.

ACAP - Any chance of success?

Ed Pentz — Wed, 19 Sep 2007 00:00:00 +0000

ACAP has released some documents outlining the use cases they will be testing and some proposed changes to the Robots Exclusion Protocol (REP) - both robots.txt and META tags. There are some very practical proposals here to improve search engine indexing. However, the only search engine publicly participating in the project is http://www.exalead.com/ (which according to Alexa attracted 0.0043% of global internet visits over the last three months). The main docs are “ACAP pilot Summary use cases being tested”, “ACAP Technical Framework - Robots Exclusion Protocol - strawman proposals Part 1”, “ACAP Technical Framework - Robots Exclusion Protocol - strawman proposals Part 2”, “ACAP Technical Framework - Usage Definitions - draft for pilot testing”.

What would cause other search engines to recognize the ACAP protocols rather than ignore them? A lot of publishers implementing this and requiring search engines to recognize it to index content could put pressure on the engines. Maybe.

Style Guides Recommend DOI strings

Ed Pentz — Wed, 19 Sep 2007 00:00:00 +0000

A couple of recent posts - from A couple of recent posts - from at Jefferson University and IFST at Univ of Delaware- note that the AMA and APA style guides now recommend using a DOI, if one is assigned, in a journal article citation.

A citation in the APA style with a DOI would be:

Conley, D., Pfeiffera, K. M., & Velez, M. (2007). Explaining sibling differences in achievement and behavioral outcomes: The importance of within- and between-family factors. Social Science Research36(3), 1087-1104. doi:10.1016/j.ssresearch.2006.09.002

In the AMA style a reference would be:

Kitajima TS, Kawashima SA, Watanabe Y. The conserved kinetochore protein shugoshin protects centromeric cohesion during meiosis. Nature. 2004;427(6974):510-517. doi:10.1038/nature02312

This is great news. I haven’t looked at the full style guides but it’s not clear if information is given about linking DOIs via http://dx.doi.org.pluma.sjfc.edu/

Information on the APA Style Guide is available - http://apastyle.apa.org.pluma.sjfc.edu/ with specific info on electronic references, URLs and DOIs and here is the AMA info.

This raises the existential question of a DOI as a URI. Is

Conley, D., Pfeiffera, K. M., & Velez, M. (2007). Explaining sibling differences in achievement and behavioral outcomes: The importance of within- and between-family factors. Social Science Research36(3), 1087-1104. doi:10.1016/j.ssresearch.2006.09.002 http://dx.doi.org.pluma.sjfc.edu/10.1016/j.ssresearch.2006.09.002

unnecessary or redundant?

Chapter 9 - The Closed Book

Tony Hammond — Sat, 15 Sep 2007 00:00:00 +0000

Hadn’t really noticed before but was fairly gobsmacked by this notice I just saw on the DOI® Handbook:

**Please note that Chapter 9, Operating Procedures is for Registration Agency personnel only.**

DOI® Handbook

doi:10.1000/182

http://www.doi.org.pluma.sjfc.edu/hb.html

And, indeed, the Handbook’s TOC only reconfirms this:

9 Operating procedures*

*The RA password is required for viewing Chapter 9.

9.1 Registering a DOI name with associated metadata

9.2 Prefix assignment

9.3 Transferring DOI names from one Registrant to another

9.4 Handle System® policies and procedures

9.4.1 Overview

9.4.2 Policies and Procedures

9.4.3 Requirements for Administrators of Resolution Services

9.4.4 Protocols and Interfaces

9.5 DOI® System error messages

That’s spooky. A book with a hidden chapter. I really don’t like that at all. Especially on a book aiming to provide general information and guidance. Seems to be that if that information needs to be kept private to RA’s then it has no business rubbing shoulders with public information. I would suggest that the material be opened up or else moved out. Makes me feel so second class.

Custom Panel for CC

Tony Hammond — Sat, 15 Sep 2007 00:00:00 +0000

Creative Commons now have a custom panel for adding CC licenses using Adobe apps - see here.

Interesting on two counts:

Machine readable licenses
- XMP metadata
But I still think that batch solutions for adding XMP metadata are really required for publishing workflows. And ideally there should be support for adding arbitrary XMP packets if we’re going to have truly rich metadata. I rather fear the constraints that custom panels place upon the publisher.

Last Orders Please!

Tony Hammond — Thu, 13 Sep 2007 00:00:00 +0000

Public comment period on the PRISM 2.0 draft ends Saturday (Sept. 15) ahead of next week’s WG meeting to review feedback and finalize the spec.

(I put in some comments about XMP already. Hope they got that.)

Marking up DOI

Tony Hammond — Tue, 11 Sep 2007 00:00:00 +0000

(Update - 2007.09.15: Clean forgot to add in the rdf: namespace to the examples for xmp:Identifier in this post. I’ve now added in that namespace to the markup fragments listed. Also added in a comment here which shows the example in RDF/XML for those who may prefer that over RDF/N3.)

So, as a preliminary to reviewing how a fuller metadata description of a Crossref resource may best be fitted into an XMP packet for embedding into a PDF, let’s just consider how a DOI can be embedded into XMP. And since it’s so much clearer to read let’s just conduct this analysis using RDF/N3. (Life is too short to be spent reading RDF/XML or C++ code. :~)

(And further to Chris Shillum’s comment [(Update - 2007.09.15: Clean forgot to add in the rdf: namespace to the examples for xmp:Identifier in this post. I’ve now added in that namespace to the markup fragments listed. Also added in a comment here which shows the example in RDF/XML for those who may prefer that over RDF/N3.)

(And further to Chris Shillum’s comment]2 on my earlier post Metadata in PDF: 2. Use Cases where he notes that Elsevier are looking to upgrade their markup of DOI in PDF to use XMP, I’m really hoping that Elsevier may have something to bring to the party and share with us. A consensus rendering of DOI within XMP is going to be of benefit to all.)

(Continues.)

Within an XMP packet our first idea might be to include the DOI using the Dublin Core (DC) schema element dc:identifier in minimalist fashion:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "10.1038/nrg2158" .

This simply says that the current document (denoted by the empty URI “<>“) has a string property “10.1038/nrg2158” which is of type identifier from the dc (or Dublin Core) schema which is identified by the URI http://purl.org/dc/elements/1.1/.

Now, since this is just a DOI and the wider public cannot be expected to know about DOIs, it would surely be better to present the DOI in URI form (doi:) as

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "doi:10.1038/nrg2158" .

or, using a registered URI form (info:) as

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "info:doi/10.1038/nrg2158" .

Aside: This shows up a limitation of XMP where the DC schema property value for dc:identifier is fixed as type Text. The natural way to express the above in RDF/N3 would be as:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier <info:doi/10.1038/nrg2158> .

which says that the value is a URI (type URI in XMP terms), not a string (type Text in XMP terms). We either have to flout the XMP specification or else live with this restriction. We’ll opt for the latter for now.

But, the XMP Spec deprecates the use of dc:identifier since the context is not specific. (Note that that’s what was just discussed above. The limitation is built into XMP which builds on RDF but does not fully endorse the RDF world view.) Instead the XMP Spec recommends using xmp:Identifier since the context can be set using a qualified property as:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ] .

This says the string “10.1038/nrg2158” belongs to the scheme “DOI”.

Here we have used the scheme “DOI” and, as noted above, for wider recognition it would be better to employ one of the URI forms, e.g.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ] ] .

This says the string “doi:10.1038/nrg2158”belongs to the scheme “URI”.

But this is the unregistered URI form (doi:), so should we be using instead the registered form (info:)? Well, turns out that this construct for xmp:Identifier is an rdf:Bag so we can include more than one term. How about using this construct then:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ] ] .

Now we’ve got both forms, which is fair enough since these are equivalent. In RDF terms we can make the statement that:

doi:10.1038/nrg2158 owl:sameAs info:doi10.1038/nrg2158 .

which asserts that the two URIs are equivalent and that they reference the same resource.

So, what if we want to include a native DOI without the URI garb? We can easily do that:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ] .

OK, that takes care of the XMP direction to use xmp:Identifier, but, while deprecated by XMP, we note that back in the real world folks will be looking at the DC elements which is the schema with the greatest purchase. So, why not also add in a dc:identifier element such as would be used typically for DOI in citations. How about this:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ];
dc:identifier "doi:10.1038/nrg2158" .

Right, so we’ve taken care of the identfiers. But maybe there’s something missing? There’s no link to the DOI proxy. For widest applicability we should not assume prior knowledge of the DOI system. Perhaps we could include this link using the property dc:relation? Seems feasible though would really like to get some feedback on this. Any ideas?

So here, then, is a fairly full and complete expression of DOI within the XMP packet.

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ];
dc:identifier "doi:10.1038/nrg2158";
dc:relation "http://dx.doi.org.pluma.sjfc.edu/10.1038/nrg2158" .

Ta-da!

(Of course, this is all premised on having freedom in writing out the XMP packet. If one is dependent on commercial applications to write out the packet then things may be different. Actually, they will be very different. They may not even be workable.)

Feedback would be very welcome.

The Second Wave

Tony Hammond — Tue, 11 Sep 2007 00:00:00 +0000

You might have been wondering why I’ve been banging on about XMP here. Why the emphasis on one vendor technology on a blog focussed on an industry linking solution? Well, this post is an attempt to answer that.

Four years ago we at Nature Publishing Group, along with a select few early adopters, started up our RSS news feeds. We chose to use RSS 1.0 as the platform of choice which allowed us to embed a rich metadata term set using multiple schemas - especially Dublin Core and PRISM. We evangelized this much at the time and published documents on XML.com (Jul. ’03) and in D-Lib Magazine (Dec. ’04) as well as speaking about this at various meetings and blogging about it. Since that time many more publishers have come on board and now provide RSS routinely, many of them choosing to enrich their feeds with metadata.

Well, RSS can be seen in hindsight as being the First Wave of projecting a web presence beyond the content platform using standard markup formats. With this embedded metadata a publisher can expand their web footprint and allow users to link back to their content server.

Now, XMP with its potential for embedding metadata in rich media can be seen as a Second Wave. Media assets distributed over the network can now carry along their own metadata and identity which can be leveraged by third-party applications to provide interesting new functionalities and link-back capability. Again a projection of web presence.

(Continues.)

XMP has much in common with RSS 1.0. They are both profiles of RDF/XML. They are both flawed in certain respects because of self-imposed limitations. But they both build on a robust and open data model for the web (RDF) and are reasonably open, at least they are extensible. One (RSS 1.0) was defined in an open process by committee, the other is an open (i.e published) specification provided by a vendor.

From our point of view both specifications are sufficiently advanced to be immediately useful. I’m not sure how one could interact with the further development of either specification. RSS 1.0 is essentially frozen with Atom being posed as a successor technology, although Atom does not conform to the RDF model. (The upshot is that an RSS 1.0 feed can be consumed completely by an RDF-aware application, while an Atom feed would need to be pre-processed before any RDF “goodness” could be gleaned from it.) By contrast, XMP is a vendor-defined technology and alive, if not perhaps kicking. I am unaware of any process to formally contribute to the XMP development apart from shouting from the terraces. None the less, both technologies are usable as is.

It is curious that no consistent packaging (and delivery) of metadata has yet been achieved with HTML, the original web interface. The HTML </tt> and <tt><meta></tt> elements are employed by publishers with various degrees of consistency. There are also RDF islands that can be embedded within HTML comments (as used e.g. by <a href="http://creativecommons.org/" target="_blank">CC licenses</a>). And then there are <a href="https://web.archive.org/web/20090927174724/http://ocoins.info/" target="_blank">COinS</a> objects. But it’s all a bit of a mish-mash to date. Certainly, I don’t recall seeing any guidelines from Crossref as to how machine readable metadata (even markup for the DOI itself) may be embedded within HTML pages, rather than on HTML pages for human readers. This lack of uniform metadata deployment for HTML pages could be something to do with context. With RSS and XMP we are dealing with remote objects, whereas with HTML we are generally accessing this directly on the content server and so have a semantic context. It could be though that metadata delivery from HTML pages will finally be more uniformly available with the further development of standards such as <a href="http://microformats.org/" target="_blank">microformats</a> and especially <a href="http://www.w3.org/2006/07/SWD/RDFa/syntax/" target="_blank">RDFa</a>, <a href="http://www.w3.org/2004/01/rdxh/spec" target="_blank">GRDDL</a>, etc. It is also interesting to note that an XMP packet could just as easily be embedded within the HTML page, and if this technology were to be adopted more widely for embedding in other media assets then why not consider the same technology for ordinary web pages? I can’t help feeling though that XMP has a lot of promise and is very timely. There are only three real obstacles: creating XMP packets, writing them and reading them. To my mind, once one has a good grasp of XMP then creating the packets can be done with common tools. The same, more or less, for reading the packets. I have shown earlier that this is readily achievable. The only major block is writing the packets into media files although there is support for create/write (if patchy) by open source libraries, as well as there being support (perhaps limited) from products for create/write. But, anyway, it’s certainly do-able. </article> <article> <h1>XMP - Some Other Gripes</h1> Tony Hammond — Mon, 10 Sep 2007 00:00:00 +0000 Following on from the missing XMP Specification version number discussed in the <a href="https://www-crossref-org.pluma.sjfc.edu/blog/w5m0mpcehihzreszntczkc9d">previous post</a> here below are listed some miscellaneous gripes I’ve got with XMP (on what otherwise is a very promising technology). I would be more than happy to be proved wrong on any of these points. 1. XMP version history and archive There doesn’t appear to be any XMP version history or archive hosted by Adobe as far as I can tell. 2. Unpublished schemas Also there is nothing published - outside the XMP Spec itself - on the core schemas used by XMP. There’s nothing to be gleaned from the namespace URIs used. The Adobe namespaces, e.g. <blockquote> <a href="http://www.adobe.com/products/xmp/" target="_blank"><a href="https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/" target="_blank">https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/</a> (listed in XMP Spec)</a> </blockquote> <blockquote> </blockquote> <blockquote> <a href="http://www.adobe.com/products/xmp/" target="_blank"><a href="https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/" target="_blank">https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/</a> (not listed in XMP Spec)</a> </blockquote> seem to all resolve to this page <blockquote> <a href="http://www.adobe.com/products/xmp/" target="_blank">http://www.adobe.com/products/xmp/</a>. </blockquote> So, that can leave us with undocumented terms (e.g. ‘<tt>xmpMM:Manifest</tt>‘ used by Adobe InDesign CS2 4.0.5) from documented schemas and also undocumented schemas (e.g. ‘<tt>pdfx</tt>‘). 3. UUID Note also that many Adobe apps do not use the URN syntax for ‘<tt>uuid:</tt>‘. The XMP Spec also has this to say: <blockquote> _“There is no formal standard for URIs that are based on an abstract UUID. The following proposal may be relevant: <a href="https://datatracker.ietf.org/doc/rfc4122/" target="_blank">https://datatracker.ietf.org/doc/rfc4122/</a>; (see: 3 XMP Storage Model / Serializing XMP / rdf:Description elements / rdf:about attribute)”</blockquote> I guess the XMP Spec (Sept. ’05) had just been bedded down more or less when the URN namespace for ‘<tt>uuid:</tt>‘ was published as <a href="http://www.ietf.org/rfc/rfc4122.txt" target="_blank">RFC 4122</a> in July ’05. </blockquote> <blockquote> 4. RDF/XML serialization </blockquote> <blockquote> The biggie. </blockquote> <blockquote> XMP schemas specify fixed property value types in RDF/XML, i.e. they specify a fixed profile of RDF/XML instead of generic RDF/XML. This has been commented on recently by <a href="http://lists.w3.org/Archives/Public/semantic-web/2007Sep/0007.html" target="_blank">myself</a> on the <a href="http://lists.w3.org/Archives/Public/semantic-web/" target="_blank">semantic-web</a> list, and also <a href="http://lists.w3.org/Archives/Public/semantic-web/2007Sep/0008.html" target="_blank">here</a> by Bruce D’Arcus speaking about OpenDocument, and <a href="http://lists.w3.org/Archives/Public/semantic-web/2007Sep/0027.html" target="_blank">here</a> by Mike Linksvayer speaking for CC. </blockquote> <blockquote> This profiling of RDF/XML leads to real problems. For example, Adobe have defined a Dublin Core (DC) schema which lists the property value types that DC values can assume in an XMP serialization. Meantime, the <a href="https://web.archive.org/web/20070910031332/http://www.prismstandard.org/" target="_blank">PRISM 2.0</a> draft spec defines an incompatible mapping of DC terms to XMP property values. Since both schemas would make use of the same DC namespace (though PRISM haven’t actually specified a DC namespace for use with XMP but do use elsewhere the regular DC namespace) this isn’t going to work. I did supply some feedback on this to the PRISM WG but have heard nothing back from them. So, PRISM XMP looks uncertain at this time. Which, for us, must be a shame. </blockquote> </article> <article> <h1>connecting things: bioGUID, iSpiders and DOI</h1> Ed Pentz — Fri, 07 Sep 2007 00:00:00 +0000 David Shorthouse and Rod Page have developed some great tools for linking references by tying together a number of services and using the Crossref OpenURL interface amongst other things. See David’s post - <a href="http://ispiders.blogspot.com/2007/08/gimme-that-scientific-paper-part-iii.html" target="_blank">Gimme That Scientific Paper Part III</a> and Rod’s post on OpenURL and using ParaTools - “<a href="http://iphylo.blogspot.com/2007/05/openurl-and-spiders.html" target="_blank">OpenURL and Spiders</a>“. Unfortunately our planned changes to the Crossref OpenURL interface (the 100 queries per day limit in particular) caused some concern for David (“<a href="http://ispiders.blogspot.com/2007/09/crossref-takes-step-back.html" target="_blank">Crossref Takes a Step Back</a>“) - but make sure you read the comments to see my response! We decided to drop the 100 per day query limit for the OpenURL interface and there will be no charges for non-commercial use of the interface - <a href="https://apps-crossref-org.pluma.sjfc.edu/requestaccount/" target="_blank">https://apps-crossref-org.pluma.sjfc.edu/requestaccount/</a> We want to encourage innovative uses of Crossref services and disseminate DOIs as effectively as possible so we appreciate feedback and encourage the type of development David and Rod are doing. It will be interesting to see if what they are doing has wider applicability. Maybe Crossref could host a webpage to point to tools like this and encourage more development? </article> <article> <h1>Stop Press</h1> Tony Hammond — Tue, 28 Aug 2007 00:00:00 +0000 Boy, was I ever so wrong! Contrary to what I said in yesterday’s post, the new PRISM 2.0 spec does support XMP value type mappings for its terms. See the table below which lists the PRISM basic vocabulary terms and the XMP value types. Many thanks to Dianne Kennedy and the rest of the PRISM Working Group for having added this support to PRISM 2.0. <table border="1" cellpadding="3"> <tr> <th> Section </th> <pre><code><th> PRISM Term </th> <th> XMP Value Type </th> </code></pre> </tr> <tr> <td> 4.2.1 </td> <pre><code><td> prism:alternateTitle </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.2 </td> <pre><code><td> prism:byteCount </td> <td> Integer </td> </code></pre> </tr> <tr> <td> 4.2.3 </td> <pre><code><td> prism:channel </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.4 </td> <pre><code><td> prism:complianceProfile </td> <td> Choice: “one”, “two”, “three” </td> </code></pre> </tr> <tr> <td> 4.2.5 </td> <pre><code><td> prism:copyright </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.6 </td> <pre><code><td> prism:corporateEntity </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.7 </td> <pre><code><td> prism:coverDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.8 </td> <pre><code><td> prism:coverDisplayDate </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.9 </td> <pre><code><td> prism:creationDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.10 </td> <pre><code><td> prism:distributor </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.11 </td> <pre><code><td> prism:edition </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.12 </td> <pre><code><td> prism:eIssn </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.13 </td> <pre><code><td> prism:embargoDate </td> <td> bag Date </td> </code></pre> </tr> <tr> <td> 4.2.14 </td> <pre><code><td> prism:endingPage </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.15 </td> <pre><code><td> prism:event </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.16 </td> <pre><code><td> prism:expirationDate </td> <td> bag Date </td> </code></pre> </tr> <tr> <td> 4.2.17 </td> <pre><code><td> prism:hasAlternative </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.18 </td> <pre><code><td> prism:hasCorrection </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.19 </td> <pre><code><td> prism:hasTranslation </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.20 </td> <pre><code><td> prism:industry </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.21 </td> <pre><code><td> prism:isCorrectionOf </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.22 </td> <pre><code><td> prism:issn </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.23 </td> <pre><code><td> prism:issueIdentifier </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.24 </td> <pre><code><td> prism:issueName </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.25 </td> <pre><code><td> prism:isTranslationOf </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.26 </td> <pre><code><td> prism:killDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.27 </td> <pre><code><td> prism:location </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.28 </td> <pre><code><td> prism:modificationDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.29 </td> <pre><code><td> prism:number </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.30 </td> <pre><code><td> prism:object </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.31 </td> <pre><code><td> prism:origin </td> <td> Choice: “email”, “mobile”, “broadcast”, “web”, “print”, “recordableMedia”, “other” </td> </code></pre> </tr> <tr> <td> 4.2.32 </td> <pre><code><td> prism:organisation </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.33 </td> <pre><code><td> prism:pageRange </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.34 </td> <pre><code><td> prism:person </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.35 </td> <pre><code><td> prism:postDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.36. </td> <pre><code><td> prism:publicationDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.37 </td> <pre><code><td> prism:publicationName </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.38 </td> <pre><code><td> prism:receptionDate </td> <td> Date </td> </code></pre> </tr> <tr> <td> 4.2.39 </td> <pre><code><td> prism:rightsAgent </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.40 </td> <pre><code><td> prism:section </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.41 </td> <pre><code><td> prism:startingPage </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.42 </td> <pre><code><td> prism:subsection1 </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.43 </td> <pre><code><td> prism:subsection2 </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.44 </td> <pre><code><td> prism:subsection3 </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.45 </td> <pre><code><td> prism:subsection4 </td> <td> bag Text </td> </code></pre> </tr> <tr> <td> 4.2.46 </td> <pre><code><td> prism:teaser </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.47 </td> <pre><code><td> prism:versionIdentifier </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.48 </td> <pre><code><td> prism:volume </td> <td> Text </td> </code></pre> </tr> <tr> <td> 4.2.49 </td> <pre><code><td> prism:wordCount </td> <td> Integer </td> </code></pre> </tr> </table> </article> <article> <h1>pdfa.org</h1> Tony Hammond — Thu, 23 Aug 2007 00:00:00 +0000 Following on from yesterday’s post I just came across this very useful source of information on PDF/A: the <a href="http://pdfa.org/" target="_blank">PDF/A Conformance Center</a>. This provides links to resources such as this whitepaper <a href="http://pdfa.org/" target="_blank">PDF/A - A new Standard for Long-Term Archiving</a>, and a number of technical notes, especially <a href="http://pdfa.org/" target="_blank">Metadata and PDF/A-1</a>(also available as a <a href="http://pdfa.org/" target="_blank">PDF</a>). (This latter corrects some errors in the ISO standard which are to be redressed in a forthcoming Technical Corrigendum later this year.) The site also links to the standard, to a FAQ, to <a href="http://pdfa.org/" target="_blank">PDF/A products</a> and to news and events. There’s also an <a href="http://pdfa.org/" target="_blank">RSS feed</a> and a <a href="https://www.pdfa.org/discussion-forums/" target="_blank">discussion forum</a>. Still difficult to find examples of PDF/A though (the discussion forum doesn’t throw up too much on that score) although at least the Technical Note linked to above is a PDF/A-1 document as can be seen from this XMP description: <pre><rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/"> <pdfaid:part>1</pdfaid:part> <pdfaid:conformance>A</pdfaid:conformance> </rdf:Description> </pre> As noted before, PDF/A may be more (and less) than Crossref publishers require at this time, but nonetheless it is certainly a useful yardstick as regards embedding metadata within a PDF and is anyway a technology worth tracking in its own right. </article> <article> <h1>Weird Scenes Inside the Gold Mine</h1> Tony Hammond — Wed, 22 Aug 2007 00:00:00 +0000 So, following up on my recent posts here on Metadata in PDFs (<a href="https://www-crossref-org.pluma.sjfc.edu/blog/metadata-in-pdf-1.-strategies/">Strategies</a>, <a href="https://www-crossref-org.pluma.sjfc.edu/blog/metadata-in-pdf-2.-use-cases/">Use Cases</a>, <a href="https://www-crossref-org.pluma.sjfc.edu/blog/metadata-in-pdf-3.-deployment/">Deployment</a>), I finally came across PDF/A and PDF/X, two ISO standardized subsets of PDF. the former (<a href="http://www.iso.org/iso/catalogue_detail?csnumber=38920">ISO 19005-1:2005</a>) for archiving and the latter (<a href="http://www.iso.org/iso/catalogue_detail?csnumber=34607">ISO 15929:2002</a>, <a href="http://www.iso.org/iso/catalogue_detail?csnumber=29061">ISO 15930-1:2001</a>, etc.) for prepress digital data exchange. Both formats share some common ground such as minimizing surprises between producer and consumer and keeping things open and predictable. But my interest here is specifically in metadata and to see what guidance these standards might provide us. Not unsurprisingly, metadata is a key issue for PDF/A, less so for PDF/X. I’ll discuss PDF/X briefly but the bulk of this post is focussed on PDF/A. See below. PDF/X The main reference I am using here is the “Application Notes for PDF/X Standards” cited below [PDF/X 2]. There are two key sections which deal with metadata in PDF/X: “2.3 Identification and conformance”, and “2.20 Document identification and metadata”. Section 2.3 states that a conforming PDF/X file has the key “<tt>/GTS_PDFXVersion</tt>” in the document information dictionary, and (depending on version) may or may not have the key “<tt>/GTS_PDFXConformance</tt>“. Section 2.20 then talks about inclusion of a document ID within the document trailer to ensure correct identification of the file. It then goes on specifically to say: <blockquote> “Additionally, the use of the PDF version 1.4 Metadata key is allowed. Note that although information placed using this mechanism may be beneficial to production processes, any reader that is not PDF version 1.4 compliant may ignore this information.” </blockquote> That is, PDF/X requires the use of a document information dictionary with the key “<tt>/GTS_PDFXVersion</tt>” (and as version demands also the key “<tt>/GTS_PDFXConformance</tt>“) to signal conformance. It is lukewarm, though with regard to the inclusion of XMP metadata (as would be indicated by the “<tt>/Metadata</tt>” key in the document catalog). PDF/A The main reference I’m using here is the “ISO DIS 19005-1:2005” draft cited below [PDF/A, 1]. Completely differently from PDF/X, PDF/A puts all its attention on the XMP metadata, while at the same time acknowledging that the document information dictionary may be used. Note 1 in Section 6.7.3 notes that: <blockquote> “Since a document information dictionary is allowed within a conforming file, it is possible for a single file to be both PDF/A-1 and PDF/X [12, 13] conformant.” </blockquote> The non-normative Annex B also has this to say: <blockquote> “Use of non-XMP metadata at the file level is strongly discouraged as there is no assurance that such metadata can be preserved in accordance with this specification. In cases where non-XMP metadata is present, the preference is to convert it to XMP, embed it in the file, and describe the conversion in the xmpMM:History property.” </blockquote> It’s not fully clear here whether “file level” is intended to be the same as “document level”. But note that this anyway is from a non-normative section and does not reflect the actual normative wording used in the standard (Section 6.7.3) which allows the use of the document information dictionary. The key section for our purposes in the standard is “6.7 Metadata”. Section “6.7.2 Properties” says: <blockquote> “The document catalog dictionary of a conforming file shall contain the Metadata key. The metadata stream that forms the value of that key shall conform to XMP Specification. All metadata properties pertaining to a file that are embedded in that file, except for document information dictionary entries that have no analogue in predefined XMP schemas as defined in 6.7.3, shall be in the form of one or more XMP packets as defined by XMP Specification, 3. Metadata properties shall be specified in predefined XMP schemas or in one or more extension schemas that comply with XMP requirements. Metadata object stream dictionaries shall not contain the Filter key.” </blockquote> This is quite something. Not only is PDF/A fully supportive of XMP (even if Adobe sometimes appear to be less than enthusiastic) it actually requires it. Further it says that the XMP packets shall be human readable (well, apart from the small matter of XML, that is :). Section “6.7.3 Document information dictionary” then goes on to say: <blockquote> “A document information dictionary may appear within a conforming file. If it does appear, then all of its entries that have analogous properties in predefined XMP schemas, as defined by Table 1, shall also be embedded in the file in XMP form with equivalent values. Any document information dictionary entry not listed in Table 1 shall not be embedded using a predefined XMP schema property.” </blockquote> This says that the primary source of metadata will be the XMP packet and that, as far as possible, metadata properties in the document information dictionary will be mapped directly to the XMP packet as specified and will not cause any conflict. I’m not quite sure how to read the last sentence. Does that mean that is one were to use an “<tt>/Identifier</tt>” key in the document information dictionary then one couldn’t map it as “<tt>dc:identifier</tt>“, say, in the XMP. I think that would be OK. My read is that it precludes the use of a predefined term within the information dictionary, so one couldn’t have something like “<tt>dc:identifier</tt>” in the information dictionary. Note also that the one quirky mapping in Table 1 which arises from the need to sync the information dictionary entries with the XMP properties is this: <blockquote> “If the dc:creator property is present in XMP metadata then it shall be represented by an ordered Text array of length one whose single entry shall consist of one or more names. The value of dc:creator and the document information dictionary Author entry shall be equivalent.” </blockquote> This means that: <blockquote> “The document information dictionary entry: <pre>/Author (Peter, Paul, and Mary)</pre> </blockquote> <blockquote> is equivalent to the XMP property: <pre><dc:creator> </blockquote> <rdf:Seq> <rdf.:li>Peter, Paul, and Mary</rdf:li> </rdf:Seq> </dc:creator> </pre> <blockquote> “ </blockquote> Weird, or what? Well, of course, I see the rationale, but … The remaining sections of interest here are “6.7.6 File identifiers” which says that: <blockquote> “A conforming file should have one or more metadata properties to characterize, categorize, and otherwise identify the file. This part of ISO 19005 does not mandate any specific identification scheme. Identifiers may be externally based, such as an International Standard Book Number (ISBN) or a Digital Object Identifier (DOI), or internally based, such as a Globally Unique Identifier/Universally Unique Identifier (GUID/UUID) or another designation assigned during workflow operations.” </blockquote> Hmm, not that DOI is a file identifier necessarily. And certainly not in the Crossref usage where is denotes a work rather than a manifestation. Section “6.7.8 Extension schemas” talks about the need to rigorously declare any extension (undefined) schema with the following PDF/A extension schema description schema properties: <ul> <li> pdfaSchema:schema </li> <li> pdfaSchema:namespaceURI </li> <li> pdfaSchema:prefix </li> <li> pdfaSchema:property </li> <li> pdfaSchema:valueTypeI think this means that were PRISM terms to be used the extension schema terms would need to be defined. And finally, the section “6.7.11 Version and conformance level identification” says that: <blockquote> “The PDF/A version and conformance level of a file shall be specified using the PDF/A Identification extension schema defined in this clause.” </blockquote> This uses the PDF/A identification schema properties: <ul> <li>pdfaid:part</li> </ul> </li> <li> pdfaid:amd </li> <li> pdfaid:conformanceSummary What does this all mean? Main lessons are to be learned from PDF/A which endorses (well, actually mandates) the use of XMP. Moreover, it requires that the document information dictionary and the XMP packet be in sync. Why it signals conformance through the XMP packet rather than through the information dictionary (as does PDF/X) is a mystery. Or at least not specify a means to also signal conformance through the information dictionary. The latter is readily get-at-able. A very crude hack to extract a PDF information dictionary can be as simple as <pre>% strings <filename.pdf> | grep "/Producer" </li> </ul> </pre> <pre><code>or some other likely key. That will usually pull a line containing the full dictionary. The XMP packet is much harder to extract and then you’re still left with XML to parse. My gut feeling is that both mechanisms should be required (and sync’ed). And it’s hard not to see the DOI being required in both sections. Leads to considerations on which schemas/terms to use and how to render the DOI. I am biased and would prefer to see it rendered in URI form, i.e. in an inclusive rather than an exclusive representation. DOI is special - but not that special. Other identifiers are also useful. As per my <a href="/blog/metadata-in-pdf-1.-strategies/">earlier post</a>, I could imagine that both DC and PRISM terms could be added to an XMP packet. I’m not sure whether there is any real interest at this time to follow the PDF/A specification or rather to be informed by it. There seems to be a lot of overhead and I’m still looking to meet up with some examples (either in the wild or fabricated) to see what it might look like in practice. Interested as always in others’ views. References So, note that these are ISO documents and as such are available for purchase from the <a href="https://web.archive.org/web/20070614003151/http://www.iso.org/iso/en/prods-services/ISOstore/store.html">ISO Store</a>. (The citations above are linked to the relevant ISO Store pages.) See also this recent post (August 1, 2007) by Rick Jelliffe on XML.com: <a href="http://www.oreillynet.com/xml/blog/2007/08/where_to_get_iso_standards_on.html">Where to get ISO Standards on the Internet free</a>. There appear to be three main sources of information for these technologies: the ISO standards, application notes and FAQs. NPES (The Association for Suppliers of Printing, Publishing and Converting Technologies) hosts pages with relevant links - see <a href="https://web.archive.org/web/20050504132522/http://www.npes.org/standards/">here</a>. Below are listed specific links to freely available documentation that may be useful. Note that I have not purchased the ISO standards but have made use of an ISO DIS (draft international standard) for PDF/A and Application Notes for PDF/X by CGATS. (As yet there are no links to Application Notes for PDF/A.) <a href="http://www.npes.org/standards/toolspdfx.html">PDF/X</a> 1. (No Draft International Standard found.) </code></pre> <ul> <li><a href="">Application Notes for PDF/X Standards Version 3</a>, September 2002, CGATS Application Notes for PDF/X Standards Version 4 (PDF/X-1a:2003, PDF/X-2:2003 & PDF/X-3:2003)</a>, September 2006 , CGATS</li> <li><a href="http://www.npes.org/LinkClick.aspx?fileticket=qStx8zxAyHA%3d&tabid=158&mid=669">Frequently Asked Questions</a>, November 2005, Martin Bailey, Chair, ISO/TC130/WG2/TF2 (PDF/X)<a href="http://www.npes.org/standards/toolspdfa.html">PDF/A</a> <ol> <li><a href="https://web.archive.org/web/20060426194815/http://www.archivists.org.au/pubs/ISO_DIS_19005-1.pdf">Draft International Standard ISO/DIS 19005-1</a>, ISO/TC171/SC2, Document management— Electronic document file format for long-term preservation — Part 1: Use of PDF 1.4 (PDF/A-1)</li> </ol> </li> <li>(No Application Notes for PDF/A available yet.)</li> <li><a href="https://web.archive.org/web/20070107093446/http://www.npes.org/standards/Tools/19005-1_FAQ.pdf">Frequently Asked Questions (FAQs), ISO 19005-1:2005, PDF/A-1</a>, July 2006, PDF/A Joint Working Group </li> </ul> </article> <article> <h1>New SRU (1.2) Website</h1> Tony Hammond — Wed, 08 Aug 2007 00:00:00 +0000 From Ray Denenberg’s post to the <a href="https://web.archive.org/web/20070813010703/http://www.loc.gov/standards/sru/community/listserv.html" target="_blank">SRU Listserv</a> yesterday: <blockquote> _“The new SRU web site is now up: <a href="http://www.loc.gov/sru/" target="_blank">http://www.loc.gov/sru/</a> </blockquote> <blockquote> It is completely reorganized and reflects the version 1.2 specifications. </blockquote> <blockquote> (It also includes version 1.1 specifications, but is oriented to version </blockquote> <blockquote> 1.2.) </blockquote> <blockquote> … </blockquote> <blockquote> There is an official 1.1 archive under the new site, </blockquote> <blockquote> <a href="https://web.archive.org/web/20080724063403/http://www.loc.gov/sru/sru1-1archive/" target="_blank">https://web.archive.org/web/20080724063403/http://www.loc.gov/sru/sru1-1archive/</a>. And note also, that the new spec incorporates both version 1.1 and 1.2 (anything specific to version 1.1 is annotated as such).”_ </blockquote> Interested to learn if any Crossref publishers are currently implementing SRU. </article> <article> <h1>Handle Plugin: Some Notes</h1> Tony Hammond — Thu, 02 Aug 2007 00:00:00 +0000 The first thing to note is that this demo (the Acrobat plugin) is an application. And that comes with its own baggage, i.e. this is a Windows only plugin and is targeted at Acrobat Reader 8. On a wider purview the application merely bridges an identifier embedded in the media file and the handle record filed against that identifier and delivers some relevant functionality. The data (or metadata) declared in the PDF and in the associated handle if rich enough and structured openly can also be used by other applications. I think this is a key point worth bearing in mind, that the demo besides showing off new functionalities is also demonstrating how data (or metadata) can be embedded at the respective endpoints (PDF, handle). Some initial observations follow below. Install problems As noted in my previous post I had to haul out the old HP laptop and engage in a dialog with our IT folks to get both Acrobat Reader 8 and the plugin installed as I did not have admin privileges on my own machine. Wasn’t pretty but they were kind. Useability I don’t know what’s happening here but from our network it seems as if the first attempts to contact the handle server are timing out and the handle client in the plugin is failing over to an alternate route (HTTP?). So, the plugin doesn’t work as expected since the user has to wait an untenably long time (somewhere between 60s and 90s). Of course, if a certain network access policy is required that would need to be specified and implemented by institutions for their users. I used both Firefox and Internet Explorer browsers and ran into occasional Acrobat plugin crashes which would lock up the browser. Due to the severe network access problems noted above I wasn’t able to rigorously test this further apart from to note that it was “buggy”. Functionality I tested most of the demo cases, but was hampered by the useability restrictions noted above. I didn’t see the “Related Links” or get the “Collections” to work but did see all the other cases and tried the buttons provided. One thing of note is that the Crossref metadata record was spoofed and returned from a stored data file rather than an active query to Crossref. A real query would have been been interesting to guage the impact of network latency, although the lookup point is made by hardwiring a response. PDF Metadata OK, so the document DOI is embedded in the PDF both in the document information dictionary and in the (document) metadata stream within an XMP packet. This is great although I do have some specific comments about how the DOI is actually disclosed. See my <a href="https://www-crossref-org.pluma.sjfc.edu/blog/metadata-in-pdf-2.-use-cases">Metadata in PDF: 2. Use Cases</a> post for details. Handle Data Handle types are generally a matter for the handle administrators to oversee, although the unregulated use of new types is not going to help foster interoperability between handle applications. In passing I note that the handles used in this demo <pre>10.5555/pdftest-collection 10.5555/pdftest-collection-item1 10.5555/pdftest-collection-item2 10.5555/pdftest-collection-item3 10.5555/pdftest-crossref 10.5555/pdftest-kernelmetadata 10.5555/pdftest-multires 10.5555/pdftest-rights 10.5555/pdftest-version </pre> make use of the following handle types (periods and underscores used as below) <pre>COLLECTION COLLECTION_ITEM HS_ADMIN HS_MODIFIED HDL_MD HDL.RIGHTS HDL.XREF </pre> There is some degree of variability here which presumably will be managed better with a central handle type registry. DOI/Handle And lastly, this demo raises questions again about DOI and handle boundaries. From a handle viewpoint a DOI is nothing more than a branded handle, whereas from a DOI viewpoint a DOI is a specific handle profile with governance and policies, and its own service portfolio. The two terms should not be used interchangeably which I fear is where some of the demo details would lead us. As a very crude analogy (and with apologies to Bob Kahn) but I would see the relationship between DOI and handle as not being dissimilar from that between TCP and IP. </article> <article> <h1>Metadata in PDF: 3. Deployment</h1> Tony Hammond — Thu, 02 Aug 2007 00:00:00 +0000 So, assuming we know the form of the metadata we wish to add to our PDFs (or else to comply with if there is already a set of guidelines, or some industry initiative in effect) how can we realize this? And, on the flip side, how can we make it easier for consumers to extract metadata we have embedded in our PDFs. Below are some considerations on deploying metadata in PDFs and consumer access. Write New Obviously the best option would be to speak to one’s suppliers and to get metadata added to the PDF at create time. This leads to questions such as: <ul> <li>What metadata do we have available in the workflow process? Do we have the full set we wish to write, or just a subset? <ul> <li>Do we include metadata in the document information dictionary, or in the document metadata stream, or both? <ul> <li> OK, so we’ve decided to (also) include an XMP packet. So, now do we make that XMP packet read only or write? That is, do we allow the possibility of further edits by adding in trailing whitespace and marking it as “write”? </ul> Write Update What possibilities exist for updating legacy PDF archives? The cleanest means of updating a PDF is in-place edits. This maintains the number of PDF objects together with their lengths and byte offests. Specifically we are interested in metadata objects. There isn’t too much one can do with the document information dictionary apart from overwriting a field value or substituting a field. This is something that may be possible on a “one off” basis only. On the other hand, XMP packets are ripe for updating if they are set in “write” mode and have trailing whitespace. This can be used to supplement the metadata already contained in the packet. There is some “wiggle” room, however, even in read-only XMP packets which have no trailing whitespace. Some XMP packets may include unused default namespace declarations and/or empty elements. These could be safely stripped and used for more positive purposes. This may not be enough to write in a full metadata set, but could be enough to squeeze in the DOI. The usual way to update a PDF file is to append new objects. This means that a replacement document information dictionary and (document) metadata stream can be provided without worrying about shoe-horning the data into any leftover space in the original objects. And this would be just fine, but for the small matter of Linerarized PDFs. These are widely deployed as web friendly PDFs ready for byte serving and are written out in a strictly determined ordering. (See Appendix F, “Linearized PDF” in the <a href="http://www.adobe.com/devnet/pdf/pdf_reference.html" target="_blank">PDF Reference Manual</a>.) The manual does, however, say (Section F.4.6, “Accessing an Updated File”) this about updating a Linearized PDF: <blockquote> _“As stated earlier, if a Linearized PDF file subsequently has an incremental update appended to it, the linearization and hints are no longer valid. Actually, this is not necessarily true, but the viewer application must do some additional work to validate </blockquote> <blockquote> the information. … For a PDF file that has received only a small update, this approach may be worthwhile. Accessing the file this way is quicker than accessing it without hints or retrieving the entire file before displaying any of it.”</blockquote> This may warrant some further investigation. </blockquote> <blockquote> Read </blockquote> <blockquote> Now for consumers, how can publishers help users to read the metadata embedded in a file? The document information dictionary is reasobaly accessible and is in the clear. It probably would not provide for much in terms of metadata but should anyway hopefully contain the DOI. </blockquote> <blockquote> The XMP SDK is still far too unwieldy for wide use. Things would be much improved if there were even some <a href="http://www.swig.org/" target="_blank">SWIG wrappers</a> for more popular languages such as Perl, Python, Ruby, etc. around the C++ code. The other thing to bear in mind is that the XMP SDK is dealing with generalities such as constructing and parsing XMP objects for reading and updating in a range of binary files. A consumer metadata app would only be interested in extracting the RDF/XML from the PDF. This can then be dealt with as appropriate to the application. Another problem concerns multiple XMP packets occurring in the same PDF, only one of them being the main (or document) XMP packet. This may be a non-problem in that all the RDF/XML could be extracted and the main XMP packet would be identifiable through the metadata it provided. </blockquote> <blockquote> I suggest the best way to really help consumers is to go ahead and embed metadata in the first place, then there would be a clear impetus for extracting it. Even if a fuller metadata set is not being considered at this time, then at least the DOI should be considered for embedding in the PDF as a “hook” for further services. The handle plugin is a really good example of just such a downstream application. </blockquote> </li> </ul> </li> </ul> </li> </ul> </article> <article> <h1>PRISM 2.0</h1> Tony Hammond — Thu, 02 Aug 2007 00:00:00 +0000 Only just caught up with this but the PRISM 2.0 draft is now available (since July 12) for public comment. See this posted by Dianne Kennedy: <blockquote> _“Just a note to let you know that PRISM 2.0 has just been posted at <a href="https://web.archive.org/web/20070929195327/http://www.prismstandard.org/" target="_blank">www.prismstandard.org</a> . This is the first major revision to PRISM. We have incorporated new elements to support online content and have expanded and revised our controlled vocabularies. In addition we have added a profile to support PRISM in an XMP environment. We invite you to review the new specification (in 6 documents organized by namespace) and provide your comments before September 15. Please just email comments and questions to me, <a href="mailto:dkennedy@idealliance.org">dkennedy@idealliance.org</a>. “</blockquote> </blockquote> </article> <article> <h1>Metadata in PDF: 1. Strategies</h1> Tony Hammond — Wed, 01 Aug 2007 00:00:00 +0000 Emboldened by my own researches, by the recent handle plugin announcement from CNRI (on which, more in a follow-on post), and by Alexander Griekspoor’s comment to my earlier post, I thought I’d write a more extensive piece about embedding metadata in PDF with a view to the following: <ul> <li>Discover what other publishers are currently doing</li> <li>Stimulate discussions between content providers and/or consumers</li> <li>Lay groundwork for a Crossref best practice guidelines</li> </ul> Why should Crossref be interested? Well, at minimum to embed the DOI along with the digital asset would seem to be inherently “a good thing”. (And, in fact, this is precisely the approach that CNRI have taken for their plugin demos. I’ll look later at what they actually did and consider whether that is a model that Crossref publishers might usefully follow.) Why include the DOI as an explicit piece of metadata rather than have it included by virtue of its appearance in a content section? The main reason is that it is then unambiguously accessible. Content sections in PDFs are typically filtered and sometimes encrypted), whereas metadata is usually plain text and moreover is marked up as to field type. Another question concerns whether to add in the identifier alone, or to embed a full metadata set. Why not just embed the identifier and visit Crossref for the metadata? This is feasible in some cases although it does involve an extra network trip, requires an application to service the identifier and is obviously not workable in offline contexts. Seems like a “no-brainer” to include a fuller description from the outset. Note that publishers frequently make some of this information available anyway in other metadata delivery channels, e.g. RSS feeds. There are two (complementary) approaches to embedding document-level metadata in a PDF: <ul> <li>A - Document Information Dictionary This is an optional object (a dictionary) referenced from the PDF trailer dictionary. Example:</li> </ul> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-1" data-lang="1"><< /Title ( PostScript Language Reference, Third Edition ) /Author ( Adobe Systems Incorporated ) /Creator ( Adobe FrameMaker 5.5.3 for Power Macintosh® ) /Producer ( Acrobat Distiller 3.01 for Power Macintosh ) /CreationDate ( D:19970915110347-08'00' ) /ModDate ( D:19990209153925-08'00' ) >> endobj </code></pre></div><ul> <li>B - (Document) Metadata Stream This is an optional object (a stream) referenced from the document catalog, itself referenced from the PDF trailer dictionary. Example:</li> </ul> <pre tabindex="0"><code>2 0 obj << /Type /Metadata /Subtype /XML /Length 1706 >> stream <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>  <?xpacket end='w'? > endstream endobj </code></pre>Both approaches usually make the embedded metadata in the PDF available in the clear, whereas content is frequently filtered and sometimes encrypted. (Note that the information dictionary is always in the clear, while the metadata stream can be filtered and rendered unreadable although in practice this tends not to be filtered.) Below I examine both approaches and see how they can be used to encode the kind of metadata that scholarly publishers are accustomed to. A - Document Information Dictionary Note that keys in the document information dictionary divide equally between the logical document description (non-asterisked keys) and the physical asset description (asterisked keys): <pre tabindex="0"><code>Title Author Subject Keywords   * Creator * Producer * CreationDate * ModDate * Trapped </code></pre>This is the complete listing of keys in the PDF specification, although foreign keys are allowed (and ignored). What is missing here is any document identifier and/or any other descriptive metadata. From a Crossref point of view the identifier (the DOI) is a “hook” into the metadata record and so at minimum this could usefully be added. The question then is how? Either the identifier can be squeezed into one of the existing fields (“Title”, “Author”, “Subject”, “Keywords”) or else a new foreign key could be created. IMO if an existing keyword is used then I would opt for “Subject” or “Keywords”, and probably the former. If, on the other hand, a new foreign key were to be created I would choose something generic and (in keeping with the other terms) use something like “Identifier” (rather than, say, “DOI”). Of preference, I think I would go for the latter (“Identifier”) but if one wanted to make this more robust one could think of also adding in a known term (e.g. “Subject” or “Keywords”). So, to include metadata for the news article “Cosmology: Ripples of early starlight” printed in Nature magazine Nature 445, 37 (2007): doi:10.1038/445037a, we might include the following terms in the document information dictionary as: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-1" data-lang="1"><< /Title ( Cosmology: Ripples of early starlight ) /Author ( Craig J. Hogan ) /Subject ( doi:10.1038/445037a ) /Keywords ( cosmology infrared protogalaxy starlight ) /Identifier ( doi:10.1038/445037a ) /Creator ( ... ) /Producer ( ... ) /CreationDate ( ... ) /ModDate ( ... ) >> endobj </code></pre></div>where the bolded term represents a foreign key/value pair. Note: This (including the DOI in the “Subject” field) is a fix intended to get the DOI listed by Adobe apps which would not otherwise recognize the foreign key “Identifier”. Since it is not really feasible to include separate enumerated fields within the information dictionary (although it could be done), one might also consider including a descriptive citation field as a foreign key, e.g., something like: <pre tabindex="0"><code>/Source (Nature 445, 37 \(2007\)) </code></pre>Aternatively that might better be presented as the “Subject” along with the DOI. Which would then limit the number of foreign keys to one (“Identifier”). B - (Document) Metadata Stream The metadata stream with its use of XMP packets (wrapping RDF/XML instances) is a much more flexible approach to embedding metadata and allows multiple schemas to be used. As noted in my <a href="https://www-crossref-org.pluma.sjfc.edu/blog/xmp-first-hacks/">previous post</a> here on XMP, PDFs with XMP packets mostly use media-specific terms and schemas, although there is also a token showing of DC. From a descriptive metadata point of view we would more likely make use of DC and PRISM for our schemas. Reprising the example from the <a href="https://www-crossref-org.pluma.sjfc.edu/blog/xmp-first-hacks/">previous post</a> (and again using citation example listed above) this would mean we may be inclined to include the following terms for a scholarly work (here in RDF/N3 for readability): <pre tabindex="0"><code class="language-dc:creator" data-lang="dc:creator">dc:title "Cosmology: Ripples of early starlight" ; dc:identifier "doi:10.1038/445037a" ; dc:source "Nature 445, 37 (2007)" ; dc:date "2007-01-04" ; dc:format "application/pdf" ; dc:publisher "Nature Publishing Group" ; dc:language "en" ; dc:rights "© 2007 Nature Publishing Group" ;   prism:publicationName "Nature" ; prism:issn "0028-0836" ; prism:eIssn "1476-4679" ; prism:publicationDate "2007-01-04" ; prism:copyright "© 2007 Nature Publishing Group" ; prism:rightsAgent "permissions@nature.com" ; prism:volume "445" ; prism:number "7123" ; prism:startingPage "37" ; prism:endingPage "37" ; prism:section "News and Views" ; </code></pre>This would look something like the following as an XMP packet within a PDF metadata stream (the RDF now being serialized as RDF/XML): <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-2" data-lang="2"><< /Type /Metadata /Subtype /XML /Length 1706 >> stream <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:dc=http://purl.org/dc/elements/1.1/> <dc:creator>Craig J. Hogan</dc:creator> <dc:title>Cosmology: Ripples of early starlight</dc:title> <dc:identifier>doi:10.1038/445037a</dc:identifier> <dc:source>Nature 445, 37 (2007)</dc:source> <dc:date>2007-01-04</dc:date> <dc:format>application/pdf</dc:format> <dc:publisher>Nature Publishing Group</dc:publisher> <dc:language>en<dc:language> <dc:rights>© 2007 Nature Publishing Group</dc:rights> </rdf:Description>   <rdf:Description rdf:about="" xmlns:prism=[https://web.archive.org/web/20140228105237/http://prismstandard.org/namespaces/1.2/basic/](https://web.archive.org/web/20140228105237/http://prismstandard.org/namespaces/1.2/basic/)> <prism:publicationName>Nature</prism:publicationName> <prism:issn>0028-0836</prism:issn> <prism:eIssn>1476-4679</prism:eIssn> <prism:publicationDate>2007-01-04</prism:publicationDate> <prism:copyright>© 2007 Nature Publishing Group</prism:copyright> <prism:rightsAgent>permissions@nature.com</prism:rightsAgent> <prism:volume>445</prism:volume> <prism:number>7123</prism:number> <prism:startingPage>37</prism:startingPage> <prism:endingPage>37</prism:endingPage& <prism:section>News and Views</prism:section> </rdf:Description> <?xpacket end='w'?> endstream endobj </code></pre></div>References Some useful references are: <ul> <li> Adobe® Portable Document Format, Version 1.7, November 2006 (see <a href="http://www.adobe.com/devnet/pdf/pdf_reference.html" target="_blank">http://www.adobe.com/devnet/pdf/pdf_reference.html</a>). </li> <li> Adobe® XMP Specification, September 2005 (see <a href="http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf" target="_blank">http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf</a> </li> <li> Embedding XMP Metadata in Application Files, September 2001 (see <a href="http://xml.coverpages.org/XMP-Embedding.pdf" target="_blank">http://xml.coverpages.org/XMP-Embedding.pdf</a> </li> </ul> Note a): See Section 10.2, “Metadata” in Ref. <a href="https://www-crossref-org.pluma.sjfc.edu/blog/xmp-first-hacks/">1</a>. Note b): Ref. [3] is a fairly brief draft which covers both the Information Dictionary and Metadata Dictionary (XMP) approaches. There is an Adobe-hosted update to this document from June 2002 but that only discusses the XMP approach. </article> <article> <h1>Metadata in PDF: 2. Use Cases</h1> Tony Hammond — Wed, 01 Aug 2007 00:00:00 +0000 Well, this is likely to be a fairly brief post as I’m not aware of many use cases of metadata in PDFs from scholarly publishers. Certainly, I can say for Nature that we haven’t done much in this direction yet although are now beginning to look into this. I’ll discuss a couple cases found in the wild but invite comment as to others’ practices. Let me start though with the CNRI handle plugin demo for Acrobat which I blogged <a href="https://www-crossref-org.pluma.sjfc.edu/blog/handle-acrobat-reader-plugin/">here</a>. Handle Plugin First off, the handle plugin PDF samples do include an embedded (test) DOI in both the document information dictionary <pre>5 0 obj << /CreationDate (D:20070614140125-04'00') /Author (Simon) /Creator (PScript5.dll Version 5.2.2) /Producer (Acrobat Distiller 8.1.0 \(Windows\)) /ModDate (D:20070614140240-04'00') /HDL (10.5555/pdftest-crossref) /Title (Microsoft Word - crossref-rev.doc) >> endobj </pre> and in the (document) metadata stream <pre><rdf:Description rdf:about="" xmlns:pdfx="http://ns.adobe.com/pdfx/1.3/"> <pdfx:HDL>10.5555/pdftest-crossref</pdfx:HDL> </rdf:Description> </pre> Bar any fuller disclosure of metadata terms at large (and one of the demo cases makes use of DOI to retrieve metadata form Crossref) this is excellent. I would, however, quibble with the use of “HDL” as a foreign key for the information dictionary. I realize this is just a test but the term “HDL” (or “DOI”, for that’s what it really is) is somewhat specific and a more general term such as “Identifier” would probably have more mileage, e.g. <pre>5 0 obj << ... /Identifier (doi:10.5555/pdftest-crossref) ... >> endobj </pre> In the second example from the metadata dictionary I don’t think the term “HDL” from the PDF extension schema “pdfx” is very helpful. (Is that namespace actually defined anywhere?) From a descriptive metadata viewpoint a more usual schema such as DC would have wider coverage. So again the second example would be better rendered as <pre><rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:identifier>doi:10.5555/pdftest-crossref</dc:identifier> </rdf:Description> </pre> or, alternately, <pre><rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:identifier>info:hdl/10.5555/pdftest-crossref</dc:identifier> </rdf:Description> </pre> Elsevier Well, we have Alexander Griekspoor’s <a href="https://www-crossref-org.pluma.sjfc.edu/blog/xmp-first-hacks/">comment earlier</a> that Elsevier are including the DOI in their PDFs. I don’t know how consistently this is being done but I’ve checked a couple sample articles and it would seem that they have embedded the DOI (here from Cancer Cell, doi:0.1016/j.ccr.2007.06.004) in the title element which shows up in the information dictionary as <pre>361 0 obj << /Producer (Adobe LiveCycle PDFG 7.2) /Creator (Elsevier) /Author () /Keywords () /Title (doi:10.1016/j.ccr.2007.06.004) /ModDate (D:20070630031637+05'30') /Subject () /CreationDate (D:00000101000000Z) >> endobj </pre> and in the (document) metadata dictionary as <pre>365 0 obj << /Type /Metadata /Subtype /XML /Length 1526 >> stream <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d' bytes='1526'?> <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/'> <rdf:Description about='' xmlns='http://ns.adobe.com/pdf/1.3/' xmlns:pdf='http://ns.adobe.com/pdf/1.3/'> <pdf:Producer>Adobe LiveCycle PDFG 7.2</pdf:Producer> <pdf:ModDate>2007-06-30T03:16:37+05:30</pdf:ModDate> <pdf:Title>doi:10.1016/j.ccr.2007.06.004</pdf:Title> <pdf:Creator>Elsevier</pdf:Creator> <pdf:Author></pdf:Author> <pdf:Keywords></pdf:Keywords> <pdf:Subject></pdf:Subject> <pdf:CreationDate>0-01-01T00:00:00Z</pdf:CreationDate> </rdf:Description> <rdf:Description about='' xmlns='http://ns.adobe.com/xap/1.0/' xmlns:xap='http://ns.adobe.com/xap/1.0/'> <xap:CreatorTool>Elsevier</xap:CreatorTool> <xap:ModifyDate>2007-06-30T03:16:37+05:30</xap:ModifyDate> <xap:Title> <rdf:Alt> <rdf:li xml:lang='x-default'>doi:10.1016/j.ccr.2007.06.004</rdf:li> </rdf:Alt> </xap:Title> <xap:Author></xap:Author> <xap:Description> <rdf:Alt> <rdf:li xml:lang='x-default'/> </rdf:Alt> </xap:Description> <xap:CreateDate>0-01-01T00:00:00Z</xap:CreateDate> <xap:MetadataDate>2007-06-30T03:16:37+05:30</xap:MetadataDate> </rdf:Description> <rdf:Description about='' xmlns='http://purl.org/dc/elements/1.1/' xmlns:dc='http://purl.org/dc/elements/1.1/'> <dc:title>doi:10.1016/j.ccr.2007.06.004</dc:title> <dc:creator/> <dc:description/> </rdf:Description> </rdf:RDF> <?xpacket end='r'?> endstream endobj </pre> Kudos anyway to Elsevier for emebedding this piece of information in their PDFs (if indeed it is a general practice). This has the merit of being picked up by Adobe apps and displayed in e.g. Reader. Also third party apps can pull this and use this to retrieve the metadata record from Crossref. The only downside is that technically this seems to be a kludge to satisfy Adobe apps and is not the correct field for filing this information. I would have thought that some other information dictionary field (e.g. “Subject”) would be a better kludge, and then reserve the “Title” and “Author” fields for their proper purposes. The RDF/XML title fields would appear to be inherited from the “Title” field in the information dictionary. It’s a bit of a shame really because the DOI is embedded - it’s just in the wrong place(s). (OK, so that’s still way better, maybe, than not providing this information at all.) Hopefully, with more examples to mull over and experiences to learn from we can arrive at a much better and more systematic way of including the DOI, and other key metadata fields, within a PDF so that this information can be gleaned easily and unambiguously by third party apps. </article> <article> <h1>Handle Acrobat Reader Plugin</h1> Tony Hammond — Tue, 31 Jul 2007 00:00:00 +0000 Just announced on the <a href="http://www.handle.net/mailman/listinfo/handle-info" target="_blank">handle-info</a> list is a new plugin from CNRI for Acrobat Reader - see <a href="http://www.handle.net/hs-tools/adobe/" target="_blank">here</a>. The announcement says: <blockquote> _“It is intended to demonstrate the utility of embedding a identifying </blockquote> <blockquote> handle in a PDF document. </blockquote> <blockquote> </blockquote> <blockquote> … </blockquote> <blockquote> </blockquote> <blockquote> A set of demonstration documents, each with an embedded identifying </blockquote> <blockquote> handle, is packaged with the plug-in to show potential uses. To make </blockquote> <blockquote> productive use of this technology, a given industry or community of </blockquote> <blockquote> users would have to agree on one or more specific applications and </blockquote> <blockquote> populate the relevant handle records accordingly.”_ </blockquote> Two immediate comments: <ul> <li>This is a Windows-only plugin (realized that right after hitting the download button and seeing the ‘.exe’ file) and also needs admin rights to install. (So I solved the first hurdle and am trying to clear the second hurdle. Lockdown is not an uncommon practice for enterprise or institutional computers.) (Update: Actually, I think I got this wrong. I need admin privileges to install Adobe Acrobat 8. Still scuppered, though. Can’t even see the sample PDF files.) <ul> <li>The plugin seems to be aimed at the user rather than at the user agent and thus is necessarily limited in scope, i.e. it needs a human driver. (Ideally content providers would embed metadata within media files using structured markup techniques which would be readily accessible to any downstream app which could leverage this data transparently to provide enhanced user services.) </ul> Anyway, I’ll add something more when I can get it installed. I think this tool could be a useful addition to publishing toolkits but also that content providers could do much more for consumers by disclosing metadata for their digital assets in a neutral, structured form.</li> </ul> </li> </ul> </article> <article> <h1>URI Template Republished</h1> Tony Hammond — Sat, 28 Jul 2007 00:00:00 +0000 Well, it all went very quiet for a while but glad to see that the <a href="https://github.com/jcgregorio/uri-templates/blob/master/draft-gregorio-uritemplate-01.txt" target="_blank">URI Template Internet-Draft</a> has just been republished: <blockquote> _“A New Internet-Draft is available from the on-line Internet-Drafts </blockquote> <blockquote> directories. </blockquote> <blockquote> Title : URI Template </blockquote> <blockquote> Author(s) : J. Gregorio, et al. </blockquote> <blockquote> Filename : draft-gregorio-uritemplate-01.txt </blockquote> <blockquote> Pages : 9 </blockquote> <blockquote> Date : 2007-7-23 </blockquote> <blockquote> URI Templates are strings that can be transformed into URIs after </blockquote> <blockquote> embedded variables are substituted. This document defines the </blockquote> <blockquote> syntax and processing of URI Templates. </blockquote> <blockquote> A URL for this Internet-Draft is: </blockquote> <blockquote> <a href="https://github.com/jcgregorio/uri-templates/blob/master/draft-gregorio-uritemplate-01.txt" target="_blank">https://github.com/jcgregorio/uri-templates/blob/master/draft-gregorio-uritemplate-01.txt</a>” </blockquote> <blockquote> _ </blockquote> URI templates should be a very useful publishing tool. Templates are already used by technologies such as OpenSearch - see <a href="https://www.opensearch.org/" target="_blank">here</a>. </article> <article> <h1>Publishing Linked Data</h1> Tony Hammond — Thu, 19 Jul 2007 00:00:00 +0000 With these words: <blockquote> _“There was quite some interest in Linked Data at this year’s World Wide </blockquote> <blockquote> Web Conference (WWW2007). Therefore, Richard Cyganiak, Tom Heath and I </blockquote> <blockquote> decided to write a tutorial about how to publish Linked Data on the </blockquote> <blockquote> Web, so that interested people can find all relevant information, best </blockquote> <blockquote> practices and references in a single place.”_ </blockquote> Chris Bizer announces this draft <a href="https://web.archive.org/web/20120315113002/http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/" target="_blank">How to Publish Linked Data on the Web</a>. It’s a bright and breezy tutorial and useful (to me, anyway) for disclosing a couple of links: <ul> <li><a href="http://www.w3.org/2001/tag/findings" target="_blank">Findings of the W3C TAG</a> <ul> <li> <a href="http://www.w3.org/DesignIssues/LinkedData.html" target="_blank">Linked Data - Design Issues</a> </ul> The tutorial is unsurprisingly orthodox in its advocacy for all things HTTP and goes on to say: <blockquote> “In the context of Linked Data, we restrict ourselves to using HTTP URIs only and avoid other URI schemes such as URNs and DOIs.” </blockquote> But this only relates back to Berners-Lee’s piece on Linked Data referenced above in which he says: <blockquote> “The second rule, to use HTTP URIs, is also widely understood. The only deviation has been, since the web started, a constant tendency for people to invent new URI schemes (and sub-schemes within the urn: scheme) such as LSIDs and handles and XRIs and DOIs and so on, for various reasons. Typically, these involve not wanting to commit to the established Domain Name System (DNS) for delegation of authority but to construct something under separate control. Sometimes it has to do with not understanding that HTTP URIs are names (not addresses) and that HTTP name lookup is a complex, powerful and evolving set of standards. This issue discussed at length elsewhere, and time does not allow us to delve into it here.” </blockquote> Hmm. Does make one wonder where the concept of URI ever arose. Surely the nascent WWW application should have mandated the exclusive use of HTTP identifiers? Seems that this concept snuck up on us somehow and we now have to put it back into the box. Pandora, indeed! Back to the tutorial there are some unorthodox terms or at least I had not heard of them before. Contrasted with the defined term information resources (from <a href="http://www.w3.org/TR/webarch/" target="_blank">AWWW</a>) is the undefined term “non-information resources”. Further on, there’s a distinction made between two types of RDF triple: “literal triples” and “RDF links”. I hadn’t heard of either of these terms before although they are presented as if they were in common usage. The tutorial then goes on to deprecate the use of certain RDF features because it makes it “easier for clients”. So, I guess that the full expressivity of RDF is either not required or the world of “linked data” is not quite so large as it would like to be. And later on, there’s this puzzling injunction: <blockquote> “You should only define terms that are not already defined within well-known vocabularies. In particular this means not defining completely new vocabularies from scratch, but instead extending existing vocabularies to represent your data as required.” </blockquote> Am I wrong, or is there something of a Catch 22 there? To extend an arbitrary vocabulary I would need to be the namespace authority - to be the “URI owner” in W3C speak. But I can’t be the authority for all namespaces/vocabularies because by the intent of the above they would likely be just the one (true?) vocabulary which I may or may not be the authority for. I thought the intent of the RDF model and XML namespaces was that terms could be applied from disparate vocabularies to the description at hand. Anyways, I am not trying to knock the draft. It’s something of a curate’s egg, that’s true, but I am genuinely looking forward to reading it through and would encourage others to have a look at it too. </li> </ul> </li> </ul> </article> <article> <h1>PURL Redux</h1> Tony Hammond — Thu, 12 Jul 2007 00:00:00 +0000 Seems that there’s life in the old dog yet. :~) See <a href="http://outgoing.typepad.com/outgoing/2007/07/purl2.html" target="_blank">this post</a> about PURL from Thom Hickey, OCLC, This extract: <blockquote> OCLC has contracted with Zepheira to reimplement the PURL code which has become a bit out of date over the years. The new code will be in written in Java and released under the Apache 2.0 license. </blockquote> </article> <article> <h1>BioNLP 2007</h1> Tony Hammond — Tue, 10 Jul 2007 00:00:00 +0000 Just posted on Nascent a <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2007/07/otmi_at_bionlp_2007.html" target="_blank">brief account</a> of a presentation I gave recently on <a href="http://opentextmining.org/" target="_blank">OTMI</a> at <a href="http://ufal.mff.cuni.cz/acl2007/workshops/program/index.php/ws05" target="_blank">BioNLP 2007</a>. The post lists some of the feedback I received. We are very interested to get further comments so do feel free to contribute comments either directly to the post, privately to <a href="mailto:otmi@nature.com">otmi@nature.com</a>, or publicly to <a href="mailto:otmi-discuss@crossref.org">otmi-discuss@crossref.org</a>. And then there’s always the OTMI wiki available for comment at <a href="http://opentextmining.org/" target="_blank">http://opentextmining.org/</a>. It is important to note that OTMI is not a universal panacea but rather an attempt at bridging the gap between publisher and researcher. We are attempting to provide a framework to enable scholarly publishers to disclose full text for machine processing purposes without compromising their normal publishing obligations. </article> <article> <h1>IBM Article on PRISM</h1> Tony Hammond — Tue, 10 Jul 2007 00:00:00 +0000 Nice entry article on PRISM <a href="http://www.ibm.com/developerworks/xml/library/x-think13.html" target="_blank">here</a> by Uche Ogbuji, Fourthought Inc. on IBM’s DeveloperWorks. </article> <article> <h1>Oh, shiny!</h1> Crossref — Mon, 02 Jul 2007 00:00:00 +0000 The other day Ed and I visited the <a href="http://www.oecd.org/" target="_blank">OECD</a> to talk about all things e-publishig. At the end of our our meeting, Toby Green, the OECD’s head of publishing, handed all 30+ meeting attendees a copy of their well-known <a href="https://www.oecd.org/en/publications/oecd-factbook-2015-2016_factbook-2015-en.html" target="_blank">OECD Factbook</a>- on a USB stick. Before you dismiss this as a gimick- note that organisations like the OECD get a lot of political and marketing mileage with “leave behinds”- print copies of their key reports, conference proceedings and reference works. While researchers might prefer electronic versions of the publications for their day-to-day work, print versions of the same publications seemed to continue to play a critical role as an “awareness tool.” I know that, for this very reason, several NGO/IGOs that I’ve spoken to have despaired of ever ramping down their print operations. I think that the OECD might have figured out a solution to this dilemma. It’s difficult to describe how viscerally satisfying it was to receive one of these Factbook USB-sticks. From the way in which the other meeting attendees swarmed around Toby as he was handing them out, I think that they might have had the same reaction. As we headed back to London on the Eurostar, I almost immediately popped the USB stick into my laptop and started browsing through the Factbook, much as I would have thumbed through a print version of the same (although -truth be told- I would have been tempted to conveniently “forget” the print version in order to not have to shlep it from Paris back to Oxford). In short, I think the system works. Kudos to the OECD for a simple, inexpensive and creative experiment in e-publishing. </article> <article> <h1>OASIS Announces Search Web Services TC</h1> Tony Hammond — Fri, 15 Jun 2007 00:00:00 +0000 <a href="https://www.oasis-open.org/" target="_blank">OASIS</a> has just <a href="http://lists.oasis-open.org/archives/tc-announce/200706/msg00008.html" target="_blank">announced</a> a technical committee for standardising search services. This from the Call for Participation: <blockquote> _ </blockquote> <blockquote> b. Purpose </blockquote> <blockquote> To define Search and Retrieval Web Services, combining various current and </blockquote> <blockquote> ongoing web service activities. </blockquote> <blockquote> Within recent years there has been a growth in activity in the development of </blockquote> <blockquote> web service definitions for search and retrieval applications. These include </blockquote> <blockquote> SRU, a web service based in part on the NISO/ISO Search and Retrieval standards; </blockquote> <blockquote> the Amazon OpenSearch, which defines a means of describing and automating search </blockquote> <blockquote> web forms; as well as many proprietary definitions (e.g. the Google and MSN </blockquote> <blockquote> Search APIs). There are also a number of activities for defining abstract search </blockquote> <blockquote> APIs that can be mapped onto multiple implementations either within native code </blockquote> <blockquote> or onto remote procedural calls and web services, such as ZOOM (Z39.50 Object </blockquote> <blockquote> Oriented Model); SQI (Simple Query Interface), an IEEE standard developed for </blockquote> <blockquote> searching and retrieval in the IMS (Instructional Management Systems) space; and </blockquote> <blockquote> OSIDs (Open Service Interface Definitions from the Open Knowledge Initiative. </blockquote> <blockquote> While abstract APIs would be out of scope, these would inform the work to </blockquote> <blockquote> increase interoperability and compatibility. </blockquote> <blockquote> _ </blockquote> </article> <article> <h1>IDF Open Meeting: Innovative uses of the DOI system</h1> Ed Pentz — Fri, 08 Jun 2007 00:00:00 +0000 Please see the details of the IDF Annual Meeting and a related Handle System Workshop in Washington, DC on June 21 which may be of interest - <a href="http://www.crossref.org.pluma.sjfc.edu/crweblog/2007/06/international_doi_foundation_a.html" target="_blank">http://www.crossref.org.pluma.sjfc.edu/crweblog/2007/06/international_doi_foundation_a.html</a> </article> <article> <h1>Resource Maps</h1> Tony Hammond — Tue, 05 Jun 2007 00:00:00 +0000 Last week we had a second face-to-face of the <a href="http://www.openarchives.org/ore/" target="_blank">OAI-ORE</a> (Open Archives Initiative – Object Reuse and Exchange) Technical Committee in New York, the meeting being hosted courtesy of Google. (Hence the snap here taken from the terrace of Google’s canteen with its gorgeous view of midtown Manhattan. And the food’s not too shabby either. ;~) The main input to the meeting was this discussion document: <a href="http://www.openarchives.org/ore/documents/CompoundObjects-200705.html" target="_blank">Compound Information Objects: The OAI-ORE Perspective</a>. This document we feel has now reached a level of maturity that we wanted to share with a wider audience. We invite feedback either directly at <a href="mailto:ore@openarchives.org.">ore@openarchives.org</a> or indirectly via <a href="mailto:t.hammond@nature.com">yours truly</a>. The document attempts to describe the problem domain - that of describing a scholarly publication as an aggregation of resources on the Web - and to put that squarely into the Web architecture context. What the initiative is seeking to provide is machine descriptions of those resources and their relationships, something that we are inclining to call “resource maps” and as underpinning we are making use of the notion of “named graphs” from ongoing semantic web research. Essentially these resource maps are machine-readable descriptions of participating resources (in a scholarly object - both core resources and related resources) and the relationships between those resources, the whole set of assertions about those resources being named (i.e. having a URI as identifier) and having provenance information attached, e.g. publisher, date of publication, version information (still under discussion). It is envisaged that these compound object descriptions may be available in a variety of serializations from a published, object-specific URL (i.e. a good old-fashioned Web address) but some honest-to-goodness XML serialization is a likely to be one of the candidates. No surprises here, then. Below is a schematic from the paper which shows the publication of a resource map (or named graph) corresponding to the compound object which logically represents a scholarly publication. For those objects of immediate interest to Crossref these would likely be identified with DOI’s although there is no restriction in OAI-ORE on the identifier to be used - other than it be a URI. Update: For a couple posts from some other members of the ORE TC see <a href="https://web.archive.org/web/20160404104320/http://dltj.org/article/thoughts-on-compound-documents/" target="_blank">here</a> (Peter Murray, OhioLINK) and <a href="https://web.archive.org/web/20160410040938/http://efoundations.typepad.com/efoundations/2007/06/refining_ore.html" target="_blank">here</a> (Pete Johnston, Eduserv). </article> <article> <h1>RSC’s Project Prospect v1.1</h1> rkidd — Thu, 31 May 2007 00:00:00 +0000 We updated our <a href="https://web.archive.org/web/20070401173200/http://www.rsc.org.pluma.sjfc.edu/Publishing/Journals/ProjectProspect/index.asp" target="_blank">Project Prospect</a> articles today to release v1.1, with a pile of look & feel improvements to the HTML views and links. The most interesting technical addition is the launch of our enhanced RSS feeds, where we have updated our <a href="https://pubs-rsc-org.pluma.sjfc.edu/en/EAlerts/RssFeed" target="_blank">existing feeds</a> for enhanced articles. These now include ontology terms and primary compounds both visually (as text terms and 2D images) and within the RDF - using the OBO in OWL representation and the info:inchi specification mentioned here by Tony only a few weeks ago. The enhanced entries will soon become more common as we concentrate our enhancements on our Advance Articles, but the current example below from our <a href="https://pubs-rsc-org.pluma.sjfc.edu/en/ealerts/rssfeed" target="_blank">Photochemical and Photobiological Sciences feed</a> is lovely. RDF code after the jump - just as beautiful to the parents… So the RDF code for the OBO terms and InChIs looks like this: <pre tabindex="0"><code><tt> <rdf:li> <content:item rdf:about="info:inchi/InChI=1/C20H28O/c1-16(8-6-9-17(2)13-15-21)11-12-19-18(3)10-7-14-20(19,4)5/h6,8-9,11-13,15H,7,10,14H2,1-5H3/b9-6-,12-11+,16-8+,17-13+"/> </rdf:li> <rdf:li><content:item rdf:about="http://purl.org/obo/owl/CL#CL:0000210"/> </rdf:li> </tt> </code></pre>We now have over five hundred 2007 articles enhanced, so we’ve brought the majority back into controlled access. There are always <a href="https://web.archive.org/web/20081004073354/http://www.rsc.org.pluma.sjfc.edu/Publishing/Journals/ProjectProspect/Examples.asp" target="_blank">examples</a> from each journal freely available. </article> <article> <h1>OAI-ORE Presentation at OAI5</h1> Tony Hammond — Wed, 02 May 2007 00:00:00 +0000 I posted <a href="https://www-crossref-org.pluma.sjfc.edu/blog/digital-objects/">here</a> about an initial meeting of the <a href="http://www.openarchives.org/ore/" target="_blank">OAI-ORE</a> Technical WG back in January. ORE is the “Object Reuse and Exchange” initiative which is aiming to provide a formalism for describing scholarly works as complete units (or packages) of information on the Web using resource maps which would be available from public access points. From a DOI perspective this work is intimately connected with multiple resolution. For further updates on this work, see <a href="https://indico.cern.ch/event/5710/contributions/1212289/attachments/988175/1405153/ore-oai5-hvds.pdf" target="_blank">here</a> for a presentation by Herbert Van de Sompel on OAI-ORE at the OAI5 Workshop (5th Workshop on Innovations in Scholarly Communication) held a couple weeks back at CERN, Geneva, Switzerland. The presentation gives an insight regarding the problem domain in which ORE operates, and in the evolving thinking regarding potential solutions. The presentation was recorded on video and is available for both streaming and download (<a href="https://web.archive.org/web/20070709065314/http://indico.cern.ch/" target="_blank">slides</a>, <a href="https://web.archive.org/web/20070709065314/http://indico.cern.ch/" target="_blank">streaming video</a>, <a href="https://web.archive.org/web/20070709065314/http://indico.cern.ch/" target="_blank">video download</a>). Note that Michael Nelson of Old Dominion University also presented on behalf of the ORE effort at the recent <a href="https://web.archive.org/web/20110106125135/http://www.cni.org/tfms/2007a.spring/abstracts/PB-update-lagoze.html" target="_blank">CNI Task Force Meeting</a> and at the <a href="https://web.archive.org/web/20070604163358/http://www.diglib.org/forums/spring2007/spring2007abstracts.htm" target="_blank">DLF Forum</a>. </article> <article> <h1>A Modest Proposal</h1> Tony Hammond — Wed, 11 Apr 2007 00:00:00 +0000 Was just reminded (thanks, Tim) of the possibility of using a special tag in bookmarking services to tag links to documents of interest to a given community. I think this is a fairly well-established practice. Note that e.g. the <a href="http://www.openarchives.org/ore/" target="_blank">OAI-ORE</a> project is using <a href="https://web.archive.org/web/20061205061750/http://www.connotea.org/" target="_blank">Connotea</a> to bookmark pages of interest and tagging them “oaiore” which can then be easily retrieved using the link <a href="http://web.archive.org/web/20160402182544/http://www.connotea.org/" target="_blank">http://web.archive.org/web/20160402182544/http://www.connotea.org/</a>. I would suggest that Crossref members might like to consider using the tag “crosstech” in bookmarking pages about publishing technology, so that the following links might be used to retrieve documents of interest to this readership: <ul> <li>del.icio.us - <https://web.archive.org/web/20071206033322/https://del.icio.us/ <ul> <li>CiteULike - <a href="http://www.citeulike.org/tag/crosstech" target="_blank">http://www.citeulike.org/tag/crosstech</a> <ul> <li>Connotea - <a href="http://web.archive.org/web/20160402182544/http://www.connotea.org/" target="_blank">http://web.archive.org/web/20160402182544/http://www.connotea.org/</a> <ul> <li>etc. </ul></li> </ul> </li> </ul> </li> </ul> </li> </ul> </article> <article> <h1>Citing Data Sets</h1> Tony Hammond — Fri, 30 Mar 2007 00:00:00 +0000 This <a href="http://www.dlib.org/dlib/march07/altman/03altman.html" target="_blank">D-Lib paper</a> by Altman and King looks interesting: “A Proposed Standard for the Scholarly Citation of Quantitative Data”. (And thanks to <a href="http://public.lanl.gov/herbertv/" target="_blank">Herbert Van de Sompel</a> for drawing attention to the paper.) Gist of it (Sect. 3) is <blockquote> _“We propose that citations to numerical data include, at a minimum, six required components. The first three components are traditional, directly paralleling print documents. … Thus, we add three components using modern technology, each of which is designed to persist even when the technology changes: a unique global identifier, a universal numeric fingerprint, and a bridge service. They are also designed to take advantage of the digital form of quantitative data. </blockquote> <blockquote> An example of a complete citation, using this minimal version of the proposed standards, is as follows: </blockquote> <blockquote> **Micah Altman; Karin MacDonald; Michael P. McDonald, 2005, “Computer Use in Redistricting”, </blockquote> <blockquote> hdl:1902.1/AMXGCNKCLU UNF:3:J0PkMygLPfIyT1E/8xO/EA== </blockquote> <blockquote> <code>http://id.thedata.org/hdl%3A1902.1%2FAMXGCNKCLU</code> </blockquote> <blockquote> “_ </blockquote> So the abbreviated citation (author, date, title, unique ID) is supplemented by a <a href="https://web.archive.org/web/20061006030921/http://cran.r-project.org/src/contrib/Descriptions/UNF.html" target="_blank">UNF</a> which fingerprints the data. UNFs would appear to be a sort of super MD5 in providing a signature of the data content independent of the data serialization to a filestore. <blockquote> _“Thus, we add as the fifth component a Universal Numeric Fingerprint or UNF. The UNF is a short, fixed-length string of numbers and characters that summarize all the content in the data set, such that a change in any part of the data would produce a completely different UNF. A UNF works by first translating the data into a canonical form with fixed degrees of numerical precision and then applies a cryptographic hash function to produce the short string. The advantage of canonicalization is that UNFs (but not raw hash functions) are format-independent: they keep the same value even if the data set is moved between software programs, file storage systems, compression schemes, operating systems, or hardware platforms. </blockquote> <blockquote> … </blockquote> <blockquote> Finally, since most web browsers do not currently recognize global unique identifiers directly (i.e., without typing them into a web form), we add as the sixth and final component of the citation standard a bridge service, which is designed to make this task easier in the medium term.”_ </blockquote> Certainly looks promising. I’m not sure if there’s any other contestants in this arena. </article> <article> <h1>Crossref Forward Linking Webinar</h1> Anna Tolwinska — Thu, 29 Mar 2007 00:00:00 +0000 The next Crossref Forward Linking Webinar is coming on Monday April 30th , 2007 at 12:00pm. Registration is now available: [The next Crossref Forward Linking Webinar is coming on Monday April 30th , 2007 at 12:00pm. Registration is now available:]<a href="https://www-crossref-org.pluma.sjfc.edu/webinars" target="_blank">1</a> Agenda is coming soon. </article> <article> <h1>Markup for DOIs</h1> Tony Hammond — Thu, 29 Mar 2007 00:00:00 +0000 Following up on his earlier <a href="http://allmyeye.blogspot.com/2007/03/persistent-linking-web-crawlers-and.html" target="_blank">post</a> (which was also blogged to CrossTech <a href="https://www-crossref-org.pluma.sjfc.edu/blog/indexing-urls/">here</a>), Leigh Dodds is now [Following up on his earlier <a href="http://allmyeye.blogspot.com/2007/03/persistent-linking-web-crawlers-and.html" target="_blank">post</a> (which was also blogged to CrossTech <a href="https://www-crossref-org.pluma.sjfc.edu/blog/indexing-urls/">here</a>), Leigh Dodds is now]<a href="http://allmyeye.blogspot.com/2007/03/persistent-links-in-bookmarks.html" target="_blank">3</a> the possibility of using machine-readable auto-discovery type links for DOIs of the form <tt> <link rel="bookmark" title="DOI" href="http://dx.doi.org.pluma.sjfc.edu/10.1000/1"/> </tt> These <code>LINK</code> tags are placed in the document <code>HEAD</code> section and could be used by crawlers and agents to recognize the work represented by the current document. This sounds like a great idea and we’d like to hear feedback on it. Concurrently at Nature we have also been considering how best to mark up in a machine-readable way DOIs appearing within a document page <code>BODY</code>. Current thinking is to do something along the following lines: <tt> <a href="http://dx.doi.org.pluma.sjfc.edu/10.1038/nprot.2007.43"> <abbr title="Digital Object Identifier">doi</abbr>: <abbr class="uri" id="doi" title="info:doi/10.1038/nprot.2007.43">10.1038/nprot.2007.43</abbr> </a> </tt> which allows the DOI to be presented in the preferred Crossref citation format (<code>doi:10.1038/nprot.2007.43</code>), to be hyperlinked to the handle proxy server (<code><a href="http://dx.doi.org.pluma.sjfc.edu/10.1038/nprot.2007.43">http://dx.doi.org.pluma.sjfc.edu/10.1038/nprot.2007.43</a></code>), and to refer to a validly registered URI form for the DOI (<code>info:doi/10.1038/nprot.2007.43</code>). Again, we would be real interested to hear any opinions on this proposal for inline DOI markup as well as on Leigh’s proposal for document-level DOI markup. (Oh, and btw many congrats to Leigh on his recent <a href="https://web.archive.org/web/20081014005906/http://eyetoeye.ingenta.com.pluma.sjfc.edu/publisher/issue18/news-dodds.htm" target="_blank">promotion</a> to CTO, Ingenta.) </article> <article> <h1>Publishing 2.0</h1> Crossref — Thu, 29 Mar 2007 00:00:00 +0000 XML:UK is holding a one-day conference entitled titled “<a href="https://web.archive.org/web/20070630093957/http://www.xmluk.org/publishing20407.htm" target="_blank">Publishing 2.0</a>” at <a href="http://www.bletchleypark.org.uk/" target="_blank">Bletchley Park</a> on Wednesday 25th April 2007. Bletchley Park was the location of the United Kingdom’s main codebreaking establishment during the Second World War and is now a museum (and has a train station!). The event will examine some of the more cutting-edge applications of XML technology to publishing. With keynotes by Sean McGrath and Kate Warlock and a series of must-see presentations, this will be the place to be on the last Wednesday in April. </article> <article> <h1>Welcome to “Otmi-discuss”</h1> Tony Hammond — Fri, 23 Mar 2007 00:00:00 +0000 Just a quick note to mention that we’ve now set up a new mailing list <a href="https://web.archive.org/web/20070503161800/http://p8800-mailserv.crossref.org.pluma.sjfc.edu/mailman/listinfo/otmi-discuss" target="_blank">otmi-discuss@crossref.org</a> for public discussion of <a href="http:/opentextmining.org/" target="_blank">OTMI</a> - the Open Text Mining Interface proposed by Nature. See the list information page <a href="https://web.archive.org/web/20070503161800/http://p8800-mailserv.crossref.org.pluma.sjfc.edu/mailman/listinfo/otmi-discuss" target="_blank">here</a> for details on subscribing to the list and to access the mail archives. And many thanks to the Crossref folks for hosting this for us! </article> <article> <h1>XMP Capabilities Extended</h1> Tony Hammond — Thu, 22 Mar 2007 00:00:00 +0000 This <a href="https://web.archive.org/web/20070908031425/http://blogs.adobe.com/creativesolutionspr/2007/03/adobe_extends_xmp_capabilities.html" target="_blank">post</a> on Adobe’s Creative Solutions PR blog may be worth a gander: <blockquote> _“This new update, the Adobe XMP 4.1, provides new libraries for developers to read, write and update XMP in popular image, document and video file formats including: JPEG, PSD, TIFF, AVI, WAV, MPEG, MP3, MOV, INDD, PS, EPS and PNG. In addition, the rewritten XMP 4.1 libraries have been optimized into two major components, the XMP Core and the XMP Files. </blockquote> <blockquote> The XMP Core enables the parsing, manipulating and serializing of XMP data, and the XMP Files enables the reading, rewriting, and injecting serialized XMP into the multiple file formats. The XMP Files can be thought of as a “file I/O” component for reading and writing the metadata that is manipulated by the XMP Core component. </blockquote> <blockquote> Supported development environments for Adobe’s XMP 4.1 are: XCode 2.3 for Macintosh universal binaries, Visual Studio 2005 (VC8) for Windows, and Eclipse 3.x on any available platform. The XMP Core is available as C++ and Java sources with project files for the Macintosh, Windows and Linux platform. A Java version of XMP Files is under consideration for a future update.”_ </blockquote> And now I just read that last sentence again: “A Java version of XMP Files is under consideration for a future update.” So, how hard do they really want to make uptake of XMP be? Am surprised they’re even still considering offering full Java support, and not offering also anything in the way of support for glue languages such as Perl, Python, or Ruby. Which leads to the question: Is anybody here using XMP and had any success to relate or lessons for the rest of us? </article> <article> <h1>SIIA Executive FaceTime Webcast Series</h1> Anna Tolwinska — Wed, 21 Mar 2007 00:00:00 +0000 We thought that this program might interest our CrossTech bloggers. Howard Ratner, Chief Technology Officer, Executive Vice-President at Nature Publishing Group is on the agenda. More information is available at: <a href="https://web.archive.org/web/20070322234448/http://www.siia.net/" target="_blank">https://web.archive.org/web/20070322234448/http://www.siia.net/</a>. SIIA Executive FaceTime Webcast Series Howard Ratner, EVP/CTO, Nature Publishing Group Wednesday, March 28, 2007 12:00PM – 1:30PM EST The SIIA is pleased to announce that Howard Ratner of Nature Publishing Group will be our guest for the upcoming Executive FaceTime. This live webcast series features one-on-one conversations between leading industry executives and host Hal Espo. Participation is encouraged, the web audience is invited to submit questions posed through the host. Past guests include Tad Smith, CEO of Reed Business Information and L. Gordon Crovitz, EVP of Dow Jones & Company. Registration is free to SIIA members and non-members alike; to participate, you must register by the end of the day on Tuesday, March 27th. Howard Ratner Howard Ratner is Chief Technology Officer, Executive Vice-President, for the Nature Publishing Group. Based in New York, Howard is in charge of NY operations and has global responsibilities for Production and Manufacturing, Web Development, Web Services, Content Services, and Information Technology across all NPG products. Howard’s prior positions include Director, Electronic Publishing & Production for Springer-Verlag New York, as well as the North American Manager for LINK, and a member of the production staff at John Wiley & Sons. He also serves on the Crossref board, PubMed Central, CORDS and LOCKSS advisory committees, and is a former chair for both the AAP/PSP DOI subcommittee and the DOI-X project. Hal Espo Hal Espo is President of Contextual Connections, LLC, a NYC-based consultancy which focuses exclusively in the digital services arena, including digital content, distribution, and applications. Hal has more than 25 years experience as an operating executive as well as a business and product development professional in the electronic information industry. He served as Chief Operating Officer of Index Stock Imagery, Inc., a web-based commercial stock photography and illustration vendor, and previously was the Chief Operating Officer at CORSEARCH, Inc., a trademark research firm serving Fortune 500 companies and law firms. </article> <article> <h1>Agile Descriptions</h1> Tony Hammond — Tue, 20 Mar 2007 00:00:00 +0000 Apologies to blog yet another of my posts to Nascent, this time on <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2007/03/agile_descriptions_new.html" target="_blank">Agile Descriptions</a> - a talk I gave the week before last before the LC Future of Bibliographic Control WG. (Don’t worry - I shan’t be making it a habit of this.) But certain aspects of the talk (powerpoint is <a href="https://web.archive.org/web/20070630200452/http://nurture.nature.com.pluma.sjfc.edu/tony/ppt/agile-descriptions.ppt" target="_blank">here</a>) may be interesting to this readership, in particular the slides on microformats and how these are tentatively being deployed on <a href="https://web.archive.org/web/20070609090207/http://network.nature.com.pluma.sjfc.edu/" target="_blank">Nature Network</a>, and also a detailed anatomy of <a href="http://opentextmining.org/" target="_blank">OTMI</a> files. </article> <article> <h1>New-Look Web Feeds from Nature</h1> Tony Hammond — Thu, 15 Mar 2007 00:00:00 +0000 I just posted <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2007/03/nature_web_feeds_a_new_look.html" target="_blank">this entry</a> on <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/" target="_blank">Nascent</a>, Nature’s Web Publishing blog, about Nature’s new look for web feeds which essentially boils down to our using the RSS 1.0 ‘mod_content’ module to add in a rich content description for human consumption to complement our long-standing commitment to machine-readable descriptions. We are thus able to deliver full citation details in our RSS feeds as XHTML in CDATA sections for humans and as DC/PRISM properties for machines, the whole encoded in our feed format of choice - RSS 1.0. Note also that we declared our intention to publish parallel feeds in Atom which again will carry both human- and machine-readable citations. Further details on the RSS 1.0/Atom paired feeds will be posted here in the near future. Perhaps of special note we have added in the DOI in our descriptions in standard Crossref citation format and linked it to the DX resolver. </article> <article> <h1>Indexing URLs</h1> Tony Hammond — Thu, 08 Mar 2007 00:00:00 +0000 Leigh Dodds proposes <a href="http://allmyeye.blogspot.com/2007/03/persistent-linking-web-crawlers-and.html" target="_blank">in this post</a> some solutions to persistent linking using web crawlers and social bookmarking. <blockquote> “When I use del.icio.us, CiteULike, or Connotea or other social bookmarking service, I end up bookmarking the URL of the site I’m currently using. Its this specific URL that goes into their database and associated with user-assigned tags, etc. </blockquote> <blockquote> … </blockquote> <blockquote> A more generally applicable approach to addressing this issue, one that is not specific to academic publishing, would be to include, in each article page, embedded metadata that indicates the preferred bookmark link. The DOI could again be pressed into service as the preferred bookmarking link.” </blockquote> He’s inviting feedback. I’d certainly like to hear what others may think of these suggestions. </article> <article> <h1>eprintweb.org</h1> Ed Pentz — Fri, 02 Mar 2007 00:00:00 +0000 IOP has created an instance of the arXiv repository called eprintweb.org at <a href="https://web.archive.org/web/20130803071935/http://eprintweb.org/S/" target="_blank">https://web.archive.org/web/20130803071935/http://eprintweb.org/S/</a>. What’s the difference from arXiv? From the eprinteweb.org site - “We have focused on your experience as a user, and have addressed issues of navigation, searching, personalization and presentation, in order to enhance that experience. We have also introduced reference linking across the entire content, and enhanced searching on all key fields, including institutional address.” The site looks very good and it’s interesting to see a publisher developing a service directly engaging with a repository. Some interesting points to note: There are DOI links to published articles - <code>http://www.eprintweb.org/S/article/astro-ph/0603001</code> - which IOP gets from Crossref. References in the preprints are also linked - <code>http://www.eprintweb.org/S/article/astro-ph/0603001/refs</code> Crossref will soon be making available an author/title only query for repositories to use to find DOIs for published papers when the preprint doesn’t have the full citation. Many authors don’t go back to their preprints to update the reference to the published version but the new Crossref query will enable the repositories to do this automatically. </article> <article> <h1>Open Content</h1> Tony Hammond — Fri, 02 Mar 2007 00:00:00 +0000 In light of my <a href="https://www-crossref-org.pluma.sjfc.edu/blog/otmi-an-update/">earlier post</a> on OTMI, the mail copied below from Sebastian Hammer at <a href="https://web.archive.org/web/20061205050055/http://indexdata.com//" target="_blank">Index Data</a> about open content may be of interest. They are looking to compile a listing of web sources of open content - see <a href="https://www.indexdata.com/resources/open-content/" target="_blank">this page</a> for further details. (Via <a href="https://web.archive.org/web/20070430002213/http://lists.webjunction.org/mailman/listinfo/xml4lib" target="_blank">XML4lib</a> and other lists.) _“Hi All, (apologies for any cross-posting) At Index Data, we have long felt that there were really interesting sources of open content out there that was not being utilized as well as it could be because it was hidden away in websites. We’re a software company specializing in information retrieval applications, so eventually we asked ourselves, ‘what could we all do with this stuff if it were exposed using our favorite open standards’. We thought it was worth finding out, so we have set up processes to regularly retrieve indexes of major open content resources, and make them available using SRU and Z39.50. We’ve started with the Open Content Alliance and Project Gutenberg (two quite different approaches to producing free eBooks), Wikipedia, the Open Directory Project, and OAIster. More is on the way. Connection information and more details are available at <a href="https://web.archive.org/web/20070325152849/http://indexdata.com//opencontent/" target="_blank">https://web.archive.org/web/20070325152849/http://indexdata.com//opencontent/</a>. The kind of metadata you can get from these sources varies. The Open Content Alliance captures MARC records along with the scanned books, which makes for excellent metadata. Many of the others produce some variation of DublinCore. Our service, through either Z39.50 or SRU/W, exposes both MARC (or MARCXML) and DublinCore in XML for all sources. We’ve created a new mailing list to help inform people of changes to the services, new resources available, etc. Signup at <a href="http://lists.indexdata.dk/cgi-bin/mailman/listinfo/oclist/" target="_blank">http://lists.indexdata.dk/cgi-bin/mailman/listinfo/oclist/</a> . We sincerely hope you will find these resources exciting and useful. Feel free to get in touch if you have questions or input. -Sebastian — Sebastian Hammer, Index Data <a href="mailto:quinn@indexdata.com">quinn@indexdata.com</a> <a href="https://www.indexdata.com" target="_blank">www.indexdata.com</a> Ph: (603) 209-6853 Fax: (866) 383-4485”_ </article> <article> <h1>OTMI - An Update</h1> Tony Hammond — Fri, 02 Mar 2007 00:00:00 +0000 We’ve just posted an <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2007/02/open_text_mining_interface_upd.html" target="_blank">update about OTMI</a> (the Open Text Mining Interface) on our Web Publishing blog <a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/" target="_blank">Nascent</a>. This post details the following changes: <ul> <li>Contact email - <a href="mailto:otmi@nature.com">otmi@nature.com</a> <ul> <li>Wiki - <a href="http://opentextmining.org/" target="_blank">http://opentextmining.org/</a> <ul> <li> Repository - <a href="https://web.archive.org/web/20090706181310/http://www.nature.com.pluma.sjfc.edu/otmi/journals.opml" target="_blank">https://web.archive.org/web/20090706181310/http://www.nature.com.pluma.sjfc.edu/otmi/journals.opml</a> </ul> The OTMI content repository currently provides two years’ worth of full text across five of our titles: <ul> <li><a href="http://www.nature.com.pluma.sjfc.edu/nature" target="_blank">Nature</a> <ul> <li><a href="http://www.nature.com.pluma.sjfc.edu/nature" target="_blank">Nature Genetics</a> <ul> <li><a href="http://www.nature.com.pluma.sjfc.edu/nature" target="_blank">Nature Reviews Drug Discovery</a> <ul> <li><a href="http://www.nature.com.pluma.sjfc.edu/nature" target="_blank">Nature Structural & Molecular Biology</a> <ul> <li> <a href="http://www.nature.com.pluma.sjfc.edu/nature" target="_blank">The Pharmacogenomics Journal</a> </ul> See the <a href="http://opentextmining.org/" target="_blank">wiki</a> for draft technical specs and for a sample script to generate the OTMI files. And feel free to add to the wiki on existing pages or create new pages as required. We’re very much looking forward to any feedback you may have on what we consider to be a very exciting new initiative for scholarly publishers. </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </article> <article> <h1>Sir TimBL’s Testimony</h1> Tony Hammond — Fri, 02 Mar 2007 00:00:00 +0000 Just in case anybody may not have seen this, <a href="http://dig.csail.mit.edu/2007/03/01-ushouse-future-of-the-web.html" target="_blank">here</a>‘s the testimony of Sir Tim Berners-Lee yesterday before a House of Representatives Subcommittee on Telecommunications and the Internet. Required reading. (Via this <a href="https://web.archive.org/web/20070307171557/http://www.savetheinternet.com/blog/2007/03/01/world-wide-web-inventor-says-net-neutrality-a-top-priority-for-congress/" target="_blank">post</a> yesterday in the <a href="http://www.savetheinternet.com/blog/" target="_blank">Save the Internet</a> blog.) </article> <article> <h1>“Spinning Around”</h1> Tony Hammond — Fri, 23 Feb 2007 00:00:00 +0000 There’s a great exposition of <a href="http://www.ifla.org/VII/s13/frbr/frbr.htm" target="_blank">FRBR</a> (the Functional Requirements for Bibliographic Records model “work -> expression -> manifestation -> item“) in <a href="https://web.archive.org/web/20071004111040/http://www.frbr.org/2007/02/22/de-revolutionibus" target="_blank">this post</a> from <a href="http://www.frbr.org/" target="_blank">The FRBR Blog</a> on <a href="http://en.wikipedia.org/wiki/De_revolutionibus_orbium_coelestium" target="_blank">De Revolutionibus</a> as described in The Book Nobody Read: Chasing the Revolutions of Nicolaus Copernicus by Owen Gingerich. See post for the background and <a href="https://web.archive.org/web/20070705095508/http://www.frbr.org/files/frbrevolutionibus.png" target="_blank">here (103 KB PNG)</a> for a map of the FRBR relationships. (Yes, and a twinkly star in the title too. ;~) </article> <article> <h1>Kay Sera Sera</h1> Crossref — Tue, 20 Feb 2007 00:00:00 +0000 Not specifically publishing-related, but here is a fun <strike>rant </strike><a href="http://www.cioinsight.com/print_article2/0,1217,a=200162,00.asp" target="_blank">interview</a> with <a href="http://en.wikipedia.org/wiki/Alan_Kay" target="_blank">Alan Kay</a> titled The PC Must Be Revamped—Now. My favorite bit… “…in the last few years I’ve been asking computer scientists and programmers whether they’ve ever typed E-N-G-E-L-B-A-R-T into Google-and none of them have. I don’t think you could find a physicist who has not gone back and tried to find out what Newton actually did. It’s unimaginable. Yet the computing profession acts as if there isn’t anything to learn from the past, so most people haven’t gone back and referenced what Engelbart thought. ” </article> <article> <h1>“We’re sorry…”</h1> Tony Hammond — Mon, 19 Feb 2007 00:00:00 +0000 Update: All apologies to Google. Apparently this was a problem at our end which our IT folks are currently investigating. (And I thought it was just me. 🙂 Just managed to get this page: _“Google Error We’re sorry… … but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, we can’t process your request right now. We’ll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected, you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software. We apologize for the inconvenience, and hope we’ll see you again on Google. To continue searching, please type the characters you see below:”_ And my search request? <tt>ark</tt> (Actual query is <a href="http://www.google.com/sorry/?continue=http://www.google.com/search%3Fclient%3Dfirefox-a%26rls%3Dorg.mozilla%253Aen-US%253Aofficial%26channel%3Ds%26hl%3Den%26q%3Dark%26btnG%3DGoogle%2BSearch" target="_blank">here</a> as argument to the <tt>continue</tt> parameter.) Was hoping to find results related to the <a href="http://www.ietf.org/internet-drafts/draft-kunze-ark-12.txt" target="_blank">The ARK Persistent Identifier Scheme</a>. Maybe I missed something but I’m not impressed. </article> <article> <h1>At Last! URIs for InChI</h1> Tony Hammond — Mon, 19 Feb 2007 00:00:00 +0000 The <a href="http://info-uri.info/" target="_blank">info registry</a> has now added in the <a href="http://iupac.org/inchi/" target="_blank">InChI</a> namespace (see registry entry <a href="http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:inchi/" target="_blank">here</a>) which now means that chemical compounds identified by InChIs (<a href="http://iupac.org/" target="_blank">IUPAC</a>‘s International Chemical Identifiers) are expressible in URI form and thus amenable to many Web-based description technologies that use URI as the means to identify objects, e.g. XLink, RDF, etc. As an example, the InChI identifier for <a href="http://en.wikipedia.org/wiki/Naphthalene" target="_blank">naphthalene</a> is InChI=1/C10H8/c1-2-6-10-8-4-3-7-9(10)5-1/h1-8H and can now be legitimately expressed in URI form as info:inchi/InChI=1/C10H8/c1-2-6-10-8-4-3-7-9(10)5-1/h1-8H The info URI scheme exists to support legacy namespaces get a leg up onto the Web. Registered namespaces include PubMed identifiers, DOIs, handles, ADS bibcodes, etc. Increasingly we’ll be expecting to see identifiers (both new and old) represented in a common form - URI. </article> <article> <h1>Stick this in your pipe…</h1> Crossref — Mon, 19 Feb 2007 00:00:00 +0000 <a href="http://www2.blogger.com/profile/12568103499947976875" target="_blank">Rob Cornelius</a> has a <a href="http://allmyeye.blogspot.com/index.html" target="_blank">practical little demo</a> of using Yahoo! pipes against some Ingenta feeds. Like Tony, I keep experiencing speed/stability problems while accessing pipes so I haven’t yet become a <a href="http://www.researchbuzz.org/wp/2007/02/12/yahoo-ruins-my-life-with-yahoo-pipes/" target="_blank">crack-pipes-head</a>. </article> <article> <h1>OpenURL Podcast</h1> Tony Hammond — Sat, 17 Feb 2007 00:00:00 +0000 Jon Udell interviews <a href="https://web.archive.org/web/20070114212828/http://curtis.med.yale.edu/dchud/" target="_blank">Dan Chudnov</a> about <a href="https://web.archive.org/web/20070206165948/http://www.niso.org/standards/standard_detail.cfm?std_id=783" target="_blank">OpenURL</a>, see his <a href="http://blog.jonudell.net/2007/02/16/a-conversation-with-dan-chudnov-about-openurl-context-sensitive-linking-and-digital-archiving/" target="_blank">blog entry</a>: “A conversation with Dan Chudnov about OpenURL, context-sensitive linking, and digital archiving”. The podcast of the interview is available <a href="http://jonudell.net/podcast/ju_chudnov.mp3" target="_blank">here</a>. Interesting to see these kind of subjects beginning to be covered by a respected technology writer like Jon. As he says in his post: <blockquote> “I have ventured into this confusing landscape because I think that the issues that libraries and academic publishers are wrestling with — persistent long-term storage, permanent URLs, reliable citation indexing and analysis — are ones that will matter to many businesses and individuals. As we project our corporate, professional, and personal identities onto the web, we’ll start to see that the long-term stability of those projections is valuable and worth paying for.” </blockquote> </article> <article> <h1>OpenDocument 1.1 is OASIS Standard</h1> Tony Hammond — Thu, 15 Feb 2007 00:00:00 +0000 From the OASIS <a href="https://web.archive.org/web/20070219093602/https://www.oasis-open.org/news/oasis-news-2007-02-14.php" target="_blank">Press Release</a>: <blockquote> “Boston, MA, USA; 13 February 2007 — OASIS, the international standards consortium, today announced that its members have approved version 1.1 of the Open Document Format for Office Applications (OpenDocument) as an OASIS Standard, a status that signifies the highest level of ratification.” </blockquote> </article> <article> <h1>Crossref Author ID meeting</h1> Amy Brand — Wed, 14 Feb 2007 00:00:00 +0000 February 5, 2007, Washington DC Crossref invited a number of people to attend an information gathering session on the topic of Author IDs. The purpose of the meeting was to determine: <ul> <li> About whether there is an industry need for a central or federated contributor id registry; </li> <li> whether Crossref should have a role in creating such a registry; </li> <li> how to proceed in a way that builds upon existing systems and standards. </li> </ul> In attendance: Jeff Baer, CSA; Judith Barnsby, IOPP; Geoff Bilder, Crossref; Amy Brand, Crossref; David Brown, British Library; Richard Cave, PLoS (remote); Bill Carden, ScholarOne; Gregg Gordon, SSRN; Gerry Grenier, IEEE; Michael Healy, BISG (remote); Helen Henderson, Ringgold; Thomas Hickey, OCLC (remote); Terry Hulburt, IOPP; Tim Ingoldsby, AIP; Ruth Jones, Britsh Library; Marl Land, Parity; Dave Martinson, ACS; Georgios Papadapoulos, Atypon (with two colleagues); Jim Pringle, Thomson; Chris Rosin, Parity; Tim Ryan, Wiley; Philippa Scoones, Blackwell; Chris Shillum, Elsevier; Neil Smalheiser, UIC (remote); Barbara Tillett, LoC; Vetle Torvik, UIC (remote); Charles Trowbridge, ACS; Amanda Ward, Nature (remote); Stu Weibel, OCLC (remote); David Williamson, LoC; Notes Amy Brand opened the meeting and welcomed attendees. She said the goal of the meeting was really nothing more than to launch a discussion on a topic of author identifiers and hear from participants re their views and experiences on unique identifiers for individuals — be they authors, contributors, or otherwise. We went around the table and everyone introduced themselves. Amy then introduced Geoff Bilder as moderator of the meeting. Geoffrey Bilder said that Crossref’s members had indicated that they would like Crossref to explore whether it could play a role in creating an author identification system. The members feel that an “author DOI” scheme would help them with production and editorial issues. They also recognize that such a scheme could fuel numerous downstream applications. Geoff apologized for sounding like Rumsfeld and said, we know that there is a lot that we don’t know, but we don’t know exactly what we don’t know. We have just started this project and we wanted to get some feedback from various groups concerned with scholarly publishing in order to understand what people would like to see in regards to author identification schemes and what initiatives/efforts we need to be aware of. He commented that the currently assembled group failed to include the open web community, and their input would be important too as this project develops. The meeting then turned to short project summaries from others. Project Summaries Jim Pringle gave a short PPT presentation (attached) and reported that Thomson first started creating its own author ids in 2000, in relation to the launch of its Highly Cited service. The focus for Thomson in this area has been on author disambiguation. Jim said that the focus for Crossref in this area would be a system that could respond to the question “who are you and what have you written”; he also raised concern about matters of author privacy. Michael Healy then discussed the <a href="https://web.archive.org/web/20070611181723/http://collectionscanada.ca/iso/tc46sc9/27729.htm" target="_blank">International Standard Party Identifier</a> (ISPI). ISO TC 46/SC 9 is developing ISPI as a new international identification system for the parties (persons and corporate bodies) involved in the creation and production of content entities. Work on the ISPI project began in August 2006 when the New Work Item proposal was approved by the member bodies of ISO TC 46/SC 9. The first meeting of the ISPI project group was held at CISAC’s offices in Paris on September 12, 2006. This project has strong representation the library sector, RRO’s, booksellers, music and film/TV industries represented as well. Mr. René Lloret Linares from CISAC (International Confederation of Societies of Authors and Composers) chairs the group; until now CISAC has been using a proprietary id scheme and would like to move to use of an open standard to identify all contributors and creators. Michael was asked whether membership in the project group was open, and he replied that anyone can attend meetings as observers but that voting is restricted to those nominated by their own national standards organisation. Chris Shillum then asked the group to think about developed use cases for the publishing industry, and how they differ from potential ISPI applications. Helen Henderson reported on the <a href="https://web.archive.org/web/20071212133049/https://web.archive.org/web/20060904075439/http://www.journalsupplychain.com/" target="_blank">Journals Supply Chain project</a>, a pilot that aims to discover whether the creation of a standard, commonly used identifier for Institutions (customer ids) will be beneficial to parties involved in the journal supply chain. The pilot models interactions between each party — library, publisher, agent. 35 publishers are participating thus far. Helen also said there is a clear need for sub-institutional level ids. Helen also pointed out the value of associating author and institutional ids. On the topic of institutions, Tim Ingoldsby pointed out that both academic and corporate institutions are important. Chris Rosin said Parity is working on author merger and disambiguation as core use cases of author ids for its publisher clients. In particular, they have developed automated merging of instances into profiles, proceeding with conservative bias on what constitutes a match/merge. Parity is also looking at applying author cv’s onto profiles. This will require contributors to participate, and they will need to make it as easy as possible for contributors. Chris said that authentication, trust, and privacy are key considerations; even collecting public information in one place raises privacy issues. Judith Barnsby pointed out that the UK has stronger data protection rules than the US, re privacy. Discussion among the group at this point in the meeting resulted in identifying two different areas in author id assignment — (1) ongoing assignment, (2) retroactive assignment. Geoff said this distinction was useful for Crossref, who could more easily address ongoing assignment via publishers working directly with authors. Neil Smalheiser, a neuroscientist at UIC, reported on the <a href="http://arrowsmith.psych.uic.edu/arrowsmith_uic/index.html" target="_blank">Arrowsmith Project</a>, a statistical model based on multiple features of the Medline database. The goal of the model is to predict the probability that any two papers are written by the same person. The project’s “Authority” tool weighs criteria such as researcher affiliation, co-author names, journal title, and medical subject headings to identify the papers most likely written by a target author. For details: arrowsmith.psych.uic.edu/arrowsmith_uic/index.html <a href="http://arrowsmith.psych.uic.edu/arrowsmith_uic/index.html" target="_blank">http://arrowsmith.psych.uic.edu/arrowsmith_uic/index.html</a> David Williamson of LoC said he was working on name authority files, using ONIX metadata. Barbara Tillet of LoC spoke about authority files and related efforts in library world, which uses the control number, one type of unique id. She reported that IFLA (International Federation of Library Associations) has a group working on how to share authority numbers, which has actually been in discussion since the 1970s; there is to be an IFLA-IPA meeting in April 2007. The library community is eager to share what it knows and what it has developed this far. Barbara suggested that use of Dublin Core format here may be the best way to go. Different communities will no doubt need different ids. What is needed in the library community is an international, multi-lingual solution, based on unicode, connecting regional authority files. Publishers will want to take advantage of library author-ity files for retrospective identifications. Thomas Hickey of OCLC mentioned the <a href="https://www-worldcat-org.pluma.sjfc.edu/identities/" target="_blank">WorldCat Identity service</a>, which summarizes information for 20 million authors searchable in WorldCat. Gerry Grenier reported that IEEE was about to implement its own author disambiguation and id system, and he offered that this metadata could be fed into a Crossref system. Different participants had different views on whether the goal here should be a “light and non-centralized” (or federated) approach versus a centralized registry with one place to link authors across all publishers, versus a hybrid — centralized source to handout unique id, but publisher data could be distributed. There could also be a network of registration agencies working in a federated system. Different participants also had different views on Crossref’s role. Several publishers at the meeting supported Crossref’s role, especially in the STM space, whereas there was concern raised among some parties about whether Crossref was an appropriate choice for a system that will need to be “available everywhere to everybody”, and others re-iterated the importance of giving the academic community a voice in the development of such a service Discussion then turned to use cases — the question being, what problems would having an author id help you solve in your organisation? USE CASES ARTICULATED AT MEETING: <ul> <li> For RROs, known use case is to facilitate distribution of monies owed to authors;; </li> <li> for booksellers, disambiguation in search;; </li> <li> to understand the provenance of documents; </li> <li> search — to find works for particular person; self presentation — how can I effectively present myself and my work to the world?; </li> <li> cross-walks — associating various life sciences ids, such as PubChem; </li> <li> identity of society members; </li> <li> identity of research funding institutions; </li> <li> disambiguation and attribution; </li> <li> linking authors and institutions; </li> <li> for enhancing peer review system — need unique ids to share information with various departments; </li> <li> to better know the value of our authors — for activities such as peer review, tracking stats on authors, article downloads, and individualized or personalized services; </li> <li> with a central registry, author only has one place they have to update their information; </li> <li> authors will want the information to be portable when they move from inst to another — “where is Jeff Smith now?” is one such question; </li> <li> to associate connected authors with one another; </li> <li> to aggregate info on where (what institution) research is being done on a particular topic; </li> <li> privacy can be enhanced with author DOIs; </li> <li> sharing info from library to library; </li> <li> cluster all the works of a particular person for search purposes; </li> <li> stats about authors — “how many times has this author tried and been rejected from Nature?” for instance. </li> </ul> **NEXT STEPS: Please watch the CrossTech blog for ongoing discussion ** </article> <article> <h1>Microsoft to Support OpenID</h1> Crossref — Thu, 08 Feb 2007 00:00:00 +0000 Kim Cameron, Microsoft’s Identity Czar and member of the <a href="https://web.archive.org/web/20070826193937/http://www.identitygang.org/" target="_blank">Identity Gang</a>, <a href="http://www.identityblog.com/?p=668" target="_blank">comments on</a> Microsoft’s announcement that they will support <a href="http://openid.net/" target="_blank">OpenID</a>. Another sign that <a href="http://en.wikipedia.org/wiki/Federated_identity" target="_blank">federated identity</a> schemes are gaining traction and OpenID is likely to emerge as a standard the publishers are going to want to grapple with soon. This follows Doc Searl’s comments on the notion of “<a href="http://www.linuxjournal.com/node/1000180" target="_blank">Creator Relationship Management</a>” where he speculates that the techniques being used in federated identity schemes and the Creative Commons can be combined to create a new “silo-free” value chain amongst creators, producers and distributors. </article> <article> <h1>Remixing RSS</h1> Tony Hammond — Thu, 08 Feb 2007 00:00:00 +0000 Niall Kennedy has a <a href="http://www.niallkennedy.com/blog/archives/2007/02/yahoo-pipes.html" target="_blank">post</a> about the newly released <a href="https://www.pipes.digital/" target="_blank">Yahoo! Pipes</a>. As he says: <blockquote> “Yahoo! Pipes lets any Yahoo! registered user enter a set of data inputs and filter their results. You might splice a feed of your latest bookmarks on del.icio.us with the latest posts from your blog and your latest photographs posted to Flickr.” </blockquote> He also warns about possible implications for web publishers: <blockquote> “Yahoo! Pipes makes it easy to remove advertising from feeds or otherwise reformat your content.” </blockquote> Note: As yet, I have not been able to access the site. Interested to learn if anybody else has and what their experiences have been. </article> <article> <h1>RSS Validator in the Spotlight</h1> Tony Hammond — Thu, 08 Feb 2007 00:00:00 +0000 Sam Ruby <a href="http://www.intertwingly.net/blog/2007/02/07/Validating-the-Validators" target="_blank">responds</a> to Brian Kelly’s <a href="http://ukwebfocus.wordpress.com/2007/02/07/validators-dont-always-work/" target="_blank">post</a> about the <a href="http://feedvalidator.org/" target="_blank">RSS Validator</a> and its treatment of RSS 1.0, or rather, RSS 1.0 modules. As Ruby notes: <blockquote> “There is no question that RSS 1.0 is widely deployed. <a href="http://web.resource.org/rss/1.0/" target="_blank">RSS 1.0</a> has a <a href="http://www.intertwingly.net/slides/2003/rssQuickSummary.html" target="_blank">minimal</a> core. The validation for that core is pretty solid.” </blockquote> Not sure if I’d seen that <a href="http://www.intertwingly.net/slides/2003/rssQuickSummary.html" target="_blank">RSS comparison table</a> before, but it is reassuring. (Oh, and see the really simple case off to the right. 😉 Good point, anyway about contributing test cases. I guess we should really submit a PRISM test case. And yes, the Validator is somewhat buggy as some recent testing confirms. On which more later. </article> <article> <h1>SearchULike</h1> Tony Hammond — Mon, 05 Feb 2007 00:00:00 +0000 Nelson Minar has a short <a href="http://www.somebits.com/weblog/tech/bad/googleSearchHistory.html" target="_blank">post</a> on Google’s <a href="http://www.google.com/searchhistory" target="_blank">Search History</a> ‘feature’ and how it can be used to enhance your search experience. I guess that should be SearchULike. </article> <article> <h1>What’s My Link?</h1> Tony Hammond — Mon, 05 Feb 2007 00:00:00 +0000 Simon Willison has a great piece <a href="https://web.archive.org/web/20070205131629/http://simonwillison.net/2007/Feb/4/urls/" target="_blank">here</a> about disambiguating URLs. Best practice on creating and publishing URLs is obviously something of interest to any publisher. See this excerpt from Simon’s post: _“Here’s a random example, plucked from today’s del.icio.us popular. convinceme.net is a new online debating site (tag clouds, gradient fills, rounded corners). It’s listed in del.icio.us a total of four times! <ul> <li> <a href="https://web.archive.org/web/20070203050251/http://www.convinceme.net/" target="_blank">https://web.archive.org/web/20070203050251/http://www.convinceme.net/</a> has 36 saves </li> <li> <a href="https://web.archive.org/web/20070202182238/http://www.convinceme.net/index.php" target="_blank">https://web.archive.org/web/20070202182238/http://www.convinceme.net/index.php</a> has 148 saves </li> <li> <a href="https://web.archive.org/web/20070203050251/http://www.convinceme.net/" target="_blank">https://web.archive.org/web/20070203050251/http://www.convinceme.net/</a> has 211 saves </li> <li> <a href="https://web.archive.org/web/20070202182238/http://www.convinceme.net/index.php" target="_blank">https://web.archive.org/web/20070202182238/http://www.convinceme.net/index.php</a> has 38 saves </li> </ul> Combined that’s 433 saves; much more impressive, and more likely to end up at the top of a social sharing sites.”_ </article> <article> <h1>comments and trackbacks</h1> Ed Pentz — Fri, 02 Feb 2007 00:00:00 +0000 Due to spam the comments and trackbacks were turned off on the blog since last week. Comments can be moderated so they have now been turned back on. Glad to see postings picking up. </article> <article> <h1>Hooray!</h1> Tony Hammond — Fri, 02 Feb 2007 00:00:00 +0000 Somebody is both reading (and recommending) this blog - see Lorcan’s post <a href="http://orweblog.oclc.org.pluma.sjfc.edu/archives/001257.html" target="_blank">here</a>. Just my opinion but would be really good to see more librarians following this in order to arrive at better consensus. </article> <article> <h1>RSC launches semantic enrichment of journal articles</h1> rkidd — Thu, 01 Feb 2007 00:00:00 +0000 The RSC has gone live today with the results of <a href="https://web.archive.org/web/20070812060042/http://www.rsc.org.pluma.sjfc.edu/Publishing/Journals/ProjectProspect/index.asp" target="_blank">Project Prospect</a>, introducing semantic enrichment of journal articles across all our titles. I’m pretty sure we’re the first primary research publisher to do anything of this scope. We’re identifying chemical compounds and providing synonyms, InChIs (IUPAC’s Chemical Identifier), downloadable CML (Chemical Markup Language), SMILES strings and 2D images for these compounds. In terms of subject area we’re marking up terms from the IUPAC Gold Book, and also Open Biomedical Ontology terms from the Gene, Cell, and Sequence Ontologies. All this stuff is currently available from an enhanced HTML view, with the additional information and links to related articles accessed via highlights in the article and popups. The mark-up tools have been developed together with UK academics based at the Unilever Centre of Molecular Informatics and the Computing Laboratory at Cambridge University. At launch we have about 100 articles from our 2007 publications, with the enhanced views currently free-to-air. Feel free to take a look. </article> <article> <h1>Digital Objects</h1> Tony Hammond — Tue, 30 Jan 2007 00:00:00 +0000 A couple weeks back there was a meeting of the <a href="http://www.openarchives.org/" target="_blank">Open Archive Initiative</a>‘s Object Reuse and Exchange (<a href="http://www.openarchives.org/ore/" target="_blank">OAI-ORE</a>) Technical Committee hosted in the Butler Library at Columbia University, New York. Lorcan Dempsey of OCLC blogs <a href="http://orweblog.oclc.org.pluma.sjfc.edu/archives/001254.html" target="_blank">here</a> on the <a href="http://www.openarchives.org/ore/documents/OAI-ORE-TC-Meeting-200701.pdf" target="_blank">report</a> (PDF format) that was generated from that meeting. As does Pete Johnston of Eduserv <a href="http://efoundations.typepad.com/efoundations/2007/01/more_ore.html" target="_blank">here</a>. Background: <a href="http://www.openarchives.org/ore/" target="_blank">OAI-ORE</a> is being positioned as a companion activity to the more familiar <a href="http://www.openarchives.org/pmh/" target="_blank">OAI-PMH</a> protocol for metadata harvesting. OAI-ORE relates to the expression and exchange of digital objects across repositories rather than just the exchange of metadata about those objects. The basic problem is that scholarly communication deals in units which are compound resulting from a complex of documents and/or datasets expressed in multiple formats, versions, relationships, etc. The underlying web architecture provides a fairly simple model of resources (identified with URIs) which are interconnected and can be interacted with by retrieving representations of those resources. In practice, this usually results in unique URIs (and thus resources) for each representation - think of one URI for an HTML document, another for a PDF document of the same work, and yet new URIs for those same document formats for a new version of the work. Clearly, all these representations (or documents) are related, and more importantly relate to a single underlying “work”. Web architecture as generally practiced does not provide ready mechanisms to aggregate (and compartmentalize) related documents and datasets. My fairly simple mental picture is that the web landscape is rather like the early universe in which energy (and matter) is distributed uniformly and there is little local “intelligence” which is gradually built up through time by matter formation and aggregations of this matter leading to the more familiar “clumpy” universe with its recognizable galaxies, stars and other objects. This “clumpiness” is precisely what we are missing in the scholarly web. </article> <article> <h1>An Open PDF?</h1> Tony Hammond — Mon, 29 Jan 2007 00:00:00 +0000 Adobe announces today the following: “SAN JOSE, Calif. — Jan. 29, 2007 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced that it intends to release the full Portable Document Format (PDF) 1.7 specification to AIIM, the Enterprise Content Management Association, for the purpose of publication by the International organisation for Standardization (ISO).” The full press release is <a href="https://web.archive.org/web/20070202072839/http://www.adobe.com/aboutadobe/pressroom/pressreleases/200701/012907OpenPDFAIIM.html" target="_blank">here</a>. (Via <a href="http://www.tkachenko.com/blog/archives/000657.html" target="_blank">Oleg Tkachenko’s Blog</a>.) </article> <article> <h1>Jon Udell and DOIs</h1> Crossref — Mon, 29 Jan 2007 00:00:00 +0000 Not to get too self-referential here, but it was very cool to see that Tony Hammond has managed to get <a href="http://blog.jonudell.net/2007/01/29/the-persistent-blogosphere/" target="_blank">Not to get too self-referential here, but it was very cool to see that Tony Hammond has managed to get</a> This based on a <a href="http://blog.jonudell.net/2007/01/26/a-conversation-with-tony-hammond-about-digital-object-identifiers/" target="_blank">podcast</a> interview with Tony posted on January 26th. </article> <article> <h1>W3C Recs for XML - Eight of ‘Em!</h1> Tony Hammond — Thu, 25 Jan 2007 00:00:00 +0000 Although most folks will already know about this it still seems significant enough to blog the arrival of XQuery 1.0, XSLT 2.0, and XPath 2.0. See the <a href="http://www.w3.org/2007/01/qt-pressrelease" target="_blank">W3C Press Release</a>. </article> <article> <h1>Use of PRISM in RSS</h1> Tony Hammond — Tue, 23 Jan 2007 00:00:00 +0000 Was rooting around for some information and stumbled across this page which may be of interest: <a href="http://googlereader.blogspot.com/2006/08/namespaced-extensions-in-feeds.html" target="_blank">http://googlereader.blogspot.com/2006/08/namespaced-extensions-in-feeds.html</a> Namespaced Extensions in Feeds Thursday, August 03, 2006 posted by Mihai Parparita “I wrote a small MapReduce program to go over our BigTable and get the top 50 namespaces based on the number of feeds that use them.”<table border=0 cellpadding="5"> </table> Seems quite an impressive percentage for PRISM. </article> <article> <h1>What’s in a URI?</h1> Tony Hammond — Mon, 08 Jan 2007 00:00:00 +0000 First off, a Happy New Year to all! A <a href="https://web.archive.org/web/20130903193049/https://utils.its.caltech.edu/pipermail/openurl/2007-January/000376.html" target="_blank">post of mine</a> to the <a href="https://web.archive.org/web/20130903202546/https://utils.its.caltech.edu/mailman/listinfo/openurl" target="_blank">OpenURL list</a> may possibly be of interest. Following up the recent W3C TAG (Technical Architecture Group) Finding on “The Use of Metadata in URIs” I pointed out that the TAG do not seem to be aware of OpenURL: which is both a standard prescription for including metadata in URI strings and a US information standard to boot. </article> </main></body></html>