Benjamin Young wrote:
Additionally (as someone outside of the library community proper),
OpenURL's dependence on resolvers would be the largest concern.
This is a misconception. An OpenURL context object can be created to
provide structured semantic citation information, without any dependence
on a resolver. Just as a way of serializing structured semantic
citation information in a standard way.
This is basically what COinS does.
Now, the largest concern with OpenURL to me is actually just that it's
way harder to understand and work with than it should be to meet it's
primary use cases, and that means trying to use it as a standard for a
new use case is probably asking for trouble in "adoption curve".
So here are the questions, my own summary analysis of this thread:
1. What are the citations you think users would want to attach to a
tweet?
a. Will they ALL have standard identifiers that can be expressed as
some form of URI (ISBN, DOI, etc).
b. Or are there an important enough subset of citations that will
NOT have standard identifiers that you still want to support?
If you choose 'a' above, then the solution to me seems clear: Simply
attach a URI as your 'citation metadata' -- be willing to use "info:"
URIs for ISBNs, ISSNs, LCCNs, OCLCnums, DOIs. It should be clearly
identified as "identifier for thing cited by this tweet" somehow, but
the 'payload' is just a URI. [ I know some people don't like
non-resolvable info: URIs. I like em, and THIS use case shows why. It
allows you to attach an ISBN to a tweet as a URI right now today,
keeping your metadata schema simple "just a URI" while still allowing
ISBNs ].
And then we're done if we choose 'a' above, it's pretty simple.
If you choose 'b' above, then you need a way to identify (or "describe
sufficient for identification") publications that do not have standard
identifiers.
An OpenURL context object using the standard "scholarly formats" (the
only ones actually being used much in the real world) is ONE such way
that is _actually_ being used today for _just_ this purpose. So it
would be worth looking at. You could try to use it "whole cloth", or you
could just take the element schema from the "scholarly formats" and
re-purpose it. You could try to fix some of it's problems. (There are
many).
Or you could ignore OpenURL (or rather than ignore, review it briefly
for ideas) and use one of the other formats that haven't really yet
caught on yet, but might be designed a lot better than OpenURL.
Examples brought up in this thread include something by Jakob Voss (that
I don't have the URL handy for), some kind of citation-in-json format
(that I don't have the url handy for), and Bibo in RDF (that I don't
have the url handy for). If you decide to go with any of these, it's
probably worth _comparing_ them to OpenURL to make sure what can be
expressed in OpenURL with standard scholarly formats can _also_ be
expressed in the format you chose. (Last time I looked at Bibo, I recall
there was no place to put a standard identifier like a DOI. So maybe
using Bibo + URI for standard identifier would suffice. etc.)
So this is my recommended framework for proceeding. Tim, I'm afraid
you'll actually have to do the hard work yourself. Standards creation
is hard. You aren't going to get something good just by getting some
listserv to vote. Many of us involved in this discussion may find this
intellectually interesting, but may have no actual use _ourselves_ for
such a format anyway. If Amazon or someone like that comes up with
something, it will end up becoming the 'de facto' standard, so I
recommend trying to talk to Amazon to see if they're thinking about this
-- or just wait to see if/what Amazon comes up with, and use that.
Jonathan
