I had to go back and read the blog post because it was 5 years ago
and I didn't remember the particulars. (OK, I also didn't remember
the generalities ;-))
I think you are right to be thinking about this. Connecting elements
based on their order is not something we can easily achieve with
RDF, and I would think is not a practice that we want to carry
Unlike MARC or XML, RDF emphasizes individual, atomic elements, and
in fact doesn't do order very well. There are mechanisms for
imposing order in RDF but what I hear from RDF developers is that
one should use ordering very sparingly. We can, however, create
logical groups of elements, such as the instrument and the number. I
believe that is what Joerg was demonstrating, although to include
the number we would need yet another level of grouping:
Or something like that.
<piece for oboe and guitar> a bf:Work ;
bf:Title “Title of this piece for oboe and
We need to rethink areas of our records that depend on order today.
Some places where it is used it could be replaced by separate data
elements, each with their own meaning. For example, a 245 with
parallel titles, each in a $a with related $b's needs to become two
separate title "graphs", one for each set of title elements for a
language. The very unfortunate $g in the MARC X00 fields (which can
contain information relating to either the author portion or the
title portion of the field, depending on where it is placed) needs
to be rethought entirely. Ditto multiple $x subfields in the 6XX
area. If the order of those is important for its meaning, then we
will need to resolve that by combining them into a single element,
or defining better what each $x means. (See examples on page 72 of
Chan & O'Neill on FAST , where they show topics with
qualifiers, but not actual subdivisions. I don't know if this is the
Another difficulty is the repeatability of data, especially in cases
where US libraries (or perhaps all anglo-american libraries) do not
separately catalog the resources in aggregates. Even today I believe
that many library systems do not separately index, say, subject
fields, so that one gets false hits from words in different subject
headings. This problem is compounded in music data because so much
of one's holdings consists of aggregates, and some terms
(symphonies, concertos) are so common that without a uniform title
browse you can't get much precision in searching. To me this says
that we haven't adequately identified the *things* in our data and
therefore are mixing together elements that should be attributes of
different resources. RDA skims past this a bit by allowing one to
identify individual works, but FRBR, as one can see from the
solution proposed by the Working Group on Aggregates , failed
(IMO) to come up with a workable solution (thus at least in part
negating the nice attempt by RDA).
Now is the time to resolve these issues, before they become baked
into yet another library data model.
O'NEILL, E. T., & CHAN, L. M. (2003). FAST (Faceted
Application of Subject Terminology) a simplified LCSH-based
vocabulary. [Hague, Netherlands], IFLA.
On 9/1/14, 1:44 PM, Kirk-Evan Billet
[log in to unmask]"
It’s a Bibframe vocabulary question and also a syntax question. I want to refer back to something Karen Coyle discussed in 2009, responding to Martha Yee ( http://kcoyle.blogspot.com/2009/07/yee-questions-9-11.html ). I’m calling it the “two oboes and three guitars” problem, but I’ll reduce it down to just the 1 oboe and 1 guitar problem.
For some music resource with an instrumentation of oboe plus guitar, we might have, in MARC:
382 0 $a oboe $n 1 $a guitar $n 1 $s 2 $2 lcmpt
But in Bibframe, the following would be inaccurate:
<piece for oboe and guitar> a bf:Work ;
bf:Title “Title of this piece for oboe and guitar” ;
bf:[?property] <http://id.loc.gov/authorities/performanceMediums/mp2013015507> ;
bf:[?property] <http://id.loc.gov/authorities/performanceMediums/mp2013015306> ;
because the medium of performance is not oboe and it’s also not guitar; it’s oboe + guitar. Is there a syntax that can “wrap” these two separate statements together so that we’re making one assertion about the work’s medium? Alternatively, and especially since no such bf property currently exists (have I missed it?), is this a case where it is expected that we will use a non-bf vocabulary? (bf:musicMedium is included in category “Title information” and corresponds to MARC bib 240 $m or auth 1XX $m.)
Thanks for any insights, clarifications, or corrections.
[log in to unmask] http://kcoyle.net