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".

-Ross.

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.

Ed

On 1/24/06, C. Hudley <[EMAIL PROTECTED]> wrote:
On 1/24/06, Tantek Çelik <[EMAIL PROTECTED]> wrote:
On 1/24/06 12:50 PM, "Ed Summers" <[EMAIL PROTECTED]> 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 *web*.

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 the
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.

http://microformats.org/discuss/mail/microformats-discuss/2006- January/002781.html

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 typically
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
out.

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 "link
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. :)

  -ch.

--
C. Hudley
We Know The Truth, Inc.
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss



--
Edward Vielmetti in Ann Arbor, MI 48104
+1 734 276 5910

[EMAIL PROTECTED]
http://www.vacuumgroup.com
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to