Nate, this is getting closer to what I have put forth as a possible alternative to WEMI. I'll try to explain.

WEMI gives a "cascade" of bibliographic information, from Work to Item. It has been interpreted as being a strict division of that information into four separate entities. A few years ago in a blog post [1] I tried to explain that rather than four separate entities we have a "build" from Work to Manifestation (with Item being local data primarily). I now see this build as separate views not separate entities, and that these views can be derived from full bibliographic descriptions.

Again, this one needs lots of examples and diagrams, and I have a document with examples that I will dust off and turn into a blog post Real Soon Now. But suffice it to say that if you have (using terms from Sally's document):

                - work title for every work (uniform and "derived uniform")

                - subject access elements (vocabularies like LCSH and MESH)

                - subject access elements (classification part of call numbers)

                - content type

                - language and other expression information

                - manifestation title

                - description information

                - provider information


... you can create any number of graphs "on the fly" for whatever functionality you need. Need Work info? then gather into a graph:

                - work title for every work (uniform and "derived uniform")

                - subject access elements (vocabularies like LCSH and MESH)

                - subject access elements (classification part of call numbers)

                - content type


Need Expression info? Then gather into a graph:

                - work title for every work (uniform and "derived uniform")

                - subject access elements (vocabularies like LCSH and MESH)

                - subject access elements (classification part of call numbers)

                - content type

                - language and other expression information


Want to display or index or somehow use a manifestation? You create a graph with:

                - work title for every work (uniform and "derived uniform")

                - subject access elements (vocabularies like LCSH and MESH)

                - subject access elements (classification part of call numbers)

                - content type

                - language and other expression information

                - manifestation title

                - description information

                - provider information


The basic "rule" here is that each data element has a clear definition that allows you to know what it is describing (WEM, or some other division like BIBFRAME:WI). These can then be used to create any number of different views, depending on your needs. Catalogers may need a hierarchical view, as John Myers has articulated [2], designed for re-usability of often-used groups of data. A search and display system may want to create a view like this when returning initial results:

Maxim Gorky
 - Mother
 - Creatures that once were men

which does not correspond to any FRBR entity.

The upshot of this is that rather than designing our future on a single physical model, we should be designing data that can be used in a variety of combinations, as needed. To do this, especially in linked data, the data definition is the most important thing (the "ontology" as it were), and the structuring of that data in graphs is flexible and variable, according to needs.

I feel like, in large part due to how FRBR has been defined [3], we have confused the "view" with the underlying data, spending our time imposing *a* structure, whereas in linked data structures do not define your data - instead, your data is available to be used in a wide variety of structures, called "graphs."

kc

[1] http://kcoyle.blogspot.com/2010/05/frbr-and-sharability.html
[2] http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=bibframe&T=0&O=A&P=47150
[3] FRBR was an abstract model, but unfortunately it got mixed up with a relational database design and the entities became solidified as separate "things". This is unfortunately not compatible with linked data, and should only be seen as relevant to data in relational databases, not to linked data. Perhaps going back to the original concepts in FRBR as an abstract model would be useful, ignoring the leap from that to database design.

On 5/24/13 6:58 AM, Trail, Nate wrote:
[log in to unmask]" type="cite">

The bf:Work does not contain the FRBR:Expression, it links to it. The FRBR:Expression is another BF:Work with a few extra properties like language that make it a FRBR:Expression.

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Friday, May 24, 2013 9:42 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe

 

If a BIBFRAME Work can have an Expression, where is that Expression? To "have" it, the Expression needs to have a separate URI, which means that it has to be a "thing" -- it has to be its own circle in the diagram. But there is no Expression circle in the diagram.

I had understood that the FRBR-type elements for Work and Expression were both to be entered into the BIBFRAME Work, and the examples seem to show that. I'm going to assume that "hasExpression" is not usable, but has not been removed from the documentation.

kc

On 5/24/13 12:41 AM, Meehan, Thomas wrote:

Laura,


As I understand it, a BIBFRAME Work can be both a FRBR Work and a FRBR Expression. The BIBFRAME vocab for Work defines both expressionOf and hasExpression properties so one BIBFRAME Work could be an expression of another BIBFRAME Work.

 

Thanks,

 

Tom

 

---

 

Thomas Meehan

Head of Current Cataloguing

Library Services

University College London

Gower Street

London WC1E 6BT

 

t.m[log in to unmask]

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Laura Krier
Sent: 23 May 2013 23:50
To: [log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe

 

Jorg,

Your breakdown here is really helpful for me, but I have a question about your conception of how the library-controlled information is handled in BIBFRAME.

 

On May 23, 2013, at 12:12 PM, Jörg Prante <[log in to unmask]> wrote:




- extract all library-controlled information out of the FRBR classes - the formal description, the classification, the subject cataloging, the call number, the shelf location, authority control information, (maybe also descriptions of the library service for access to printed and electronic resources, it's not clear right now) etc. Put that also into bf:Instance.

 

I don't know that I would consider this Instance information under the BIBFRAME definition of Instance. A lot of it (call number, shelf location, library service) seems more like item information, and might be a library annotation. It's related to a specific library's copy of an Instance. 




I'm also still a little baffled about BIBFRAME's use of Work. I can't figure out whether it's closer to FRBR's concept of Work (conceptual essence) or Expression. Personally, I think something closer to Expression would be more important for libraries' goals, and the line seems very blurred to me, here. Are we describing a particular expression of a conceptual essence, or the concept/idea itself? Or both? I  suppose I will have to anxiously await the release of the Creative Work discussion paper. (Though your suggestion to go back to the Primer was a very useful one.)

 

Laura

--

Laura Krier

Metadata Analyst

California Digital Library

 

510-987-0832

 

 



-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet