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” ;
             mybibframe:instrument (
<> .
                mybibframe:numberOfInstruments "3" ) ;
              mybibframe:instrument (
<> .
                  mybibframe:numberOfInstruments "1" ) .

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 [1], where 
they show topics with qualifiers, but not actual subdivisions. I don't 
know if this is the "normal" case.)

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 [2], 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.


[1] 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 wrote:
> 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 ( ). 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] <> ;
>              bf:[?property] <> ;
> 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.
> Kirk-Evan Billet

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