Re: BIBFRAME and schema.org

Agreed. - kc

On 6/30/13 7:08 PM, Ross Singer wrote:
> 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
> <mailto: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
> <http://schema.org> for bibliographic data. schema.org
> <http://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
> <mailto: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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>  > ph: 1-510-540-7596
>  > m: 1-510-435-8234
>  > skype: kcoylenet
>  >
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 1 July 2013 14:28:20 UTC