Re: [CODE4LIB] MODS and DCTERMS

No apologies required — your dissection of the (very important) differences between MODS and DCTERMS, both in concept and format, was extremely enlightening and helpful; as was all the other input. Any misunderstandings are much more my fault for not being clearer when Ross asked what my use ca

Re: [CODE4LIB] MODS and DCTERMS

Thank you for this clarification, MJ. I apologize for my initial reaction that there was little value here. Knowing the use-case you define below, I think there's a great deal of value. Beyond just the pragmatic short-term gains, I think a development like this would help pin-point those areas

Re: [CODE4LIB] MODS and DCTERMS

>> Let me give another example: the Open Library API returns a JSON tree, eg. >> http://openlibrary.org/books/OL1M.json >> >> But what schema is this? And if it doesn't conform to a standard schema, >> does that make it useless? If it were based on DCTERMS, at least I'd have a >> reference

Re: [CODE4LIB] MODS and DCTERMS

Quoting MJ Suhonos : Let me give another example: the Open Library API returns a JSON tree, eg. http://openlibrary.org/books/OL1M.json But what schema is this? And if it doesn't conform to a standard schema, does that make it useless? If it were based on DCTERMS, at least I'd have a

Re: [CODE4LIB] MODS and DCTERMS

> A more rational approach, IMO, would create a general description set > (probably numbering 20-50), then expanding that for more detail and for > different materials. Users of the sets could define the "zones" they wish to > use in an application profile, so no one would have to carry around data

Re: [CODE4LIB] MODS and DCTERMS

Oops, there was a typo in my namespace prefixes which screws up the datatypes for the integers. So, when reading these think: s/xmlns:xsd=\"http:\/\/www\.w3\.org\/2001\/XMLSchema#integer/xmlns:xsd=\"http:\/\/www\.w3\.org\/2001\/XMLSchema#/ and s/http:\/\/www\.w3\.org\/2001\/XMLSchema#integerinteg

Re: [CODE4LIB] MODS and DCTERMS

On Tue, May 4, 2010 at 10:26 AM, Mike Taylor wrote: > Ross, I think that got mangled in the sending -- either that, or it's > some strange format that I've never seen before.  That said, I am > tremendously impressed by all the information you obtained there. > What software did you use, how much

Re: [CODE4LIB] MODS and DCTERMS

I'd just like to say a word of thanks for everyone who has contributed so far on this thread. The viewpoints raised certainly help clarify at least my understanding of some of the issues and concepts involved. > MARCXML is a step in the right direction. MODS goes even further. Neither > really

Re: [CODE4LIB] MODS and DCTERMS

On 5/4/2010 9:54 AM, Karen Coyle wrote: BIBO, which many people seem to like, has almost 200 data elements and classes, and is greatly lacking in some areas (e.g. maps, music). What makes BIBO useful, in my limited experience, is that it integrates commonly used ontologies like FOAF and DCTER

Re: [CODE4LIB] MODS and DCTERMS

Ross, I think that got mangled in the sending -- either that, or it's some strange format that I've never seen before. That said, I am tremendously impressed by all the information you obtained there. What software did you use, how much of this did you have to feed it by hand, and how much did it

Re: [CODE4LIB] MODS and DCTERMS

On Tue, May 4, 2010 at 8:24 AM, Mike Taylor wrote: > On 4 May 2010 13:19, Ross Singer wrote: >> On Tue, May 4, 2010 at 7:55 AM, Mike Taylor wrote: >>> Having read the rest of this thread, I find that nothing that's been >>> said changes my initial gut reaction on reading this question: DO NOT >>

Re: [CODE4LIB] MODS and DCTERMS

Quoting Chad Fennell : 2. MARC21 bib data -- very detailed, well over 1,000 different data elements I can understand appreciating the richness of #2, but 1k data elements (choices I have to make) seems, to me, more like evidence of a core problem with MARC21 than a core strength. While you

Re: [CODE4LIB] MODS and DCTERMS

On Tue, May 4, 2010 at 8:24 AM, Mike Taylor wrote: > Oh, what is the solution when using it in RDF? I've been using the Bibliographic Ontology myself: http://bibliontology.com/ Lots of stuff in there for journals, etc ... and reuse of other vocabularies like event, foaf, prism and (ahem) dcte

Re: [CODE4LIB] MODS and DCTERMS

On 4 May 2010 13:19, Ross Singer wrote: > On Tue, May 4, 2010 at 7:55 AM, Mike Taylor wrote: >> Having read the rest of this thread, I find that nothing that's been >> said changes my initial gut reaction on reading this question: DO NOT >> USE DCTERMS.  It's vocabulary is Just Plain Inadequate,

Re: [CODE4LIB] MODS and DCTERMS

