[uf-discuss] citation microformat encodings
ross.singer at library.gatech.edu
Wed Jan 25 04:58:58 PST 2006
Avoiding a "standards process that runs on four year cycle" on
principle won't get you very far, I'm afraid. Any large scale spec
that needs to account for a wide swath of scenarios and possibilities
is going to take a while to develop; especially when those drafting it
aren't working on it full-time.
The first version of the spec was done in a much shorter period of time
and had real scalability issues. Just sayin'...
In regards to your local (public) library not running one of these
"link resolver" thingamabobs, that's hardly an excuse not find value in
the technology. It's only a matter of time before all libraries have a
link resolver of some sort. The rise of electronic resources has
basically rendered the link resolver as important as the catalog.
There are logical reasons that you find it currently at the academic
level, rather than the public library level - the bread and butter of
link resolvers (and, indeed, citations and scholarly research) is in
journal articles. This is a much larger part of a university library
budget than a public library's.
However, the state of Georgia will be rolling out link resolving for
all citizens (colleges, public libraries, K-12) this year, so the trend
is certainly moving "down the library food chain".
On Jan 24, 2006, at 9:06 PM, Edward Vielmetti wrote:
> Is there an openly available spec for OpenURL?
> It doesn't sound awful, though any standard process
> that runs on a four year cycle is one I try to avoid.
> My local (public) library does not run one of these
> "link resolver" thingamabobs, though the local
> University does. So OpenURLs are not really that
> useful to me to help me decide whether I can get
> an item. I suppose if there were a simple link
> resolver that only knew about the simplest kind
> of links (e.g. only ISBNs) I could make it a Greasemonkey
> thing and run without an intervening server.
> On 1/24/06, C. Hudley <chudley at gmail.com> wrote:
>> On 1/24/06, Tantek Çelik <tantek at cs.stanford.edu> wrote:
>>> On 1/24/06 12:50 PM, "Ed Summers" <ehs at pobox.com> wrote:
>>>> I must admit to feeling a bit confused about how to proceed. Could
>>>> those of us who are interested in seeing openurl components in a
>>>> microformat create some pages that illustrate how it could be used?
>>>> Would this confuse current efforts or add to them?
>>> The key point missing is this.
>>> Microformats are based FIRST on human publishing *behaviors* on the
>>> And ONLY THEN do we look at what previous attempts at formats have
>>> done to
>>> see if they can help address the problem that has been specified by
>>> examples documented from the Web.
>> Fair enough - it says as much on the wiki. But, was vcard being
>> published as such on the web? What's confusing me is the point at
>> which folks become willing to translate a non-web spec to an hSpec.
>> Did you go through the whole process translating vCard into hCard? Or
>> iCal and hCal? Or were these short-circuited somehow because doing so
>> was obviously a good idea?
>> If you did follow the whole process both times, it seems totally fair
>> to go through the whole process for translating OpenURL profiles to
>> hCitations, or wherever else the process might lead. And tell us so,
>> and we'll study the list archives etc. and get smarter quickly to make
>> sure we can help more at every step.
>> If you didn't go through the whole process, then I have a different
>> question to ask. :)
>>> Existing formats are most useful for the
>>> terms and vocabulary they have chosen.
>>> One point on OpenURL - as far as I can tell, all the information
>>> about the
>>> citation is captured in the URL.
>> Did you see the recent examples posted here that pull the OpenURL
>> profile fields into html classes? We have translated the OpenURL book
>> and journal citation profile keys into HTML class attribute values.
>> Note the class name pattern, aside from the COinS bit (the Z3988 class
>> value title element, which essentially replicates the more obvious
>> class attribute values). Would it be appropriate for us to put those
>> examples into citation-brainstorming?
>>> The problem is that this is NOT the way people publish citations
>>> on the web.
>> We could litter the wiki with 76 different examples of how journal
>> publishers mark up HTML for citations. They are all inconsistent and
>> incompatible. Because of that, they mostly also use OpenURL to link
>> Assuming you don't really want 76 different examples, we could pull
>> out a handful
>> of these that are better than others. Some are already there.
>> Forgive us for a bit of frustration, having worked through years of
>> inconsistent journal publishing patterns in the 1990s, and then a
>> four-year standards-setting process for OpenURL (which formally came
>> out in 2004), and then having to start over again here. We're willing
>> to work through the process, it just isn't clear what barrier must be
>> crossed before it might be even possible for somebody to consider that
>> "perhaps this problem is already solved, maybe we could translate the
>> answer." Or if there is, indeed, no shortcut.
>>> In short, OpenURL is *not* human friendly and does not convey human
>>> *visible* information. In addition, by its dependency on a specific
>>> server" in order to be of any use at all, it does not encourage
>>> *decentralized* development.
>> Neither is vCard, nor iCal, human friendly. We know!
>> That's why we're here. We have been working for two years to free
>> OpenURL from the dependency from specific link servers and we want it
>> to be useful for decentralized development, and microformats are
>> obviously the best place to be for both. :)
>> C. Hudley
>> We Know The Truth, Inc.
>> microformats-discuss mailing list
>> microformats-discuss at microformats.org
> Edward Vielmetti in Ann Arbor, MI 48104
> +1 734 276 5910
> edward.vielmetti at gmail.com
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss