LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  February 2015

BIBFRAME February 2015

Subject:

Re: 2-tier BIBFRAME

From:

Karen Coyle <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Mon, 2 Feb 2015 11:04:11 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (53 lines)

On 2/2/15 7:31 AM, Martynas Jusevičius wrote:
> I think BIBFRAME tries to cover too much even in the Linked Data
> layer. For example, taxonomies and categorization are not specific to
> bibliographic data and are already covered by established vocabularies
> such as SKOS. I don't see why they should also be included in BF,
> unless they were added in support for MARC, in which case it is bad
> design.
>
> BIBFRAME should be the glue between different Linked Data vocabularies
> relevant to bibliographic data, and not a blanket to cover them all.

Yes, that's an argument that has been made here, but to no avail.

Here's another option that I see: Create links between MARC records and
related RDF triples without transforming the whole MARC record to RDF.
Begin slowly, and only add linkable data with specific goals in mind.

Much of what is in library/archive data has little or no value for
linking -- for searching, yes, for display, yes, but for linking, no.
It's become something of a cliche' to say that the MARC record is
primarily a mark-up of a textual description of the resource. Had it
been created in 1995 instead of 1965 the record would have been an XML
and/or HTML document. Very few of the fields/subfields in MARC are
actionable in any way except as they are bundled into a record-wide
keyword search.

We could start by identifying *linkable data* and adding that to our
data store, much like OCLC has added schema.org data to its MARC-based
online displays. This data could live in relation to the MARC record
without the necessity to transform the text of current library
cataloging into RDF (which I think isn't a good fit).

After working with this linkable data for a while, I think that people
will better understand the "document vs linked data" concept. I also
think that it will be easier to begin to transform our data because
we'll have an idea of what functionality we are wanting to support. At
the moment, it seems that we are transforming our data to RDF just for
the purpose of making it RDF. BIBFRAME, as currently conceived, will
provide few if any advantages over MARC because linking to web resources
is not one of the functions being considered. There are no BIBFRAME use
cases [1] that are about linking to resources, and many people complain
that BIBFRAME appears to be a huge change with no provable gain.

kc
[1] The use cases document seems to be have removed or at least unlinked
from the BF site, otherwise I would link to it here.

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

Top of Message | Previous Page | Permalink

Advanced Options