Print

Print


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:
>
> 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
>     <http://bibframe.org/vocab/Work.html> defines both expressionOf
>     <http://bibframe.org/vocab/expressionOf.html> and hasExpression
>     <http://bibframe.org/vocab/hasExpression.html> 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
>
>     [log in to unmask] <mailto:[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] <mailto:[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]
>     <mailto:[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]  <mailto:[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