Subject: [CODE4LIB] Something completely different

From: Peter Schlumpf <[email-masked]>
Date: Sun, 5 Apr 2009 11:40:04 -0400

Greetings!

I have been lurking on (or ignoring) this forum for years.  And libraries too.  Some of you may know me.  I am the Avanti guy.  I am, perhaps, the first person to try to produce an open source ILS back in 1999, though there is a David Duncan out there who tried before I did. I was there when all this stuff was coming together.

Since then I have seen a lot of good things happen.  There's Koha.  There's Evergreen.  They are good things.  I have also seen first hand how libraries get screwed over and over by commercial vendors with their crappy software.  I believe free software is the answer to that.  I have neglected Avanti for years, but now I am ready to return to it.

I want to get back to simple things.  Imagine if there were no Marc records.  Minimal layers of abstraction.  No politics.  No vendors.  No SQL straightjacket.  What would an ILS look like without those things?  Sometimes the biggest prison is between the ears.

I am in a position to do this now, and that's what I have decided to do.  I am getting busy.

Peter Schlumpf

---

From: "Cloutman, David" <[email-masked]>
Date: Mon, 6 Apr 2009 09:59:47 -0700

I'm open to seeing new approaches to the ILS in general. A related
question I had the other day, speaking of MARC, is what would an
alternative bibliographic data format look like if it was designed with
the intent for opening access to the data our ILS systems to developers
in a more informal manner? I was thinking of an XML format that a
developer could work with without formal training, the basics of which
could be learned in an hour, and could reasonably represent the
essential fields of the 90% of records that are most likely to be viewed
by a public library patron. In my mind, such a format would allow
creators of community-based web sites to pull data from their local
library, and repurpose it without having to learn a lot of arcane
formats (e.g. MARC) or esoteric protocols (e.g. Z39.50). The sacrifice,
of course, would be loosing some of the richness MARC allows, but I
think in many common situations the really complex records are not what
patrons are interested in. You may want to consider prototyping this in
your application. I see such an effort to be vital in making our systems
relevant in future computing environments, and I am skeptical that a
simple, workable solution would come out the initial efforts of a
standardization committee.

Just my 2 cents.

- David

---
David Cloutman <[email-masked]>
Electronic Services Librarian
Marin County Free Library 

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of
Peter Schlumpf
Sent: Sunday, April 05, 2009 8:40 AM
To: [email-masked]
Subject: [CODE4LIB] Something completely different

Greetings!

I have been lurking on (or ignoring) this forum for years.  And
libraries too.  Some of you may know me.  I am the Avanti guy.  I am,
perhaps, the first person to try to produce an open source ILS back in
1999, though there is a David Duncan out there who tried before I did. I
was there when all this stuff was coming together.

Since then I have seen a lot of good things happen.  There's Koha.
There's Evergreen.  They are good things.  I have also seen first hand
how libraries get screwed over and over by commercial vendors with their
crappy software.  I believe free software is the answer to that.  I have
neglected Avanti for years, but now I am ready to return to it.

I want to get back to simple things.  Imagine if there were no Marc
records.  Minimal layers of abstraction.  No politics.  No vendors.  No
SQL straightjacket.  What would an ILS look like without those things?
Sometimes the biggest prison is between the ears.

I am in a position to do this now, and that's what I have decided to do.
I am getting busy.

Peter Schlumpf

Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

---

From: Joe Hourcle <[email-masked]>
Date: Mon, 6 Apr 2009 13:32:18 -0400

On Sun, 5 Apr 2009, Peter Schlumpf wrote:

[trimmed]

> Sometimes the biggest prison is between the ears.

Perhaps a slightly different perspective on looking at requirements:

 	What should be easier to do, but is a pain currently?

-Joe

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 6 Apr 2009 13:38:55 -0400

>  	What should be easier to do, but is a pain currently?

My answers to that won't point to a more simplified data structure I 
think some are hoping for.

1. For a serial title, identify if a particular issue of that serial is 
held, and where.
2. Group alternate editions of the same work.
3. Identify the form/genre of an item

There are more. This is what immediately comes to mind. Most of these 
issues are issues of metadata control, and not trivial to solve.

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 10:49:16 -0700

Cloutman, David wrote:
> developer could work with without formal training, 

Well, speaking of 'without formal training' -- I posted this to the Open 
Library technology list, but using the OL, which is triple-based and 
open access, I was able to create a simple demo Pipe of how you could 
determine the earliest date of publication of a book (with an interest 
in looking at potential copyright status). Caveat is that the API I'm is 
still pretty stubby, so it only retrieves on exact title (this will be 
fixed sometime in the future).

The pipe is here:

http://pipes.yahoo.com/pipes/pipe.info?_id=216efa8c3b04764ca77ad181b1cc66e4

kc

> the basics of which

-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
[email-masked] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

---

From: Alex Dolski <[email-masked]>
Date: Mon, 6 Apr 2009 10:38:39 -0700

I think Dublin Core XML is an excellent attempt at what you're talking 
about if you want to consider it a bibliographic data format, which I 
guess could be one of its many uses.

I know that a large percentage of the data in our MARC records is not 
being used for finding/gathering or even display, so in that case, what 
good is it? There is a lot of richness in those records, but it's so 
all-over-the-place that whatever value it might have had gets killed by 
all the inconsistency. In my experience, good, consistent metadata that 
captures the essence of an object is more useful than highly-detailed, 
inconsistent metadata (which all highly-detailed metadata tends to be) 
in a fine-grained element set.

I think there may be a cultural element to this as well, in that IR 
people think of metadata in terms of its utility for IR purposes (at 
which DC tends to be extremely practical) and catalogers think of it as 
a thorough-as-possible description of an object (at which DC is quite 
inadequate).

Alex

-- 
Alex A. Dolski
Web & Digitization Application Developer
Lied Library, University of Nevada, Las Vegas
4505 S. Maryland Parkway, Box 457041
Las Vegas, NV 89154-7041
(702) 895-2225 (phone) / (702) 895-2280 (fax)

---

From: Tom Keays <[email-masked]>
Date: Mon, 6 Apr 2009 14:08:24 -0400

The linked open data crowd might suggest:

Bibliographic Ontology Specification (aka bibo)
http://bibliontology.com/
Abstract: The Bibliographic Ontology Specification provides main
concepts and properties for describing citations and bibliographic
references (i.e. quotes, books, articles, etc) on the Semantic Web.

A lot of work has gone into this to make it work with a wide variety
of possible use cases. It acknowledges FRBR, but doesn't require it.
The Swedish national library uses a tiny fraction of BIBO, along with
DC and other RDF vocabularies. BIBO as a whole is much more granular
than MARC, but whether that makes it more or less suited as a library
format probably depends on who you are.

Tom

---

From: Joe Hourcle <[email-masked]>
Date: Mon, 6 Apr 2009 14:11:17 -0400

