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 forward.
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:
<piece for oboe and guitar> a bf:Work ;
bf:Title “Title of this piece for oboe
and guitar” ;
Or something like that.
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 "normal"
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
. [Hague, Netherlands], IFLA.
On 9/1/14, 1:44 PM, Kirk-Evan
[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