Print

Print

On 11/7/14 5:40 PM, Robert Sanderson wrote:
[log in to unmask]" type="cite">


On Thu, Nov 6, 2014 at 12:53 PM, Karen Coyle <[log in to unmask]> wrote:
Rob, it's not a theoretical question but a practical one. Much of the existing bibliographic data in the world does not follow FRBR or BIBFRAME, and many communities may never think about the difference between a Work and an Instance.

Sure. So why would those communities that do not follow bibframe then decide that they should (a) use bibframe and (b) use it incorrectly?

I wasn't implying that they would use BIBFRAME. Your question was: why would anyone not have an abstract entity and a physical entity? With BIBFRAME that's the model, but a lot of bibliographic data uses a different model. That doesn't mean that we should silo ourselves from those data sources. In fact, we should be actively trying to link to them.

[log in to unmask]" type="cite">

An easy example is a standard citation -- of which there are bazillions in the gazillions of already published articles, many of which are being digitized. A standard citation has elements like:

author (bf:Work)
title (bf:Instance)
publisher (bf:Instance)
date (bf:Instance)
pages (bf:Instance)

Should this data be coded in BibTex, schema.org, or whatever, it will almost certainly have a single resource identity to which the metadata elements are assigned. Presumably, at some point, this data and library data will be swimming in the same LoD soup, available for exploration and recombination.

And presumably they would then have to mint new identifiers to distinguish the Work from the Instance, if they wanted to actually use bibframe.
 
(Note that a lot of work is going into making citations linkable, e.g. at PLOS.)

Using bibframe? I would guess not.

No, as I said, this isn't about BIBFRAME. It's about the large sea of bibliographic data that I hope we'll also swim in.

[log in to unmask]" type="cite">
 

Then look at the folks who are intending to follow FRBR -- e.g. RDA -- and you see a different division that (arguably) has three abstract levels and one physical one. (You could argue that bf:Instance is still abstract, because it does not have actually physicality; that is reserved for the bf:Item.)

I don't buy the argument that people who are intending to follow a different model will suddenly require the same resource to be both an abstract concept and a physical thing at the same time.  They simply wouldn't use bibframe, the same way that bibframe doesn't use schema.org or bibo.

There are folks doing mix-n-match metadata. I haven't yet seen any that uses BF, but there are some that use the occasional RDA element. BIBO uses some DC,  PRISM and FOAF; there are a couple of bibliographic models that use some bits of FRBR in rather unexpected ways (see from: http://kcoyle.net/frbr/?page_id=81). So when you say "use BIBFRAME" you seem to see it as BIBFRAME as a whole, but the stats from the LOV vocabularies (http://lov.okfn.org/dataset/lov/) show a great deal of mixing and matching. We could find in an upcoming re-run of LOV that BF properties are leaking out into the world. There's nothing to require those uses to follow the BF 2-tier abstract model, just as there's nothing to require those who borrow bits of FRBR to divvy up the bibliographic world exactly as FRBR does.

[log in to unmask]" type="cite">

 
In addition, some communities within GLAM have argued that their division between abstract and physical will differ from what has been laid out in FRBR and BIBFRAME.

Ditto.

I'm not sure "ditto" what, but in fact these folks are part of our community and many currently use MARC. If there is a move to something beyond MARC, they will need to be accommodated. They are in fact looking at BIBFRAME, as the BF A-V report that I cited shows. Note that I say "communities within GLAM" which to me is *us*. I don't think we want to kick them out of the club because they have different needs.

[log in to unmask]" type="cite">

+1 to not asserting restrictive domains on predicates that imply impossible class combinations, to allow allied communities to work with us even though they have slightly different modeling requirements.

;)

Agreed, except, as I say above, I don't consider them to be "allied" - I consider them to be *us*.

kc


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600