On Mon, 6 Apr 2009, Jonathan Rochkind wrote:

> My answers to that won't point to a more simplified data structure I think 
> some are hoping for.
>
> 1. For a serial title, identify if a particular issue of that serial is held, 
> and where.
> There are more. This is what immediately comes to mind. Most of these issues 
> are issues of metadata control, and not trivial to solve.

The really sad thing is -- I agree with every one of those items, as 
they're problems that I run into with my own (non-bibliographic) data.

I've got a few others that might not be as useful in libraries:*

 	Identify items contained in more than one catalog:
 		eg, Hugo award winners that were also on the NYT best
 		seller's list.
 	Identify the lack of correlation between catalogs:
 		eg, Identify items in this week's NYT best sellers list
 		that we _don't_ have at our library.
 	Group (or filter) results by similar form and/or processing;
 		eg, All unabridged audio books in English on CD; Large
 		print books in Spanish in hardback; etc.
 		(or, as an alternative, allow users to set preferences to
 		select their preferred formats)

(I don't follow ILS features, so it's possible that some might be able to 
handle these, but when I've talked to folks in the past, their responses 
have seemed to suggest that I have an odd way of looking at records)

-Joe

* Examples are approximates ... I'm actually looking for records such as:

 	Find periods of time where there was coronal dimming before a
 	coronal mass ejection.

 	Find where there are entries in the LASCO/CME catalog that aren't
 	in the CACTUS catalog (and visa-versa)

 	Only show Level0 data if there isn't associated Level1 data for
 	the observation;  Only show reduced data if there's no full
 	resolution data;  Use SOHO/EIT data unless there's a gap of more
 	than 1 hr, then fill using data from the highest resultion  EUV
 	telescope in the sun-earth line)

---

From: "Walker, David" <[email-masked]>
Date: Mon, 6 Apr 2009 11:12:18 -0700

> I know that a large percentage of the data in our 
> MARC records is not being used for finding/gathering 
> or even display, so in that case, what good is it?

This is, of course, a chicken and egg thing.  The reason why a lot of MARC data remains inconsistent is precisely because it is not being used for finding or display.

Anyone who has worked with a faceted search application has seen this in action.  As soon as you aggregate subject headings, genre designations, etc., into facets you begin to see all kinds of data problems that you never noticed before because they are scattered among thousands of records that previously could only be viewed individually.

Of course, fixing bad or inconsistent data is probably an order of magnitude easier than adding data to records after the fact.

--Dave

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Code for Libraries [[email-masked]] On Behalf Of Alex Dolski [[email-masked]]
Sent: Monday, April 06, 2009 10:38 AM
To: [email-masked]
Subject: Re: [CODE4LIB] Something completely different

Alex

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 11:17:15 -0700

My problem with bibo is that it's strongly oriented toward academic 
journal articles... I would like to see a comparison to MARC, if anyone 
has done that, which might give us an idea of what isn't there. For 
example, I don't see the various work/work, work/expression 
relationships. But it has great detail in some areas, like time 
intervals and access rights.

kc

---

From: "Han, Yan" <[email-masked]>
Date: Mon, 6 Apr 2009 11:19:15 -0700

Well, the future of ILS is to use general computing standards without
making library's own. 

Essentially, from a computing theory view, a graph is the way to present
all the info (i.e. a graph can represent a tree, or a line. When you
look at MARC, it is a linear computing model.) Graph is powerful, but
graph theory can be difficult and extremely complex. Some of them are NP
hard problem. 

I think that RDF based standards (DC? Or something else or maybe no need
for just one metadata standard )can be used to maximize
interoperability, allow further information discovery and at the same
time provide suitable description for different type of materials. 

Yan  

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of
Karen Coyle
Sent: Monday, April 06, 2009 10:49 AM
To: [email-masked]
Subject: Re: [CODE4LIB] Something completely different

The pipe is here:

http://pipes.yahoo.com/pipes/pipe.info?_id=216efa8c3b04764ca77ad181b1cc6
6e4

kc

> Email Disclaimer:
http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

---

From: Ross Singer <[email-masked]>
Date: Mon, 6 Apr 2009 14:33:05 -0400

On Mon, Apr 6, 2009 at 2:17 PM, Karen Coyle <[email-masked]> wrote:
> My problem with bibo is that it's strongly oriented toward academic journal
> articles... I would like to see a comparison to MARC, if anyone has done
> that, which might give us an idea of what isn't there. For example, I don't
> see the various work/work, work/expression relationships. But it has great
> detail in some areas, like time intervals and access rights.

Well, I'm not sure I agree with the assessment that it's geared
towards academic journals... there's been a lot of work towards all
kinds of citations, esp. court cases and whatnot.  See the examples:

http://wiki.bibliontology.com/index.php/Examples

As far as not including FRBR, BIBO doesn't have to, because the FRBR
vocabs: http://vocab.org/frbr/core.html and
http://vocab.org/frbr/extended.html already do.  This way BIBO can
focus on describing citations, FRBR can focus on
work/expression/manifestion/item relationships and other vocabularies
can focus on other attributes (size, location, circ status, whatever).

This is part of the flexibility of RDF, the ability to pick and choose
among schemas to describe resources however you need to.

-Ross.

---

From: Tom Keays <[email-masked]>
Date: Mon, 6 Apr 2009 14:51:15 -0400

It is designed as a container for citations. Articles are one such
example, but that well-understood format is not BIBO's main focus.
They've been going after the tough ones, including legal cases,
conference presentations, letters, etc. Oh, yeah, books, book
chapters, quotations. For a partial list, see
http://wiki.bibliontology.com/index.php/Examples

On Mon, Apr 6, 2009 at 2:17 PM, Karen Coyle <[email-masked]> wrote:
>>> I have been lurking on (or ignoring) this forum for years.  And libraries
>>> too.  Some of you may know me.  I am the Avanti guy.  I am, perhaps, the
>>> first person to try to produce an open source ILS back in 1999, though there
>>> is a David Duncan out there who tried before I did. I was there when all
>>> this stuff was coming together.
>>>
>>>  There's Evergreen.  They are good things.  I have also seen first hand how
>>> libraries get screwed over and over by commercial vendors with their crappy
>>> software.  I believe free software is the answer to that.  I have neglected
>>> Avanti for years, but now I am ready to return to it.
>>>
>>> records.  Minimal layers of abstraction.  No politics.  No vendors.  No SQL
>>> straightjacket.  What would an ILS look like without those things?

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 12:42:32 -0700

> http://wiki.bibliontology.com/index.php/Examples

Still looks pretty limited to me. What academics cite isn't a full 
bibliographic universe. No music, no films, no way to do realia. And 
citing isn't the same as bibliographic description. Don't get me wrong, 
I think it's very complete as a citation format, I just don't think it 
meets other needs. The right tool for the job... and all that.

> can focus on other attributes (size, location, circ status, whatever).

