On Jan 20, 2015, at 3:05, Jodi Schneider <[email protected]> wrote: >> From: Herbert Van de Sompel <[email protected]> >> Date: Mon, 19 Jan 2015 18:10:45 -0700 >> Message-Id: <[email protected]> >> Cc: "[email protected]" <[email protected]> >> To: Larry Masinter <[email protected]> >> >> Larry >> How about HTTP Link headers (RFC 5988) to convey links and metadata >> expressed as links when serving PDFs? I can imagine an authoring tool >> embedding the info in XMP. But I have a harder time imagining a consumer >> application that would want to read the info via XMP. > > I don't: Bibliographic managers for PDFs could make use of XMP metadata. > Imagine never typing another citation again!
I thought bibliographic managers already did. If I remember correctly, some STM publishers did stuff metadata in XMP containers at one point. And I would have thought that bibliographic managers would then have used that. It would be telling if they didn't. But, anyhow, I admit my above sentence wasn't all that clear. I was really expressing my doubt that an "on web" Linked Data aggregating tool would start doing something special when encountering a PDF: pulling it across and then check whether anything interesting was in an XMP container. In my below proposal, an HTTP HEAD (needed anyhow to figure out whether a resource is a PDF) would suffice to obtain the links if they were provided in the HTTP Link header. Using IANA-registered relation types, those links would end up being a bit generic but they would be readily available. And rather easily transformable into RDF. Cheers Herbert > >> How about a web server add-on that can extract (and map/transform.) the info >> from the XMP container as the PDF is being served. And stuff it all in the >> HTTP Link header on the fly. > > This of course is a good idea but I don't think it's either/or. > > -Jodi > >> Cheers >> Herbert > >