On Tue, May 4, 2010 at 7:55 AM, Mike Taylor wrote: > Having read the rest of this thread, I find that nothing that's been > said changes my initial gut reaction on reading this question: DO NOT > USE DCTERMS.  It's vocabulary is Just Plain Inadequate, and not only > for esoteric cases like the Alt

Re: [CODE4LIB] MODS and DCTERMS

Having read the rest of this thread, I find that nothing that's been said changes my initial gut reaction on reading this question: DO NOT USE DCTERMS. It's vocabulary is Just Plain Inadequate, and not only for esoteric cases like the Alternative Chronological Designation of First Issue or Part of

Re: [CODE4LIB] MODS and DCTERMS

> 2. MARC21 bib data -- very detailed, well over 1,000 different data > elements I can understand appreciating the richness of #2, but 1k data elements (choices I have to make) seems, to me, more like evidence of a core problem with MARC21 than a core strength.

Re: [CODE4LIB] MODS and DCTERMS

I think there's a fundamental difference between MODS and DCTERMS that make this nearly impossible. I've sometimes described this as the difference between "metadata as record format" (MARC, oai_dc, MODS, etc) and "metadata as vocabulary" (DCTERMS, DCAM, & RDF Vocabs in general). These aren't

Re: [CODE4LIB] MODS and DCTERMS

On May 3, 2010, at 2:47 PM, Aaron Rubinstein wrote: >> 1. MARC the data format -- too rigid, needs to go away >> 2. MARC21 bib data -- very detailed, well over 1,000 different data >> elements, some well-coded data (not all); unfortunately trapped in #1 > > For the sake of my own understanding, I

Re: [CODE4LIB] MODS and DCTERMS

ave about > the material: > What is it called? Who made it? When was it made? How big is it? What is it > about? Answers to the question, How can I get it? are usually given in the > associated MARC holdings record. > > > -Original Message- > From: Code for Libraries

Re: [CODE4LIB] MODS and DCTERMS

What is it about? Answers to the question, How can I get it? are usually given in the associated MARC holdings record. -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Roy Tennant Sent: Monday, May 03, 2010 2:15 PM To: CODE4LIB@LISTSERV.N

Re: [CODE4LIB] MODS and DCTERMS

s [mailto:code4...@listserv.nd.edu] On Behalf Of Roy Tennant Sent: Monday, May 03, 2010 2:15 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] MODS and DCTERMS I would even argue with the statement "very detailed, well over 1,000 different data elements, some well-coded data (not all)". There

Re: [CODE4LIB] MODS and DCTERMS

On Mon, May 3, 2010 at 2:40 PM, MJ Suhonos wrote: > Yes, even to me as a librarian but not a cataloguer, many (most?) of these > elements seem like overkill. I have no doubt there is an edge-case for > having this fine level of descriptive detail, but I wonder: > > a) what proportion of records

Re: [CODE4LIB] MODS and DCTERMS

On 5/3/2010 1:55 PM, Karen Coyle wrote: 1. MARC the data format -- too rigid, needs to go away 2. MARC21 bib data -- very detailed, well over 1,000 different data elements, some well-coded data (not all); unfortunately trapped in #1 For the sake of my own understanding, I would love an explana

Re: [CODE4LIB] MODS and DCTERMS

> NB: When Karen Coyle, Eric Morgan, and Roy Tennant all reply to your thread > within half an hour of each other, you know you've hit the big time. Time to > retire young I think. That would be Eric *Lease* Morgan — oh my god, you're right! I'm already losing data! It *is* insidious! I rep

Re: [CODE4LIB] MODS and DCTERMS

> So, back to my statement, let me re-state it as: > > "dcterms is so terribly lossy that it would be a shame to reduce MARC21 bib > data to it." Right — sorry, I think I did understand your original point as meaning this, but both you and Eric reiterate a fine point about the endless confusion

Re: [CODE4LIB] MODS and DCTERMS

On Mon, May 3, 2010 at 2:03 PM, Eric Lease Morgan wrote: > "MARC must die. Long live MARC." > Speaking as a "non-library computer type," let me say "MARC must die. MARC must die." MARC21 bib data is a mess of "hopefully-unique" strings, inlined punctuation, and arcane rules that do a good job

Re: [CODE4LIB] MODS and DCTERMS

I would even argue with the statement "very detailed, well over 1,000 different data elements, some well-coded data (not all)". There are only 11 (yes, eleven) MARC fields that appear in 20% or more of MARC records currently in WorldCat[1], and at least three of those elements are control numbers o

Re: [CODE4LIB] MODS and DCTERMS

On May 3, 2010, at 1:55 PM, Karen Coyle wrote: > 1. MARC the data format -- too rigid, needs to go away > 2. MARC21 bib data -- very detailed, well over 1,000 different data > elements, some well-coded data (not all); unfortunately trapped in #1 The differences between the two points enumerat