Somehow, though, they have to work together, at least where they are 
describing the same thing. I think the interaction between things like 
FRBR/Work and citation is interesting and complex. The RDA Online effort 
is working to allow you to assign particular data elements to FRBR 
entities through application profiles -- thus you can have a 'work 
title' which may be different to the 'manifestation title.' No one uses 
these differences in citations, but then again we haven't yet used them 
in library catalogs -- both citations and current library cataloging 
limit themselves to describing manifestations. However, if you are 
writing a literary criticism of "Moby Dick" you probably aren't only 
referring to a particular manifestation, but to the work as a whole. 
Right now, citation standards don't address this.

Also note that IFLA is registering the FRBR vocabulary in the 
metadataregistry.org registry. I suspect it will look different to the 
one at vocab.org, although I haven't looked at the IFLA trial version in 
comparison to the one at vocab.org. Presumably FRAD will also be 
registered by IFLA in the same way.

kc

---

From: stuart yeates <[email-masked]>
Date: Tue, 7 Apr 2009 07:54:18 +1200

The TEI format does a decent job of representing  bibliographic 
information. The TEI approach is to treat all instances of bibliographic 
reference as similarly as possible. So the title page of a work, the 
reference markers in the text and the references at the end of the work 
are all described in the same conceptual framework.

http://www.tei-c.org/release/doc/tei-p5-doc/html/CO.html#COBI

The TEI is modular, so you can declare whether you're commingling 
bibliographic tags with part-of-speech, manuscript description and other 
kinds of tags.

cheers
stuart

-- 
Stuart Yeates
http://www.nzetc.org/       New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/     Institutional Repository

---

From: Ross Singer <[email-masked]>
Date: Mon, 6 Apr 2009 16:26:52 -0400

On Mon, Apr 6, 2009 at 3:42 PM, Karen Coyle <[email-masked]> wrote:

> bibliographic universe. No music, no films, no way to do realia. And citing
> isn't the same as bibliographic description. Don't get me wrong, I think
> it's very complete as a citation format, I just don't think it meets other
> needs. The right tool for the job... and all that.

But again, that's where RDF comes in, they even address the other
ontologies to defer to:
http://wiki.bibliontology.com/index.php/Development_Brainstorming#Possible_ontologies_to_Reuse

> describing the same thing.

Right, but that's how it would work.  If these resources were modeled
in RDF, they'd have URIs.  What you would do is to say 'bibliographic
things' you'd use bibo attributes with the URI.  To say work grouping
things you'd use FRBR/FRAR attributes with the URI.

So as long as they're using the same URIs, they're describing the same thing.

-Ross.

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 14:03:32 -0700

