Figuring out where to start
Ross Singer
So, like Godmar said, let's do something (hear! hear!).
So, I guess we need to start with what the resources are that we're
working with and what metadata formats to deliver them in. Then we
need to decide what happens with each HTTP verb and how that
translates to the backend connectors (i.e. will they be RESTful,
also?).
Just to get a gauge on who would be interested in what pieces...
We've got three "components" that need building (I don't care what
languages and, in some ways, the more the better to prove a point):
1. A Jangle core implementation that can follow the spec as it evolves
2. Connectors
3. Client libraries (to see if Jangle core is actually working properly).
If you don't want to code anything, people just willing to work on the
specs are more than welcome and if you want to focus on a particular
piece of the chain, speak up.
In the end, I don't care how this works, I just want to see something work :)
I will be happy to work on whichever component that we have the fewest
development cycles for, but it would make more sense for others to
work on connectors, esp. those closer to an ILS than me (although I
can obviously get access to one).
But, before we get ahead of ourselves, let's figure out what we're serving:
The proposed resources (so far) are:
Actor
Collection
Resource (or FRBR Manifestation -- it would be nice to decide on a
name for this)
Item
Can anybody think of any other resources? If we focus on a simple
availability service as our use case for this iteration, we can
probably ignore Actor in sharp detail (basically we can stub it out
for now).
If we can agree on the resources, let's take this to Jangle.org to
flesh it out. If Drupal becomes a burden for collaborative editing,
we can fall back the Google Code wiki.
This sound ok?
Thanks,
-Ross.
Emily Lynema
I'm assuming that when you start to think about actors, there will be things like hold so that you can add a hold to an actor? Perhaps that doesn't qualify according to the definition of 'resource'.
Also, I'm assuming that 'Resource' could be either a bibliographic record or an authority record?
-emily
Ross Singer
On Mon, Apr 21, 2008 at 10:12 AM, Emily Lynema <emily...@gmail.com> wrote:
> Have you given any thought to holdings-level description, the type normally
> used for serials? I myself prefer to work with item-level descriptions, but
> often holdings-level description is all that's available for serials.
Is this basically the same thing as an item? I guess I'm not enamored
with 'holdings' because it seems so library specific.
Could variations on a theme be subclassed? Like, say, Holdings is a
child of Item?
>
> I'm assuming that when you start to think about actors, there will be things
> like hold so that you can add a hold to an actor? Perhaps that doesn't
> qualify according to the definition of 'resource'.
A hold doesn't seem so much like resource to me, as much as it's the
intersection of a person with a thing.
It does make me think I have been leaving out a resource type, though,
which would be 'Event'.
>
> Also, I'm assuming that 'Resource' could be either a bibliographic record or
> an authority record?
Right, at least, this has been what I've been thinking (somebody
please come up with a better word than Resource!). Again, maybe we're
talking Class::Subclass.
Alternatives welcome :)
-Ross.
Emily Lynema
Yeah, good questions.
Is this basically the same thing as an item? I guess I'm not enamored
On Mon, Apr 21, 2008 at 10:12 AM, Emily Lynema <emily...@gmail.com> wrote:
> Have you given any thought to holdings-level description, the type normally
> used for serials? I myself prefer to work with item-level descriptions, but
> often holdings-level description is all that's available for serials.
with 'holdings' because it seems so library specific.
Ross, I am specifically referring to holdings records that do *not* describe at the item level. Unless you have a very flexible schema for item level description, how will you include the complex enumeration and chronology that is used to describe serials resources at the marc holdings record level? Especially in cases where an enumeration and chronology statement (possibly even just a free-text one) is all that is available to describe a bibliographic resource's holdings.
I'm just pointing this out strongly since we are finding this a bit difficult to handle in the dlf spec.
Ross Singer
"lucky" enough to have serials holdings in chron/enum format, it's
still so littered with random, unparsable words to make it near
worthless.
Maybe it would help us if we had some use cases as to what exactly
clients would intend to do with serial 'items'. I definitely think
some abstraction away from the way that information is held in
MARC/MFHD or even knowledgebases may be in order.
-Ross.
David Fiander
and one's just a special case of the other:
1) Is the "most recent" issue available? Or, alternatively, "What is
the most recent issue that is available?"
2) I need 23(6):243-262. Is that available? Of course, we can assume
that no larcenous undergrad has razored out the article I want, and
merely check for the issue.
I've been running into some of this right now at MPOW. I want to know
what we own for about 100 journals, and the best that I can do in a
simple automated way is that "we own some of it, in some format".
Which is Emily's concept of "holdings level", and is clearly useless
for pretty much any use whatsoever beyond acting as the coarsest of
filters.
- David
Galen Charlton
On Mon, Apr 21, 2008 at 10:32 AM, Ross Singer <rossf...@gmail.com> wrote:
> >
> > Also, I'm assuming that 'Resource' could be either a bibliographic record or
> > an authority record?
>
> Right, at least, this has been what I've been thinking (somebody
> please come up with a better word than Resource!). Again, maybe we're
> talking Class::Subclass.
>
> Alternatives welcome :)
I think 'resource', or a term just as generic, is the best we can do
at the top level. A MARC authority record can represent several
rather different kinds of entities. A MARC bib record (or its
equivalent in just about any other metadata schema in use) in the
general case cannot be readily squeezed into one of the FRBR boxes,
either.
To avoid having to data model the whole libraryish world, how about
for now defining a set of Resource subclasses that are basically just
wrappers for existing metadata standards:
Resource::Bib which can contain:
Resource::Bib::MARCXML
Resource::Bib::DC
etc.
Resource::Authority::MARCXML
Regards,
Galen
LibLime
Ross Singer
> I've been running into some of this right now at MPOW. I want to know
> what we own for about 100 journals, and the best that I can do in a
> simple automated way is that "we own some of it, in some format".
> Which is Emily's concept of "holdings level", and is clearly useless
> for pretty much any use whatsoever beyond acting as the coarsest of
> filters.
Right, this is what I struggle with, as well. In your example, the
'Item' it pretty obvious: Volume 23, Issue 6. It doesn't need to
explicitly be defined as a unique row in the ILSes RDBMS (or whatever
persistence mechanism it uses), since, if it was in there, we wouldn't
have this problem.
So, outside of this 'virtual item' concept (which would be non-trivial
to implement, obv.), what would a client do with a serials holding
record?
Are monographic holdings 1:1 with 'Items"? I feel like they might be.
-Ross.
Ross Singer
> Resource::Bib which can contain:
> Resource::Bib::MARCXML
> Resource::Bib::DC
> etc.
> Resource::Authority::MARCXML
>
Yeah, this is sort of how I was thinking about it (although I'd
probably argue for Content-negotiation for the actual format). Still
works out the same on the implementation end, though.
-Ross.
Emily Lynema
-emilyi
Ross Singer
holdings format for a 'resource', then.
So, maybe something like this:
---------------------------------
HEAD http://jangle.example.org/koha/resource/1234567
HTTP/1.1 200 OK
Content-type: application/marc21; application/iso20775; etc.
This isn't exactly right since almost none of our metadata formats are
registered MIME types, but I suppose they either could be (or made
up).
Another approach could be something like:
GET http://jangle.example.org/koha/resource/1234567/content-types
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Content-type: http://jangle.example.org/koha/resource/1234567</title>
<link href="http://jangle.example.org/koha/resource/1234567/content-types"/>
<updated>2008-04-21T18:30:02Z</updated>
<id>http://jangle.example.org/koha/resource/1234567/content-types</id>
<entry>
<title>http://www.loc.gov/MARC21/slim</title>
<link href="http://jangle.example.org/koha/resource/1234567.mrc"/>
<id>http://jangle.example.org/koha/resource/1234567.mrc</id>
<updated>2008-04-21T18:30:02Z</updated>
<summary>MARC 21 Format</summary>
</entry>
<entry>
<title>info:ofi/fmt:xml:xsd:iso20775</title>
<link href="http://jangle.example.org/koha/resource/1234567.iso"/>
<id>http://jangle.example.org/koha/resource/1234567.iso</id>
<updated>2008-04-21T18:30:02Z</updated>
<summary>XML Format for ISO Holdings</summary>
</entry>
<entry>
<title>http://purl.org/dc/elements/1.1/</title>
<link href="http://jangle.example.org/koha/resource/1234567.dc"/>
<id>http://jangle.example.org/koha/resource/1234567.dc</id>
<updated>2008-04-21T18:30:02Z</updated>
<summary>Dublin Core</summary>
</entry>
</feed>
In your application, what data would you expect to see there? Roughly
what currently exists either in MFHD or the MARC 853-878 fields?
Let's say you also wanted to pull electronic holdings from SFX, what
do you envision that returning?
-Ross.