Re: BIBFRAME and schema.org

Well, I tried responding inline, but apparently my tablet is going to make
that impossible.

Re: the FRBR thing, I think schemabibex has absolutely made the case for
commonEndeavour (without even regarding any of the other properties) in
some capacity. I hope we can drop any notion of WEM (I'll argue that OCLC
makes a decent --optional-- case for I), but I hope we don't give up the
goal of semantically linking fundamentally like things.

-Ross.
On Jun 30, 2013 9:15 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>
> Oddly, I didn't get James' post... so I'll answer it on Jeff's...
>
>
> On 6/30/13 3:36 PM, Young,Jeff (OR) wrote:
>
>
>>>
>>> As a result, schemabibex can exist not only *long* before BIBFRAME
>>> will, but it can also start being used very quickly and if it is well
>>> done, has the potential to become very popular and widespread.
>
>
> Jim,
>
> schemabibex is the name of the group looking to extend schema.org for
bibliographic data. schema.org already exists, is already being used, AND
has most of what you would need to mark up a web page that has information
about books, movies and recorded music. It isn't a substitute for BIBFRAME
by any means, in part because it isn't a library standard.
>
>
>
> It
>>>
>>> seems to me that relating all of that to FRBR can only hinder the
>>> adoption.
>
>
> I totally agree. I even question the Work/Instance breakdown of BIBFRAME.
I think that people are confusing the concept of "work" with the definition
of Work in FRBR and BIBFRAME. You can have a concept of "work" without
creating an artificial division where descriptions of actual books can't
have subject headings because that's in the "work record." A book HAS an
author and subjects and an ISBN and a publisher -- altogether. The concept
of a work doesn't take some of those away from the real book (or movie or
whatever).
>
>
>
>
>>>
>>> Anyway, BIBFRAME itself is already overthrowing the FRBR data model,
>>> in favor of instance and work, or what I have always called
>>> description and headings.
>
>
> Actually, I don't think that's the criterion for the division. There are
some headings in bf:Instance, and some description in bf:Work. The
separation has been defined as "abstract vs. concrete" in the BIBFRAME
documentation. Personally I think that "description and headings" makes
sense, but that's not how FRBR approached it, as far as I can ascertain.
>
> kc
>
>
>>>
>>> It just seems to me that after schemabibex is adopted, it will 1)
>>> exist, and 2) be easy to implement. Therefore it should be used quite
>>> widely. BIBFRAME will have to adapt to schemabibex.
>>>
>>> --
>>> *James Weinheimer* weinheimer.jim.l@gmail.com
>>> *First Thus* http://catalogingmatters.blogspot.com/
>>> *First Thus Facebook Page* https://www.facebook.com/FirstThus
>>> *Cooperative Cataloging Rules*
>>> http://sites.google.com/site/opencatalogingrules/
>>> *Cataloging Matters Podcasts*
>>> http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html
>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>