> So as long as they're using the same URIs, they're describing the same thing.
OK, Now I think I see where we're missing each other. Right now, IFLA is 
not thinking about registering (or creating identifiers for) the FRBR 
"attributes," just the entities and relationships.  I'm not sure that 
the attributes make the cut... and they aren't the same as the 
properties that RDA has defined. RDA properties have been assigned to 
particular FRBR entities (Groups 1 and 2 only, since RDA didn't do Group 
3) in the RDA documentation, but there isn't complete agreement within 
the cataloging community as to which properties go with which FRBR Group 
1 entities. So what RDA online is experimenting with is applying the 
FRBR entities as classes to RDA properties in an application profile 
that brings together RDA 'data elements' (properties in RDF) and FRBR 
entities (classes in RDF). (I haven't seen the result yet in the 
http://metadataregistry.org so I'm unclear on how the FRBR relationships 
will be used. I think they've been registered as properties.)

I'm not at all sure what will happen with the FRBR attributes that are 
in the FRBR document, but they seem to have been rejected by the JSC in 
the RDA process. Nor can I figure out what's going to happen when the 
FRAD draft is made official. FRAD essentially includes all of FRBR plus 
some other properties and relationships.

Now bibo has many attributes that might be the same as RDA attributes, 
or that could at least have some meaning within the FRBR defined 
classes. FRBR entities could be used with bibo, if the idea for RDA in 
the http://metadataregistry.org works, by creating an application 
profile for bibo + FRBR classes.

kc

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 15:32:03 -0700

Sorry, spoke/wrote too soon. FRBR at vocab.org isn't using the FRBR 
attributes either. And it does have the entities as classes. I'm still 
not sure how one can model a relationship between RDA or bibo properties 
and FRBR Group 1 entities and their properties. RDA tries to assign 
descriptive properties (like 'title' and 'place of publication') to 
particular FRBR Group 1 entities, which I think doesn't work.

OK, I'm off to think about this some more. With some BIG pieces of paper.

kc

Karen Coyle wrote:
> OK, Now I think I see where we're missing each other. Right now, IFLA 
> is not thinking about registering (or creating identifiers for) the 
> FRBR "attributes," just the entities and relationships.  I'm not sure 
> that the attributes make the cut... and they aren't the same as the 
> particular FRBR entities (Groups 1 and 2 only, since RDA didn't do 
> Group 3) in the RDA documentation, but there isn't complete agreement 
> within the cataloging community as to which properties go with which 
> FRBR Group 1 entities. So what RDA online is experimenting with is 
> applying the FRBR entities as classes to RDA properties in an 
> application profile that brings together RDA 'data elements' 
> (properties in RDF) and FRBR entities (classes in RDF). (I haven't 
> seen the result yet in the http://metadataregistry.org so I'm unclear 
> on how the FRBR relationships will be used. I think they've been 
> registered as properties.)
>
> in the FRBR document, but they seem to have been rejected by the JSC 
> in the RDA process. Nor can I figure out what's going to happen when 
> the FRAD draft is made official. FRAD essentially includes all of FRBR 
> plus some other properties and relationships.
>

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 6 Apr 2009 18:48:18 -0400

> particular FRBR Group 1 entities, which I think doesn't work.
I'm curious why you think that doesn't work?  Isn't "place of 
publication" a characteristic of a particular manifestation? While, 
"title", according to traditional library practices where you take it 
from the title page, is also a characteristic of a particular 
manifestation, is it not? ("uniform title" is _usually_ a characteristic 
of a work, unless we get into music cataloging and some other 'edge' 
cases. Our traditional practices -- which aren't actually changed that 
much by RDA, are rather confusing.)

I am confused about what one would do about the fact that RDA defines 
attributes a bit different than FRBR itself does. It's not too 
surprising -- FRBR is really just a draft, hardly tested in the world. 
When RDA tried to make it a bit more concrete, it's not surprising that 
they found they had to make changes to make it workable. Not sure what 
to do about that in the grand scheme of things, if RDA and FRBR both end 
up registering different vocabularies. I guess we'll just have two 
different vocabularies though, which isn't too shocking I guess.

Jonathan

---

From: Karen Coyle <[email-masked]>
Date: Mon, 6 Apr 2009 17:10:10 -0700

Jonathan Rochkind wrote:
> manifestation, is it not? ("uniform title" is _usually_ a 
> characteristic of a work, unless we get into music cataloging and some 
> other 'edge' cases. Our traditional practices -- which aren't actually 
> changed that much by RDA, are rather confusing.)

Well, I was responding to Ross' statement that bibo and FRBR could be 
used in combination, depending on whether one was at that moment 
describing 'bibliographic things' or 'work things'. bibo doesn't have a 
uniform title, so the question is: can you use a bibo title and say that 
it is a work title? I thought that Ross was indicating something of that 
nature -- that you could have a FRBR 'work thing' with bibo properties. 
I'm trying to understand how that works since Work is a class. Don't you 
have to indicate the domain and range of a property in its definition?

RDA tries to solve this by creating different properties for every 
concept+FRBR entity: title of the work (Work), title proper 
(Manifestation). [I don't understand why expressions don't have 
titles.... a translation is an expression, after all.]
> When RDA tried to make it a bit more concrete, it's not surprising 
> that they found they had to make changes to make it workable. Not sure 
> what to do about that in the grand scheme of things, if RDA and FRBR 
> both end up registering different vocabularies. I guess we'll just 
> have two different vocabularies though, which isn't too shocking I guess.
>
I'm not sure there's anything to do, but I do know that the developers 
of RDA feel very strongly that in RDA they have 'implemented' FRBR, so 
we have to find a way to integrate FRBR and RDA in the registered RDA 
vocabulary. I agree that there's no problem with having RDA and FRBR as 
two different vocabularies, it's the effort of bringing them together 
that boggles me. I feel like it leaves a lot of loose ends. I'd be happy 
to see FRBR revised, or to have it re-defined without the attributes, 
thus allowing metadata developers to use the bibliographic relationship 
properties with any set of descriptive elements.

I'm having trouble with the FRBR Group 1 entities as classes. I see them 
instead as relationships, and vocab.org does seem to treat them as 
relationships, not as 'things.' I see a distinct difference between a 
person entity and a work entity, because there is no thing that is a 
work. I see work as a relationship between two bibliographic statements. 
(This is vague in my mind, so I won't be surprised if it doesn't make 
sense....) As an example, if I have a group of bibliographic properties, 
say an author and a title, and I say:

Magic Mountain, by Thomas Mann --> expresses --> Der Zauberberg, by 
Thomas Mann

then I have created an 'expression to work' relationship, and so Der 
Zauberberg is a Work. If I do this, I don't need an explicit Work title. 
If I have a badly created Manifestation that has on its title page: 
Magic Mountian, I can do:

Magic Mountian, published by x in y --> manifests --> Magic Mountain, by 
Thomas Mann --> expresses --> Der Zauberberg, by Thomas Mann

In this way, I don't have to declare different title elements with 
different domains/ranges (which is essentially what RDA does in an 
awkward way) to connect them to the FRBR Group 1 classes, and the FRBR 
properties become more usable because you don't have to declare your 
bibliographic properties in terms of the FRBR classes. Now, IF you can 
use any properties, say, dcterms:title, with the FRBR properties, like 
"manifests" then the whole thing is solved. I think it works that way, 
but that is definitely NOT what RDA has done; it has incorporated the 
domain (FRBR class) in the bibliographic properties. I think that what I 
describe above in my examples works; and if it does, then the problem is 
with RDA.

In the end, it's the relationship between properties and classes in FRBR 
and RDA that is giving me a headache, and the headache mainly has to do 
with FRBR group 1. I think this is my bete noir, and so I will now go 
read something soothing and let my blood pressure drop a bit.

kc

---

From: Ross Singer <[email-masked]>
Date: Mon, 6 Apr 2009 21:18:22 -0400

Right, ok, so an RDF graph can say the same resource is multiple
things at the same time, so that's how you deal with this:

<http://lccn.loc.gov/95100870> rdf:type <bibo:Book> .
<http://lccn.loc.gov/95100870> dc:title "Doctor Zhivago"@en .
<http://lccn.loc.gov/95100870> dc:creator
<http://www.worldcat.org/identities/lccn-n79-18438> .
<http://lccn.loc.gov/95100870> rda:uniformTitle "Doktor Zhivago. English" .
<http://lccn.loc.gov/95100870> rdf:type <rda:EditionStatement> .
<http://lccn.loc.gov/95100870> rdf:type <frbr:Manifestation> .
<http://lccn.loc.gov/95100870> frbr:embodimentOf
<http://dbpedia.org/resource/Doctor_Zhivago> .

I'm guessing on the RDA assertions, because the schema in the
metadataregistry doesn't make much sense to me.

Anyway, this shows how you can say multiple things from different
vocabularies for one resource.

-Ross.
On Mon, Apr 6, 2009 at 8:10 PM, Karen Coyle <[email-masked]> wrote:
> Jonathan Rochkind wrote:
>>
>> I'm curious why you think that doesn't work?  Isn't "place of publication"
>> a characteristic of a particular manifestation? While, "title", according to
>> traditional library practices where you take it from the title page, is also
>> a characteristic of a particular manifestation, is it not? ("uniform title"
>> is _usually_ a characteristic of a work, unless we get into music cataloging
>> and some other 'edge' cases. Our traditional practices -- which aren't
>> actually changed that much by RDA, are rather confusing.)
>
> Well, I was responding to Ross' statement that bibo and FRBR could be used
> in combination, depending on whether one was at that moment describing
> 'bibliographic things' or 'work things'. bibo doesn't have a uniform title,
> so the question is: can you use a bibo title and say that it is a work
> title? I thought that Ross was indicating something of that nature -- that
> you could have a FRBR 'work thing' with bibo properties. I'm trying to
> understand how that works since Work is a class. Don't you have to indicate
> the domain and range of a property in its definition?
>
> concept+FRBR entity: title of the work (Work), title proper (Manifestation).
> [I don't understand why expressions don't have titles.... a translation is
> an expression, after all.]
>>
>> attributes a bit different than FRBR itself does. It's not too surprising --
>> FRBR is really just a draft, hardly tested in the world. When RDA tried to
>> make it a bit more concrete, it's not surprising that they found they had to
>> make changes to make it workable. Not sure what to do about that in the
>> grand scheme of things, if RDA and FRBR both end up registering different
>> vocabularies. I guess we'll just have two different vocabularies though,
>> which isn't too shocking I guess.
>>
> I'm not sure there's anything to do, but I do know that the developers of
> RDA feel very strongly that in RDA they have 'implemented' FRBR, so we have
> to find a way to integrate FRBR and RDA in the registered RDA vocabulary. I
> agree that there's no problem with having RDA and FRBR as two different
> vocabularies, it's the effort of bringing them together that boggles me. I
> feel like it leaves a lot of loose ends. I'd be happy to see FRBR revised,
> or to have it re-defined without the attributes, thus allowing metadata
> developers to use the bibliographic relationship properties with any set of
> descriptive elements.
>
> relationships, not as 'things.' I see a distinct difference between a person
> entity and a work entity, because there is no thing that is a work. I see
> work as a relationship between two bibliographic statements. (This is vague
> in my mind, so I won't be surprised if it doesn't make sense....) As an
> example, if I have a group of bibliographic properties, say an author and a
> title, and I say:
>
> Magic Mountain, by Thomas Mann --> expresses --> Der Zauberberg, by Thomas
> Mann
>
> Zauberberg is a Work. If I do this, I don't need an explicit Work title. If
> I have a badly created Manifestation that has on its title page: Magic
> Mountian, I can do:
>
> In this way, I don't have to declare different title elements with different
> domains/ranges (which is essentially what RDA does in an awkward way) to
> connect them to the FRBR Group 1 classes, and the FRBR properties become
> more usable because you don't have to declare your bibliographic properties
> in terms of the FRBR classes. Now, IF you can use any properties, say,
> dcterms:title, with the FRBR properties, like "manifests" then the whole
> thing is solved. I think it works that way, but that is definitely NOT what
> RDA has done; it has incorporated the domain (FRBR class) in the
> bibliographic properties. I think that what I describe above in my examples
> works; and if it does, then the problem is with RDA.
>
> In the end, it's the relationship between properties and classes in FRBR and
> RDA that is giving me a headache, and the headache mainly has to do with
> FRBR group 1. I think this is my bete noir, and so I will now go read
> something soothing and let my blood pressure drop a bit.
>
> kc
>
> --

---

From: Karen Coyle <[email-masked]>
Date: Tue, 7 Apr 2009 06:39:58 -0700

Ross,

I'm not questioning the technical assertion -- obviously you can combine 
properties from different vocabularies. My problem is with making sense 
of FRBR in relation to the properties, either in RDA or in bibo. Do you 
say that a particular grouping of properties is of type 
FRBR:Manifestation, or is the property defined in the vocabulary as in 
the Manifestation domain? RDA does the latter (although not in a 
semantic web way). Each data element in RDA "belongs" to a particular 
FRBR entity, so you never actually use the FRBR entities in your 
metadata. (Although the examples that Alistair Miles did [1] use the 
levels as part of the record organization.) I actually prefer the usage 
that I gave in my examples, in which relationships carry the FRBR 
"meaning" and bibliographic properties can be used at any level.

The schema in the registry is completely flat partly because of the 
choice made by RDA to include the FRBR levels in the data elements 
themselves. The other 'partly' is because the creators of RDA are still 
pretty much thinking in terms of traditional bibliographic data, ISBD 
and MARC.

kc
[1] Linked from each scenario at 
http://dublincore.org/dcmirdataskgroup/Scenarios

---

From: Ross Singer <[email-masked]>
Date: Tue, 7 Apr 2009 11:21:57 -0400

So, thanks to the help of my coworkers, here's the RDA Elements schema
reformatted in an easier to read presentation:
http://morph.talis.com/?data-uri[]=http%3A%2F%2Frdvocab.info%2FElements.rdf&input=&output=exhibit&callback=

I have to say I feel like this schema is trying to both do way too
much and subsequently loses the resource specificity that RDF would be
providing.

For one thing, it seems to reinvent a _lot_ of wheels.  Why does it
define its own title property instead of using DC's?  By using
properties like titleOfTheWork, dateOfWork and all of the properties
that are specifically about TheSeries there is tremendous duplication
of text.  If Work was its own class, you would only need say that this
manifestation was an embodimentOf of it and reuse all of the
title-based properties for manifestation.  The series-specific
property names seem redundant, as well, since isn't SeriesStatement
defining a series?  Why do you need titleProperOfSeries if you already
have titleProper?

What does property 'uri' mean?

I also can't figure out how people/institutions are modeled in this
schema, since none of the elements have ranges.  Are they their own
resources?  If so, what?  The way it looks at a glance, they're
strings?

There are also different properties for dimensions, dimensionsOfMap,
dimensionsOfStillImage, etc.  Why is there any need for anything more
than 'dimensions'?  This is redefining what the resource 'is' in
multiple places, but the fact that this is a still image is made
somewhere else, right?  If so, isn't it self-evident that the
dimensions are of a still image?

It seems to me that very little work was done find preexisting
vocabularies to reuse and this schema still presents a very
'document-centric' or 'record-centric' view of data.

-Ross.

On Tue, Apr 7, 2009 at 9:39 AM, Karen Coyle <[email-masked]> wrote:
> properties from different vocabularies. My problem is with making sense of
> FRBR in relation to the properties, either in RDA or in bibo. Do you say
> that a particular grouping of properties is of type FRBR:Manifestation, or
> is the property defined in the vocabulary as in the Manifestation domain?
> RDA does the latter (although not in a semantic web way). Each data element
> in RDA "belongs" to a particular FRBR entity, so you never actually use the
> FRBR entities in your metadata. (Although the examples that Alistair Miles
> did [1] use the levels as part of the record organization.) I actually
> prefer the usage that I gave in my examples, in which relationships carry
> the FRBR "meaning" and bibliographic properties can be used at any level.
>
> The schema in the registry is completely flat partly because of the choice
> made by RDA to include the FRBR levels in the data elements themselves. The
> other 'partly' is because the creators of RDA are still pretty much thinking
> in terms of traditional bibliographic data, ISBD and MARC.
>
> kc
>>>> publication"
>>> used
>>> (Manifestation).
>>>> surprising --
>>> person
>>> Thomas
>>> If
>>> different
>>> and

---

From: Nate Vack <[email-masked]>
Date: Tue, 7 Apr 2009 10:59:05 -0500

On Sun, Apr 5, 2009 at 10:40 AM, Peter Schlumpf <[email-masked]> wrote:

> I want to get back to simple things.  Imagine if there were no Marc records.  Minimal layers of abstraction.  No politics.  No vendors.  No SQL straightjacket.  What would an ILS look like without those things?

Back to this original question, when I imagine these things, I imagine
building an ILS that relies on an unusual data persistence backend,
discounts industry-standard data formats, and explicitly ignores the
political concerns of adopting, deploying, and maintaining it.

And I get a little bit nervous.

For what it's worth (and I think this touches on the ontological
discussion in this thread, too) -- my experience has been that it's
easier to build a piece of software that solves a problem
compellingly, solving technical hurdles as you need to than it is to
come up with solutions to anticipated technical problems before
starting on making a product.

