I've been wondering for a while how to create a platform that used linked data natively.
There are plenty of platform building options which understand ordinary relational databases, but, for my requirements, there's nothing like Yii with a linked-data backend.
Anyway, I'd really like to see an OpenURL resolver re-use the data by making the requests it's given available as linked open data, in much the same way as SFX exposes it's data for other purposes, such as the bX service.
I also hope I can see a time when publishers, or a body representing them (CrossRef)will make the metadata for the articles they produce freely available, like Nature Publishing... hell, a lot of them expose their content to Google, so why not maximise their exposure via other means?
Monday, March 29, 2010
Friday, October 16, 2009
CrossRef Labs - worth a look!
If you work in the "information space", then it's nice to know that CrossRef have some developmental services, but there's one, (okay, two), in particular that I really like the look of:
- Metadata Search complete with an OpenSearch plugin. This is not, of course a complete "search": "Instead, CrossRef Metadata Search is focused on allowing researchers to lookup citations using only terms that might appear in the bibliographic metadata of the item they are searching for."
- an undocumented aspect which I discovered which is a more RESTful service providing the metadata for a given DOI. This is of the form: http://api.labs.crossref.org/{DOI}.xml
Labels:
crossref,
crossref labs,
doi,
doi registration agency,
opensearch,
RESTful api
Sunday, September 27, 2009
txtckr stage 1
Well, I've just committed a batch of updates to txtckr, which has finally moved beyond a mix of php & pseudo-php to a stage where I run it on a laptop without any errors (with the included very simple test).
It's almost at the stage of adding the finishing touches to the name handling, where the various openurl name parts get humpty-dumptied again. It's just skeleton coding at this stage, but hopefully a pretty sound basis for what's to come!
It's almost at the stage of adding the finishing touches to the name handling, where the various openurl name parts get humpty-dumptied again. It's just skeleton coding at this stage, but hopefully a pretty sound basis for what's to come!
Thursday, September 17, 2009
Google Co-op: EBSCO Connect search
There's been a bit of talk about EBSCO Connect content appearing on Google, and while it's not the sort of thing that thrills me necessarily, I found it was easy enough to create yet another Google Custom search, which would allow the retrieval of EBSCO connect material only.
There appears to be quite a bit of content there - give the search a go, and leave a response if you feel that way inclined...
There appears to be quite a bit of content there - give the search a go, and leave a response if you feel that way inclined...
Thursday, August 6, 2009
Dealing with humans' (names)
Recently I hit a slight snag on a fairly common problem... dealing with names. This is a problematic area, given that everyone has one, and trying to build in what we know about names into software is actually a bit of a slog!
What I'm doing is trying to parse names, (mainly author names), for txtckr, so that one of the output display formats could be a reference, (APA, for example). To do this, I also need to untangle the "rft.au" information which is delivered through OpenURL, and I'm trying to build in some "forgiveness" to allow for people/companies that don't follow spec's properly!
Things to consider:
What I'm doing is trying to parse names, (mainly author names), for txtckr, so that one of the output display formats could be a reference, (APA, for example). To do this, I also need to untangle the "rft.au" information which is delivered through OpenURL, and I'm trying to build in some "forgiveness" to allow for people/companies that don't follow spec's properly!
Things to consider:
- with a full name, is it supplied first-name(s) last-name/surname, and if so, where does the surname begin? This is fine for a fair number of relatively simple names, but what about surnames which aren't, such as "van der Weerden"?
- if you're going to receive name fragments, how do you build these sensibly into software, so you can give permutations of the name, e.g. Pasley, Tom == Pasley, T. == Tom Pasley == T. Pasley?
Labels:
authors,
databases,
names,
openurl,
openurl resolver,
php,
programming,
references,
txtckr
Friday, July 17, 2009
What if OpenURL resolvers could blog?
I thought about this when I was thinking about having support for unAPI, etc. I found Mike Giarlo's plugin for WordPress, which added this, and I could make it work for txtckr, but why should I?
I may have overlooked something, (since I don't use WordPress), but:
There's also the tools available through something like the WordPress platform, which further promotes the re-distribution of information about articles, books, etc., including COinS, RSS feeds, OAI-PMH, unAPI, etc.
Of course there's also the ability for others to comment and refer, (trackback), on the item being represented in the blog post.
I may have overlooked something, (since I don't use WordPress), but:
- what if WordPress was the OpenURL resolver, (well, actually it wasn't but just looked like it)?
- what if txtckr could redirect to the WordPress post which had the request response once it had made a post which contained all of that info?
There's also the tools available through something like the WordPress platform, which further promotes the re-distribution of information about articles, books, etc., including COinS, RSS feeds, OAI-PMH, unAPI, etc.
Of course there's also the ability for others to comment and refer, (trackback), on the item being represented in the blog post.
Labels:
atom,
blogging,
openurl,
openurl resolver,
rss,
unapi coins,
wordpress
Wednesday, July 15, 2009
txtckr under development
While I was working at Crop & Food Research, I developed an OpenURL resolver called textseeka.
txtckr is a GPL, (open-source), OOP focussed, replacement for textseeka, based on what I know now, in terms of programming, OpenURL, webservices and metadata sources.
This is not a simple overnight project, complicated by the fact that I need access to the original code-base, which is still at my old work. Over time, (snatched here and there), txtckr will be fleshed out, starting from the bones that are there now, (currently just a class for the "context object").
txtckr is a GPL, (open-source), OOP focussed, replacement for textseeka, based on what I know now, in terms of programming, OpenURL, webservices and metadata sources.
This is not a simple overnight project, complicated by the fact that I need access to the original code-base, which is still at my old work. Over time, (snatched here and there), txtckr will be fleshed out, starting from the bones that are there now, (currently just a class for the "context object").
Subscribe to:
Posts (Atom)