Print

Print


On 11/7/14 5:40 PM, Robert Sanderson wrote:
>
>
> On Thu, Nov 6, 2014 at 12:53 PM, Karen Coyle <[log in to unmask] 
> <mailto:[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.

>
>     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
>     <http://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.

>
>     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 <http://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.

>
>     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.

>
> +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
https://listserv.loc.gov/cgi-bin/wa?A3=ind1411&L=BIBFRAME&E=7bit&P=774321&B=--------------000900050205000006090101&T=text%2Fplain;%20charset=utf-8&header=1
listserv.loc.gov
crawl=CC-MAIN-2022-49
6229
application/http; msgtype=response
sha1:7VYRCB4BSWWQEESBGXDIDU76IIQR4IXP
<urn:uuid:6d0b4cfc-b37d-46bb-9f03-039eb85708df>
2022-11-29T17:50:06Z
140.147.239.86
text/html
sha1:X7K3QWL3V5AHI5GENBEDZQ4TR4D77CRX
<urn:uuid:bee2c63f-f7cb-42ed-925a-d71b0364b610>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1411&L=BIBFRAME&E=7bit&P=774321&B=--------------000900050205000006090101&T=text%2Fplain;%20charset=utf-8&header=1
response
<urn:uuid:8c01a7f3-10db-4f45-8508-c45af6673212>
isPartOf: CC-MAIN-2022-49
publisher: Common Crawl
description: Wide crawl of the web for November/December 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-71
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/