More concretely: if you build a software product, I don't care at all
whether it's based on a SQL straitjacket or a luscious RDF comforter.
I care if it solves a problem well, and that I can install it and run
it easily.

Cheers,
-Nate

---

From: Karen Coyle <[email-masked]>
Date: Tue, 7 Apr 2009 10:15:46 -0700

> much and subsequently loses the resource specificity that RDF would be

Absolutely. I think there 's a real issue that NO technology folks were 
involved in the creation of RDA. So this is "data" from a cataloger's 
perspective, and from the perspective of guidance rules for creating 
bibliographic data. I'm pretty sure that we can't create a viable data 
record using the RDA data elements, and I hate the idea that the data 
format, once again, is an afterthought rather than integral to the data 
creation standard.

> define its own title property instead of using DC's? 

Because they wanted their own definition. Everything in the RDA element 
list has an RDA-specific meaning, which then makes it impossible to use 
any existing data properties. But there's more: RDA was defining RDA 
cataloging rules, not a schema or record format. Not only are there 
multiple data elements where one could do, there are things that are 
missing. For example, the FRBR "place" entity can ONLY be used as a 
subject, so it really means "place as subject". There's no general 
"place" element that could be used, for example, in place of 
publication. The latter has no relationship to FRBR place. This is a 
FRBR problem as much as an RDA problem, but again FRBR functions at a 
conceptual level and doesn't really provide a schema that one can work with.

