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.


Reply via email to