Print

Print


RDF also has ordered collections, called rdf:Seq. Like the SKOS collection it appears to be oriented toward display (and as such could be used for the eye-readable publication statement). It also has rdf:List, which is a kind of linked list with a chain from first -> rest -> last. Although these exist, they are apparently awkward to work with compared to simple triples. Therefore, like blank nodes, they give you an out when you have no other choice, but other solutions (like re-thinking the actual meaning of the data elements that were previously connected by order) are preferable.

Given that MARC bibliographic was essentially a display format, we have to assume that in some cases (publisher statement being an obvious one) there was no impetus to develop a more precise coding. It is instructive to compare the treatment of the basic bibliographic fields in MARC bibliographic to the MARC holdings format, which was designed for machine processing, especially in the area of serial receipt prediction. I'm in favor of doing this re-thinking NOW before we move these practices into BIBFRAME. Note, however, that this will require collaboration with the cataloging community, since in some cases the rules may still support the older concepts.

kc

On 9/3/14, 7:09 AM, Murray, Ronald wrote:
[log in to unmask]" type="cite">
If RDF is supposed to be representing information as graphs, then it should also have the ability to represent orderings among linked elements in RDF graphs. This is how fundamental structures like directed graphs (think about map directions) are constructed.

---> If I had not dug a little deeper, I would have said this ---> This sounds like an oversight at RDF design time, probably due to the designers (a.) not following through on their basic graph definitions, or (b.) not being able to imagine the need for data ordering,  (c.) not looking around for existing graph-like resource description structures in the wild (e.g., library catalogs from Cutter on). Given that lapse at the RDF design level, is there a reason not to implement graph ordering in RDA? All order-oriented graph definitions can be found in graph theory textbooks, and algorithms for traversing ordered graphs – and especially knowing when to stop – are equally accessible.

However - SKOS already includes a definition of an OrderedCollection (thanks, RDF folks!):

<rdf:Description rdf:about="#OrderedCollection">
<rdfs:label xml:lang="en">Ordered Collection</rdfs:label>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
<skos:definition xml:lang="en">An ordered collection of concepts, where both the grouping and the ordering are meaningful.</skos:definition>
<skos:scopeNote xml:lang="en">Ordered collections can be used where you would like a set of concepts to be displayed in a specific order, and optionally under a 'node label'.</skos:scopeNote>
<!-- S28 -->
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
<!-- S29 --><rdfs:subClassOf rdf:resource="#Collection"/>
</rdf:Description>

But the SKOS scope note does not suggest/dictate that element ordering can play a role beyond data display.

Now we know better, and need to correct our BIBFRAME conceptualization & implementation to (a.) accommodate the previous examples, and (b.) generalize the use of OrderedCollections for application elsewhere. 

Ron Murray



From: Karen Coyle <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Tuesday, September 2, 2014 6:07 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Medium of performance (Music) question

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:
[log in to unmask]" type="cite">
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

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