Re: [CODE4LIB] MODS and DCTERMS

Quoting MJ Suhonos : dcterms so so terribly lossy that it would be a shame to reduce MARC to it. This is *precisely* the other half of my rationale — a shame? Why? If MARC is the mind prison that some purport it to be, then let's see what a system built devoid of MARC, but based on the

Re: [CODE4LIB] MODS and DCTERMS

> dcterms so so terribly lossy that it would be a shame to reduce MARC to it. This is *precisely* the other half of my rationale — a shame? Why? If MARC is the mind prison that some purport it to be, then let's see what a system built devoid of MARC, but based on the best alternative we have l

Re: [CODE4LIB] MODS and DCTERMS

Oops, just sent this Karen by mistake... -Ross. On Mon, May 3, 2010 at 12:52 PM, Ross Singer wrote: > On Mon, May 3, 2010 at 12:37 PM, Karen Coyle wrote: > >> dcterms so so terribly lossy that it would be a shame to reduce MARC to it. >> What we need, ASAP, is a triple form of MARC (and I know

Re: [CODE4LIB] MODS and DCTERMS

QDC basically represents the same things has dcterms, so you can probably just take the existing XSLT and hack on it until it until it represents something that looks more like dcterms than qdc. That won't address of the issue of breaking up the MARC into individual resources, however. You mentio

Re: [CODE4LIB] MODS and DCTERMS

Quoting MJ Suhonos : Sure, my goal is simple in theory and complex in practice: take a pile of MARC records and turn them into a set of DCTERMS (I'll avoid reference to the older QDC notion) so that I can do interesting things with them — the simplest use case being exposing a "record"

Re: [CODE4LIB] MODS and DCTERMS

Sure, my goal is simple in theory and complex in practice: take a pile of MARC records and turn them into a set of DCTERMS (I'll avoid reference to the older QDC notion) so that I can do interesting things with them — the simplest use case being exposing a "record" as a pile of RDF triples. The

Re: [CODE4LIB] MODS and DCTERMS

On Mon, May 3, 2010 at 12:01 PM, Riley, Jenn wrote: >> >> So wait, why didn't the QDC people just use oai_dc too? > > 'Cause the properties in oai_dc are the simple DC properties - no way to just > tack on the additional features needed for QDC (a few additional elements, > refinements, stateme

Re: [CODE4LIB] MODS and DCTERMS

Out of curiosity, what is your use case for turning this into DC? That might help those of us that are struggling to figure out where to start with trying to help you with an answer. -Ross. On Mon, May 3, 2010 at 11:46 AM, MJ Suhonos wrote: > Thanks for your comments, guys.  I was beginning to t

Re: [CODE4LIB] MODS and DCTERMS

> -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Jonathan Rochkind > Sent: Monday, May 03, 2010 11:40 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] MODS and DCTERMS > > So wait, why didn't the Q

Re: [CODE4LIB] MODS and DCTERMS

Thanks for your comments, guys. I was beginning to think the lack of response indicated that I'd asked something either heretical or painfully obvious. :-) > That's my understanding as well. oai_dc predates the defining of the 15 > legacy DC properties in the dcterms namespace, and it's my gue

Re: [CODE4LIB] MODS and DCTERMS

So wait, why didn't the QDC people just use oai_dc too? Riley, Jenn wrote: I'm still confused about all this stuff too, but I've often see the oai_dc format (for OAI/PMH I think?) used as a 'standard' way to expose simple DC attributes. Yep, it's the same approach as was taken with the QD

Re: [CODE4LIB] MODS and DCTERMS

> I'm still confused about all this stuff too, but I've often see the > oai_dc format (for OAI/PMH I think?) used as a 'standard' way to expose > simple DC attributes. Yep, it's the same approach as was taken with the QDC format CONTENTdm uses that I mentioned - a third party defining its own wra

Re: [CODE4LIB] MODS and DCTERMS

I'm still confused about all this stuff too, but I've often see the oai_dc format (for OAI/PMH I think?) used as a 'standard' way to expose simple DC attributes. One thing I was confused about was whether the oai_dc format _required_ the use of the "old style" DC uri's, or also allowed the use

Re: [CODE4LIB] MODS and DCTERMS

Hi MJ, > - for that matter, is there a good example of how to "properly" > serialize DCTERMS for eg. a converted MARC/MODS record in XML (or > RDF/XML)? I see, eg. > which has been replaced by > but I'm not s

[CODE4LIB] MODS and DCTERMS

Hi all, I'm digging into earlier threads on Code4Lib and NGC4lib and trying to get some concrete examples around the DCTERMS element set — maybe I haven't been a subscriber for long enough. What I'm looking for in particular are things I can work with *in code/implementation*, most notably: -