I already use rules with textseeka to generate urls (to different levels: volume; issue; articles), for targets such as Royal Society of New Zealand titles, using data from the incoming openurl requests...
When there are DOIs, it should be possible to do the same with titles such as Annual Reviews, where the publisher has a DOI resolver for their content, just as there are publishers' OpenURL-flavoured resolvers.
I've tagged some items which might be of interest, if this is your thing here: http://delicious.com/Tom.Pasley/rules_based_url - I've just realised I hadn't tagged the URL Clearinghouse, which is a great resource, (but which I need to contribute more to!), but I've just fixed it now.
Friday, January 30, 2009
Monday, January 26, 2009
Thursday, January 22, 2009
NTS:: RDA (Important Library Stuff)
Hmmm... it did look like RDA might be the sort of thing I was wanting... supposed to have the granularity I'd like, but just seeing the draft documents makes me just balk.
Once you download the zip file, and see the size of the pdfs, you realise how much work has been done, (a lot), but also how much work is involved in implementing it. Not being a cataloguer, getting my head around this would take too long, so I'm probably going to soften it, and go with something similar, but easier.
My grand plan, (which is all it is at this stage - whether it gets to be anything more is dubious), would be a central repository for the tags, and how they translate... whether this would be a networked thing remains to be seen.
Once you download the zip file, and see the size of the pdfs, you realise how much work has been done, (a lot), but also how much work is involved in implementing it. Not being a cataloguer, getting my head around this would take too long, so I'm probably going to soften it, and go with something similar, but easier.
My grand plan, (which is all it is at this stage - whether it gets to be anything more is dubious), would be a central repository for the tags, and how they translate... whether this would be a networked thing remains to be seen.
Labels:
cataloging,
cataloguing,
database design,
flattened marc,
metadata,
rda
Wednesday, December 24, 2008
NTS:: Postgres vs. MySQL
I think that Postgres has a lot going for it - judging by this page on Wikipedia there's somethings which using Postgres is an advantage...
I like the idea of triggers, (must look into this), but I believe MySQL has something similar? Would be useful when you want an additive database, which is triggered by an insert on a main database:
index (is updated on INSERT of main)(keeps all information - is a "look-up database")
main (keeps only current items)
XML/Xpath sounds nice too!
Will install and see what the advantages are...
I like the idea of triggers, (must look into this), but I believe MySQL has something similar? Would be useful when you want an additive database, which is triggered by an insert on a main database:
index (is updated on INSERT of main)(keeps all information - is a "look-up database")
main (keeps only current items)
XML/Xpath sounds nice too!
Will install and see what the advantages are...
Friday, December 5, 2008
NTS:: Database structure and "flattened MaRC" - hmmm... let's start again
Okay, so I didn't get the whole RDF thing... and what I've come up with below is not that dissimilar to Prism, see this example from HubMed which is really what I had in mind, (but with more elements).
I suppose what I'd like to do is add in some FRBR too...
ROW # (autoincrement) | RECORD | LINE | ORDER | VALUE
1 | 1 | creator:surname | 001 | Smith
2 | 1 | creator:firstname | 001 | James
3 | 1 | title:entire | 001 | MySQL : Exploring database design
4 | 1 | published:date | 001 | 2004
5 | 1 | published:edition | 001 | [1st]
6 | 1 | published:isbn | 001 | 018524564X
7 | 1 | published:date | 002 | 2006
8 | 1 | published:edition | 002 | 2nd
9 | 1 | published:isbn | 002 | 978018524678X
I suppose what I'd like to do is add in some FRBR too...
ROW # (autoincrement) | RECORD | LINE | ORDER | VALUE
1 | 1 | creator:surname | 001 | Smith
2 | 1 | creator:firstname | 001 | James
3 | 1 | title:entire | 001 | MySQL : Exploring database design
4 | 1 | published:date | 001 | 2004
5 | 1 | published:edition | 001 | [1st]
6 | 1 | published:isbn | 001 | 018524564X
7 | 1 | published:date | 002 | 2006
8 | 1 | published:edition | 002 | 2nd
9 | 1 | published:isbn | 002 | 978018524678X
Thursday, December 4, 2008
NTS:: Database structure and "flattened MaRC" - further thoughts
hmmm... I thought what I'd come up with wasn't entirely new (but didn't know where!)... it's not a huge leap from PubMed data, with a bit of Dublin Core thrown in.
Hopefully I'll get a chance to play with some data, and see how it pans out.
<article pubmodel="Print">
<journal>
<issn issntype="Print">0964-7058</issn>
<journalissue citedmedium="Print">
<volume>15</volume>
<issue>1</issue>
<pubdate>
<year>2006</year>
</pubdate>
</journalissue>
<title>Asia Pacific journal of clinical nutrition</title>
</journal>
</article>
Hopefully I'll get a chance to play with some data, and see how it pans out.
<article pubmodel="Print">
<journal>
<issn issntype="Print">0964-7058</issn>
<journalissue citedmedium="Print">
<volume>15</volume>
<issue>1</issue>
<pubdate>
<year>2006</year>
</pubdate>
</journalissue>
<title>Asia Pacific journal of clinical nutrition</title>
</journal>
</article>
Wednesday, December 3, 2008
NTS:: Database structure and "flattened MaRC"
Thinking about how MaRC works, makes me think that subject (record?), property, value is not enough... or maybe I've not caught on to RDF just yet?
Column structure for a simple database (along the lines of XML and a flattened MaRC structure):
(okay, so this is not going to set the world on fire, but I think it's useable)
ROW # (autoincrement) | RECORD | LINE | ORDER | VALUE
1 | 1 | creator:surname | 001 | Smith
2 | 1 | creator:firstname | 001 | James
3 | 1 | title:entire | 001 | MySQL : Exploring database design
4 | 1 | published:date | 001 | 2004
5 | 1 | published:edition | 001 | [1st]
6 | 1 | published:date | 002 | 2006
7 | 1 | published:edition | 002 | 2nd
Column structure for a simple database (along the lines of XML and a flattened MaRC structure):
(okay, so this is not going to set the world on fire, but I think it's useable)
ROW # (autoincrement) | RECORD | LINE | ORDER | VALUE
1 | 1 | creator:surname | 001 | Smith
2 | 1 | creator:firstname | 001 | James
3 | 1 | title:entire | 001 | MySQL : Exploring database design
4 | 1 | published:date | 001 | 2004
5 | 1 | published:edition | 001 | [1st]
6 | 1 | published:date | 002 | 2006
7 | 1 | published:edition | 002 | 2nd
Subscribe to:
Posts (Atom)