I completely agree with Karen regarding how FRBR falls short in not 
allowing for more relationships between Group 1-2 and Group 3 entities. 
FRBRoo fleshes out some of these things, but in a woefully unweildy way, 
IMO. Conversely, FRBR in RDF (at consolidates 
some classes and properties (e.g. Responsible entity, a superclass of 
Person, Family and Corporate body), and to me approaches the kind of 
extensibility we need. Unfortunately, it does not include data 
properties, which I agree are problematic, as Karen illustrates.

I do maintain that FRBR is the kind of *conceptual* model that, for the 
most part, can guide the development of effective data structures. 
However, it is far too abstract to be implemented verbatim. This is what 
I think RDA is trying to do with attributes like "Title for the work" I 
wonder: why is there not an ontology expert on the JSC?? (If I'm wrong 
and there is, someone please correct me)


Karen Coyle wrote:
> Extensibility as absolutely key. I know that some people consider XML 
> to be inherently extensible, but I'm concerned that the conceptual 
> model presented by FRBR doesn't support extensibility. For example, 
> the FRBR entity "Place" represents only the place as a subject. If you 
> want to represent places anywhere else in the record, you are SOL. 
> Ditto the "Event" entity. The attributes in FRBR have no inherent 
> structure, so you have, say, Manifestation with a whole page of 
> attributes that are each defined at the most detailed level. You have 
> "reduction ratio (microform)" but no "reproduction info" field that 
> you could extend for another physical format. You have "date of 
> publication" but no general "date" property that could be extended to 
> other dates that are needed (in fact, the various date fields have no 
> relation to each other).
> To have an extensible data structure we need to have some foundation 
> "classes" that we can build on, and nothing in FRBR, RDA, or MARC 
> gives us that.
> kc
> Casey A Mullin wrote:
>> (Attention: lurker emerging)
>> To me what it comes down to is neither simplicity nor complexity, but 
>> extensibility. In a perfect world, our data models should be capable 
>> of representing very sophisticated and robust relationships at a high 
>> level of granularity, while still accommodating ease of metadata 
>> production and contribution (especially by non-experts and those 
>> outside the library community).
>> I agree that none of our existing data structures/syntaxes are /a 
>> priori /fundamental or infallible. But what is promising to me about 
>> RDF is its intuitive mode of expression and extensibility (exactly 
>> the kind I advocate above).
>> Casey
>> Han, Yan wrote:
>>> Bill and Peter,
>>> Very nice posts. XML, RDF, MARC and DC are all different ways to 
>>> present information in a way (of course, XML, RDF, and DC are easier 
>>> to read/processed by machine).
>>> However, down the fundamentals, I think that it can go deeper, 
>>> basically data structure and algorithms making things works. RDF 
>>> (with triples) is a directed graph. Graph is a powerful (the most 
>>> powerful?) data structure that you can model everything. However, 
>>> some of the graph theory/problems are NP-hard problems. In 
>>> fundamental we are talking about Math. So a balance needs to be 
>>> made. (between how complex the model is and how easy(or possible) to 
>>> get it implemented). As computing power grows, complex data modeling 
>>> and data mining are on the horizon.
>>> Yan
>>> -----Original Message-----
>>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf 
>>> Of Peter Schlumpf
>>> Sent: Thursday, April 09, 2009 10:09 PM
>>> To: [log in to unmask]
>>> Subject: [CODE4LIB] You got it!!!!! Re: [CODE4LIB] Something 
>>> completely different
>>> Bill,
>>> You have hit the nail on the head!!!!!  This is EXACTLY what I am 
>>> trying to do!  It's the underlying stuff that I am trying to get 
>>> at.   Looking at RDF may yield some good ideas.  But I am not 
>>> thinking in terms of RDF or XML, triples, or MARC, standards, or any 
>>> of that stuff that gets thrown around here.  Even the Internet is 
>>> not terribly necessary.  I am thinking in terms of data structures, 
>>> pointers, sparse matrices, relationships between objects and yes, 
>>> set theory too -- things like that.  The former is pretty much cruft 
>>> that lies upon the latter, and it mostly just gets in the way.  
>>> Noise, as you put it, Bill!
>>> A big problem here is that Libraryland has a bad habit of getting 
>>> itself lost in the details and going off on all kinds of tangents.  
>>> As I said before, the biggest prison is between the ears!!!!  Throw 
>>> out all that junk in there and just start over!  When I begin 
>>> programming this thing my only tools will be a programming language 
>>> (C or Java) a text editor (vi) and my head.  But before I really 
>>> start that, right now I am writing a paper that explains how this 
>>> stuff works at a very low level.  It's mostly an effort to get my 
>>> thoughts down clearly, but I will share a draft of it with y'all on 
>>> here soon.
>>> Peter Schlumpf
>>> -----Original Message-----
>>>> From: Bill Dueber <[log in to unmask]>
>>>> Sent: Apr 9, 2009 10:37 PM
>>>> To: [log in to unmask]
>>>> Subject: Re: [CODE4LIB] Something completely different
>>>> On Thu, Apr 9, 2009 at 10:26 AM, Mike Taylor <[log in to unmask]> 
>>>> wrote:
>>>>> I'm not sure what to make of this except to say that Yet Another XML
>>>>> 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

Casey A. Mullin
Discovery Metadata Librarian
Metadata Development Unit
Stanford University Libraries
[log in to unmask]