Print

Print


When I compare the Bibframe method to record music work attributes with instruments etc. and the Music Ontology http://musicontology.com/, I feel kind of frustrated. 

There again, a mechanism to match library catalog music (i.e. Bibframe) with existing music description entities on the Semantic Web is needed.

So many efforts exist, like http://dbtune.org with more than 14 billion RDF triples.

I wonder if one should not be able to just take an entity of music description according to the rules of the Music Ontology, adds a catalog ID, relationship identifiers to publisher entities, and specific library service description how to obtain the music (aka holdings), and that's it?

I do not expect that *all* music in the catalogs can make reuse of existing sources, but the linking to other sources *if* there already exists some other information is crucial in my eyes.

It's not about music only, you can also take movies, images, or other cultural endeavors as an example for linking requirements. Much of these is described or can be described by using CIDOC CRM.

Jörg



On Wed, Sep 3, 2014 at 12:07 AM, Karen Coyle <[log in to unmask]> wrote:
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:mediumOfPerformance
                <http://id.loc.gov/authorities/performanceMediums/mp2013015507> .
               mybibframe:numberOfInstruments "3" ) ;
             mybibframe:instrument (
                 mybibframe:mediumOfPerformance             
                <http://id.loc.gov/authorities/performanceMediums/mp2013015306>  .
                 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.

kc

[1] O'NEILL, E. T., & CHAN, L. M. (2003). FAST (Faceted Application of Subject Terminology) a simplified LCSH-based vocabulary. [Hague, Netherlands], IFLA. http://www.ifla.org/IV/ifla69/papers/010e-ONeill_Mai-Chan.pdf.
[2] http://www.ifla.org/node/923


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

Kirk-Evan Billet

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