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 http://vocab.org/frbr) 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) Casey 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 650-736-0849 [log in to unmask] http://www.caseymullin.com