[Ref-Links] Do you need to know content-type?

[Eric Hellman <eric@hellman.net>]

In designing the metadata for SLinkS (http://www.openly.com/SLinkS/) I made
a conscious decision not to provide a field for describing  available
content-type, in other words, html vs. pdf vs. RealPage vs. xml vs. TeX vs.
PostScript.

I'd like to ask the newly constituted list for a reality-check: Are there
any situations in which a linking application REALLY has to have a
content-type field in journal-level metadata?

The argument against is as follows.

1. A reference link to a scholarly article ought to first resolve to an
HTML page, at least in 1999. A user (or a browser-agent) can then select
from multiple formats, if they exist.

2. There are better ways to determine content-type: HTTP MIME headers,
filename extensions.

3. If a content-type in the metadata conflicts with the MIME header
content-type, what is an application to do?

4. What about servers which produce dynamic content using HTTP content-type
negotiation?

5. A publisher may provide separate reference links for separate
content-type internally, but they are unlikely to use journal-level
metadata for this purpose.

6. Content-type is very likely to be non-uniform at the journal level.
Different volumes often have different content-types available.

7. RDF can include content-type metadata using vocabulary in other namespaces.

8. K.I.S.S.

Comments?

Eric

PS I posted the latest version of SLinkS last week.

Eric Hellman, President                            Openly Informatics, Inc.
eric@openly.com                                    10 Columbus Ave., Suite C
tel/fax 1-973-509-7800                             Montclair, NJ 07042
Tools for 21st Century Scholarly Publishing        http://www.openly.com/

------------------------------------------------------
Ref-Links maillist  -  Ref-Links@doi.org
http://www.doi.org/mailman/listinfo/ref-links