>  By using
> title-based properties for manifestation. 

Exactly. This is what I've been saying (or trying to say) in relation to 
the bibo discussion. You should be able to use whatever properties you 
want with the FRBR classes, and not restrict data elements to a single 
class. This is a big problem in RDA, but I can say that when it was 
brought up to them (JSC) they strongly defended this choice and would 
not budge. RDA, to JSC, has a specific relationship to FRBR, and if you 
use a data element with a different FRBR class, then you are no longer 
doing RDA.

> What does property 'uri' mean?

Did you look at the rdf/xml? I'm wondering if it isn't the display 
that's confusing.

> resources?  If so, what?  The way it looks at a glance, they're

EVERYTHING is strings at the moment, with a very very few exceptions 
(like some dates, I think). Some data elements CAN use a controlled 
vocabulary, but I believe that all of those are a mixture of 
uncontrolled and controlled strings. People and institutions are mainly 
undefined because that is in the FRAD realm. And FRAD hasn't been 
finalized. Also note that the JSC didn't feel it could do anything that 
would be too incompatible with the 'legacy' -- that is, with all of our 
AACR/MARC data.

> 'document-centric' or 'record-centric' view of data.

Absolutely. The catalogers are still creating a textual document, not 
data. At best you can mark up the text, as we do with the MARC record. I 
worry that we won't be able to mesh the cataloger's view with a data 
view -- that the two are some how inherently opposed. I'd like to start 
modeling a new data format but I can't imagine how we can bridge the gap 
between the catalogers and the system view. I suppose a very clever 
interface could hide the data view from the catalogers, but starting 
from either AACR2 or RDA and trying to get there feels extremely 
difficult. I guess my fear is that it will require compromises, and 
those will be hard to negotiate.

kc

p.s. The RDA element analysis is at 
http://www.collectionscanada.gc.ca/jsc/docs/5rda-elementanalysisrev2.pdf. 
That was the input to the registry.

---

From: Eric Lease Morgan <[email-masked]>
Date: Tue, 7 Apr 2009 13:24:38 -0400

On Apr 7, 2009, at 1:15 PM, Karen Coyle wrote:

> data. At best you can mark up the text, as we do with the MARC  
> record...

Listen...  What you hear from over here is the sound of a very heavy  
sigh coming from a computer type who really wants to help improve the  
way library data is used in a networked environment, but they can't  
convince their own to modify the way they encode information.

-- 
Earache Least Moron

---

From: Rob Sanderson <[email-masked]>
Date: Tue, 7 Apr 2009 18:25:20 +0100

See also the thread, 'RDA: A Standard Nobody Will Notice'.

http://www.mail-archive.com/[email-masked]/msg04422.html

A standard nobody will notice ... for good reason. 

Rob

---

From: David Fiander <[email-masked]>
Date: Tue, 7 Apr 2009 13:41:28 -0400

On Tue, Apr 7, 2009 at 1:24 PM, Eric Lease Morgan <[email-masked]> wrote:
> Listen...  What you hear from over here is the sound of a very heavy sigh
> coming from a computer type who really wants to help improve the way library
> data is used in a networked environment, but they can't convince their own
> to modify the way they encode information.

See also

Fiander, David J. "Applying XML to the Bibliographic Description."
Cataloging and Classification Quarterly 33, no. 2 (2001): 17-28.

Fiander, David J., and D. Grant Campbell. "An XML Definition for an
ISBD-Based Encoding Scheme." Journal of Internet Cataloging 6, no. 4
(2003): 29-58.

Which is what happens when a computer type starts de novo with the
cataloguing standards and builds simple data structures.

---

From: Anna Headley <[email-masked]>
Date: Tue, 7 Apr 2009 13:44:05 -0400

And what you hear over here is a plea to not give up on catalogers.  
Some are beyond ready to move from text to data.  Hiding the data view 
-- do you mean making it look like marc? -- sounds pretty awful.  
Catalogers who are on board are trapped by the way sharing currently 
works, i.e. record sharing.  If the leaders of the cataloging community 
are failing, what can catalogers do?  This is an honest question, not a 
throwing-up-of-hands.  Though maybe completely off-topic for this list.

ah

Karen Coyle wrote:
> data. At best you can mark up the text, as we do with the MARC record. 
> I worry that we won't be able to mesh the cataloger's view with a data 
> view -- that the two are some how inherently opposed. I'd like to 
> start modeling a new data format but I can't imagine how we can bridge 
> the gap between the catalogers and the system view. I suppose a very 
> clever interface could hide the data view from the catalogers, but 
> starting from either AACR2 or RDA and trying to get there feels 
> extremely difficult. I guess my fear is that it will require 
> compromises, and those will be hard to negotiate.
>
> kc
>

-- 
Anna Headley
Swarthmore College Library
610.690.5781
[email-masked]

---

From: Roy Tennant <[email-masked]>
Date: Tue, 7 Apr 2009 10:48:32 -0700

Well, and then you have the XOBIS work from Stanford that ksclarke was
involved with.
Roy

--

---

From: Ross Singer <[email-masked]>
Date: Tue, 7 Apr 2009 13:48:42 -0400

Karen, thanks for this summary of the process.  It's pretty
disheartening, sadly.

I got 'uri' wrong, btw, it's "Universal Resource Locator'
<!--Property: Uniform resource locator-->
-
<rdf:Property rdf:about="http://RDVocab.info/Elements/uniformResourceLocator">
<rdfs:label xml:lang="en">Uniform resource locator</rdfs:label>
<skos:definition xml:lang="en">
    The address of a remote access resource.  </skos:definition>
<rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"/>
<reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"/>
</rdf:Property>

But again, not exactly the best use of the tools at their disposal.

All this being said, it's really not too late to fix any of this,
since nobody is implementing this and, realistically, nobody ever
will.

-Ross.

On Tue, Apr 7, 2009 at 1:15 PM, Karen Coyle <[email-masked]> wrote:
> Because they wanted their own definition. Everything in the RDA element list
> has an RDA-specific meaning, which then makes it impossible to use any
> existing data properties. But there's more: RDA was defining RDA cataloging
> rules, not a schema or record format. Not only are there multiple data
> elements where one could do, there are things that are missing. For example,
> the FRBR "place" entity can ONLY be used as a subject, so it really means
> "place as subject". There's no general "place" element that could be used,
> for example, in place of publication. The latter has no relationship to FRBR
> place. This is a FRBR problem as much as an RDA problem, but again FRBR
> functions at a conceptual level and doesn't really provide a schema that one
> can work with.
>
>>  By using
> Exactly. This is what I've been saying (or trying to say) in relation to the
> bibo discussion. You should be able to use whatever properties you want with
> the FRBR classes, and not restrict data elements to a single class. This is
> a big problem in RDA, but I can say that when it was brought up to them
> (JSC) they strongly defended this choice and would not budge. RDA, to JSC,
> has a specific relationship to FRBR, and if you use a data element with a
> different FRBR class, then you are no longer doing RDA.
>
> Did you look at the rdf/xml? I'm wondering if it isn't the display that's
> confusing.
>
> EVERYTHING is strings at the moment, with a very very few exceptions (like
> some dates, I think). Some data elements CAN use a controlled vocabulary,
> but I believe that all of those are a mixture of uncontrolled and controlled
> strings. People and institutions are mainly undefined because that is in the
> FRAD realm. And FRAD hasn't been finalized. Also note that the JSC didn't
> feel it could do anything that would be too incompatible with the 'legacy'
> -- that is, with all of our AACR/MARC data.
>
> Absolutely. The catalogers are still creating a textual document, not data.
> At best you can mark up the text, as we do with the MARC record. I worry
> that we won't be able to mesh the cataloger's view with a data view -- that
> the two are some how inherently opposed. I'd like to start modeling a new
> data format but I can't imagine how we can bridge the gap between the
> catalogers and the system view. I suppose a very clever interface could hide
> the data view from the catalogers, but starting from either AACR2 or RDA and
> trying to get there feels extremely difficult. I guess my fear is that it
> will require compromises, and those will be hard to negotiate.
>
> kc
>

---

From: David Fiander <[email-masked]>
Date: Tue, 7 Apr 2009 13:53:46 -0400

Roy,

That's true. Unfortunately, I missed Kevin's talk at Access '02 in
Windsor, and since I wrote the first of those two papers I've mostly
been out of the loop, since it's not my area any more.

- David

---

From: Ross Singer <[email-masked]>
Date: Tue, 7 Apr 2009 13:55:25 -0400

It's not off-topic, at least I don't think so.

And I don't think anybody is asking to give up on catalogers.  Just
like I don't think anybody would want the technologists to describe
the materials, I think the problem is that the catalogers tried to
apply their idea of a data model into tangible technology.

Actually, I think the resource sharing argument is red herring.  A
shift to resource-centricity (vs. record-centricity) just means you
when you grab a new 'manifestation' for your local catalog, you may
also have to grab the creator, the publisher, the series, the
expression, the work, the subjects, etc.  All of these can be bundled
in the same xml document, though -- really it's just a different way
of looking at the data, but it's not a radical departure in the
delivery/discovery.

-Ross.

On Tue, Apr 7, 2009 at 1:44 PM, Anna Headley <[email-masked]> wrote:
> And what you hear over here is a plea to not give up on catalogers.  Some
> are beyond ready to move from text to data.  Hiding the data view -- do you
> mean making it look like marc? -- sounds pretty awful.  Catalogers who are
> on board are trapped by the way sharing currently works, i.e. record
> sharing.  If the leaders of the cataloging community are failing, what can
> catalogers do?  This is an honest question, not a throwing-up-of-hands.
>  Though maybe completely off-topic for this list.
>
> ah
>
>
> Karen Coyle wrote:
>>
>> worry that we won't be able to mesh the cataloger's view with a data view --
>> that the two are some how inherently opposed. I'd like to start modeling a
>> new data format but I can't imagine how we can bridge the gap between the

---

From: "Kevin S. Clarke" <[email-masked]>
Date: Tue, 7 Apr 2009 14:15:50 -0400

>  Though maybe completely off-topic for this list.

Hear, hear.  I don't think we'll see a real solution unless we consider both
the tech-folks' and the catalogers' concerns.  I'm also sympathetic to
knowledge domains wanting to have control over the meaning of their data
elements (to have a useful and well defined set).  How we move forward when
we have so much "legacy" data (and supporting systems), as Anna said, is a
difficult problem.

Thanks for the plug Roy.  The checks in the mail.  ;-)

Kevin

-- 
Kevin S. Clarke
Coordinator of Web Services
Belk Library & Information Commons
Appalachian State University
218 College Street
Boone, NC 28608

[email-masked]
(828) 262-8472

"There are two kinds of people in the world: those who believe there are two
kinds of people and those who know better."

---

From: Anna Headley <[email-masked]>
Date: Tue, 7 Apr 2009 14:25:46 -0400

But the first one to take this on has no one to grab from.  The sharing 
argument may be a red herring in that the problem, from some 
perspectives, isn't so much about sharing one's own work -- it's more 
about using others' work.  Or is there already a community of people 
doing something like what Ross describes?  If so, where can I find out 
more about who, and how this works?

It seems to me that the best movements forward in this opening of data 
are centered on translating marc into more web-usable forms.  Which is 
great**... for everyone except catalogers with no love for marc.  Jakob 
makes a good point in the post that Rob pointed out 
(http://www.mail-archive.com/[email-masked]/msg04422.html)... 
when cataloging can look like librarything, the rules *and, I would add, 
tools* we use seem incredibly bloated.

** I do mean great.  We have to start somewhere.  It's just that the 
cataloging pieces move so excruciatingly slowly.

ah

---

From: Ross Singer <[email-masked]>
Date: Tue, 7 Apr 2009 14:48:22 -0400

Well, there's the project by Alistair Miles that Karen alluded to earlier:

http://code.google.com/p/code4rda

The goals of this project are, in my mind, crucial in moving forward,
since it's taking our existing corpus of records and turning them into
RDA/RDF.  Not only is it a good proof of concept to show how these new
data models would look and work (esp. how they would work w/r/t to
current applications/workflows), but, more importantly, it shows it
can be done *with our current data* alleviating the need for some
unrealistic retrospective recataloging effort.

I guess the way I look at it is, there's still time to fix this, at
least technologically.  There is a difference between the standard,
the data model and the application.

Karen posted a couple of weeks back that UKMARC didn't include
punctuation, instead leaving it to technology to add it.  This doesn't
mean they didn't follow AACR2, they just didn't encode it into the
data fields, explicitly.  Of course, they gave this up when they
adopted MARC21.

Anyway, there's a separation of concerns that is currently being
blurred, but doesn't have to be in practice.

-Ross.

On Tue, Apr 7, 2009 at 2:25 PM, Anna Headley <[email-masked]> wrote:
> argument may be a red herring in that the problem, from some perspectives,
> isn't so much about sharing one's own work -- it's more about using others'
> work.  Or is there already a community of people doing something like what
> Ross describes?  If so, where can I find out more about who, and how this
> works?
>
> It seems to me that the best movements forward in this opening of data are
> centered on translating marc into more web-usable forms.  Which is
> (http://www.mail-archive.com/[email-masked]/msg04422.html)... when
> cataloging can look like librarything, the rules *and, I would add, tools*
> we use seem incredibly bloated.
>
>>>> view --

---

From: Karen Coyle <[email-masked]>
Date: Tue, 7 Apr 2009 13:25:21 -0700

> the data model and the application.

An interesting experiment would be to attempt to use the cataloger's use 
cases that Alistair worked from, but instead of using the RDA vocabulary 
to use bibo+vocab.org/frbr. That would give us something comparative to 
look at. If bibo+frbr can do all or even a lot of what RDA does, then we 
can demonstrate a different model and explain why one is better than the 
other (or at least that more than one model will work).

kc

---

From: Mike Taylor <[email-masked]>
Date: Thu, 9 Apr 2009 15:26:31 +0100

Cloutman, David writes:
 > alternative bibliographic data format look like if it was designed
 > with the intent for opening access to the data our ILS systems to
 > developers in a more informal manner? I was thinking of an XML
 > format that a developer could work with without formal training,
 > the basics of which could be learned in an hour, and could
 > reasonably represent the essential fields of the 90% of records
 > that are most likely to be viewed by a public library patron.

I read this and immediately thought, "oh, that's MODS":
	http://en.wikipedia.org/wiki/Metadata_Object_Description_Schema

Then I read on through the thread and found that Stuart Yeates
recommeded TEI instead.

Then I read on a few more messages, and found that Alex Dolski though
Dublin Core XML was the answer.

Then I read on a bit further, a found half a dozen people arguing for
RDF, triplestores and topic maps.

(I fact, the only thing that _no-one_ has recommended is anything
based on RDA :-) )

I'm not sure what to make of this except to say that Yet Another XML
Bibliographic Format is NOT the answer!

... anyway, all of this is far, far away from the point.  MARC is old
and ugly yes; but then so am I, and I get the job done, just like
MARC.  That format is responsible for about 0.2% of our difficulties,
and replacing it would make essentially no difference to anything that
we actually care about.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[email-masked]>    http://www.miketaylor.org.uk
)_v__/\  "_Scelidosaurus_ [is] vastly more important for understanding
	 dinosaur anatomy & evolution than yet another dromaeosaur
	 (can't believe I just wrote that, even though it's true)" --
	 Thomas R. Holtz, Jr.

---

From: Joe Atzberger <[email-masked]>
Date: Thu, 9 Apr 2009 10:39:30 -0400

> and replacing it would make essentially no difference to anything that

The *encoding* however is responsible for about 20% of my difficulties.
MARC-8 should die...
--Joe

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Thu, 9 Apr 2009 10:48:58 -0400

From: "Mike Taylor" <[email-masked]>

> and ugly yes; but then so am I, 

I don't think you're old, Mike. 

--Ray

---

From: Mike Taylor <[email-masked]>
Date: Thu, 9 Apr 2009 16:12:29 +0100

> I don't think you're old, Mike. 

And _I_ don't think _you're_ ugly.

:-)

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[email-masked]>    http://www.miketaylor.org.uk
)_v__/\  "Whenever there is a conflict between human rights and property
	 rights, human rights must prevail" -- Abraham Lincoln, quoted
	 by Richard Stallman.

---

From: "Mitchell, Erik T." <[email-masked]>
Date: Thu, 9 Apr 2009 12:58:04 -0400

Hi all,

WFU is thinking about moving all of our services to a hosted
environment.  We have been using a company called MediaTemple for the
last year to try a few of our peripheral systems & while that has worked
well, we are also thinking about hosting our digital storage. 

Has anyone done this to a large extent & have
suggestions/recommendations for us?

Thanks,

Erik Mitchell
Assistant Head for Technology Services
Z. Smith Reynolds Library
Wake Forest University

---

From: "Kevin S. Clarke" <[email-masked]>
Date: Thu, 9 Apr 2009 18:12:01 -0400

> Bibliographic Format is NOT the answer!

In theory, there is no difference between practice and theory, but in
practice there is.  In theory, Yet Another XML Bibliographic Format is NOT
the answer, but it in practice it is.  ;-)

Kevin

[email-masked]
(828) 262-8472

---

From: Bill Dueber <[email-masked]>
Date: Thu, 9 Apr 2009 22:37:08 -0400

> Bibliographic Format is NOT the answer!

I recognize that you're being flippant, and yet think there's an important
nugget in here.

When you say it that way, it makes it sound as if folks are debating the
finer points of OAI-MARC vs MARC-XML -- that it's simply syntactic sugar
(although I'm certainly one to argue for the importance of syntactic sugar)
over the top of what we already have.

What's actually being discussed, of course, is the underlying data model.
E-R pairs primarily analyzed by set theory, triples forming directed graphs,
whether or not links between data elements can themselves have attributes --
these are all possible characteristics of the fundamental underpinning of a
data model to describe the data we're concerned with.

The fact that they all have common XML representations is noise, and
referencing the currently-most-common xml schema for these things is just
convenient shorthand in a community that understands the exemplars. The fact
that many in the library community don't understand that syntax is not the
same as a data model is how we ended up with RDA.  (Mike: I don't know your
stuff, but I seriously doubt you're among that group. I'm talkin' in
general, here.)

Bibliographic data is astoundingly complex, and I believe wholeheartedly
that modeling it sufficiently is a very, very hard task. But no matter the
underlying model, we should still insist on starting with the basics that
computer science folks have been using for decades now: uids  (and, these
days, guids) for the important attributes, separation of data and display,
definition of sufficient data types and reuse of those types whenever
possible, separation of identity and value, full normalization of data, zero
ambiguity in the relationship diagram as a fundamental tenet, and a rigorous
mathematical model to describe how it all fits together.

This is hard stuff. But it's worth doing right.

-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library

---

From: Ross Singer <[email-masked]>
Date: Fri, 10 Apr 2009 09:05:39 -0400

> This is hard stuff. But it's worth doing right.
 +1

The issue here isn't about serializations or transmission formats.
It's about data modeling.  Our current bibliographic data model is
horribly inefficient, with antiquated design ideas and far too rigid
to handle the explosion in information sources, and that has nothing
to do with ISO 2709 (although the byte limit might).

Then there's the actual inventory control data model...

-Ross.

---

From: Sharon Foster <[email-masked]>
Date: Sat, 11 Apr 2009 09:08:53 -0400

+1

Sharon M. Foster, 91.7% Librarian
Speaker-to-Computers
http://www.vsa-software.com/mlsportfolio/