LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  September 2014

BIBFRAME September 2014

Subject:

Re: Medium of performance (Music) question

From:

"[log in to unmask]" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Wed, 3 Sep 2014 13:57:52 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (168 lines)

I don't think anyone would argue that the notions to which you refer (e.g. "first author" and "last author") should be discarded. The question is, instead, how to record them. It was convenient in one model of description and one format to use ordering for that purpose, but that is no base on which to infer that it will be convenient or wise to so do in a completely different model and a complete different format. I think that is part of your claim. 

As a patron, I would be very happy to be able to distinguish the more important from the less important contributors to a work. I have no desire to infer that distinction myself on the basis of evidence in a particular display. I would rather the people who generated that display for me have taken the time to properly model the different relationships between the various contributors and the work, and display them in such wise as requires no inference from me. That may be by ordering them, by labeling them, by using color or some other visual distinction to the purpose… I can imagine uses for all these techniques. My point was only that in our example the ordering is not inherent in the data. The relationships between entities are inherent, and the ordering is just a technique of display accidentally imported back into the data itself.

---
A. Soroka
The University of Virginia Library

On Sep 3, 2014, at 1:44 PM, "Murray, Ronald" <[log in to unmask]> wrote:

> So yes, its a data modeling issue: 
> 
> There are social and maybe legal arrangements encoded in text layouts from which readers can make inferences based on order. In multiperson scholarly publications, for example, notions like "first author" and "last author" can be very important in evaluating source credibility. If we throw away such ordering due to the inability to represent it, we toss out an opportunity for end-user (or computed) inferencing. (This bumps us against a previous techno/cataloging policy-motivated data capture limitation - that of not enumerating all authors of a publication. That decision would be pretty problematic in an age of multinational collaborative experimentation such as those at CERN.*)
> 
> Wherever one sees person names out of alphabetical order - e.g., many actor listings in motion picture titles and trailers along with "with" and "and" – some readers and those of us behind the scenes should give a thought to why it is so. There's a big difference between no ability to specify well-motivated data orderings (i.e., go easy on designers and programmers) and one that is employed according to rule-specified, i.e., those that are less oriented towards data display.
> 
> Ron Murray
> 
> *Click on the ATLAS collaboration author link at: http://cds.cern.ch/record/1753190
> Note that they are all in alphabetic order, whereas this MEDLINE citation: http://www.ncbi.nlm.nih.gov/pubmed/24808340 hints at a different kind of relationship.
> 
> ---------------------
> 
> 
> From: "[log in to unmask]" <[log in to unmask]>
> Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
> Date: Wednesday, September 3, 2014 11:23 AM
> To: "[log in to unmask]" <[log in to unmask]>
> Subject: Re: [BIBFRAME] Medium of performance (Music) question
> 
> On Sep 3, 2014, at 10:35 AM, Karen Coyle <[log in to unmask]> wrote:
> 
>> 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.
> 
> As someone who writes code to manage RDF, I agree heartily with this. It is true that RDF can represent order. But it is _very_ true that other solutions are preferable. <grin> As Karen Coyle points out, that requires that effort be spent not in encoding, but in modeling itself. I don't pretend to know much about description for music, but in this case, if I do understand the intent properly, it seems that we're reaching for a "medium of performance" class that itself could feature various properties, like "instrument used". That would allow a construction:
> 
> resource bf:musicMedium example:oboe-guitar-duet .
> example:oboe-guitar-duet mybibframe:instrument [
> mybibframe:mediumOfPerformance <http://id.loc.gov/authorities/performanceMediums/mp2013015507> ;
> mybibframe:numberOfInstruments "1"] ;
> mybibframe:instrument [
>                  mybibframe:mediumOfPerformance <http://id.loc.gov/authorities/performanceMediums/mp2013015306>  ;
>                  mybibframe:numberOfInstruments "1" ] .
> 
> or the like. With an actual "medium of performance" class combined with inferencing, some of the properties might be able to be omitted. 
> 
>> 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.
> 
> Yes. One of the "social" issues here is the need to recognize that what a cataloger (or other professional) sees looking at the raw data is not at all what the patron (or other consumer) necessarily will see. We already know that from MARC. We don't put field numbers or subfield codes in the displays of OPACs. {grin} But we still assume a very simple mapping between raw data and displayed data. Processes of indexing and transformation are freeing for the cataloger, allowing a precise description to be manipulated a great deal before display, and in different ways for different displays.
> 
>> On 9/3/14, 7:09 AM, Murray, Ronald wrote:
>>> 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.
> 
> RDF, treated as a graph, is directed. Paths through the graph can be represented and discovered fairly easily using constructions like SPARQL property paths or LDPath programs, although there aren't always obvious encodings in RDF itself for those constructions. Ordering of collections, however, is certainly different. Ordering for display, for example, can be done via linked lists, or indexed items, and probably in other ways. But it's not clear to me that this example is really about ordering at all. It seems to me to be more about aggregation.
> 
> ---
> A. Soroka
> The University of Virginia Library
> 
> 
>> 
>> 
>> On 9/3/14, 7:09 AM, Murray, Ronald wrote:
>>> 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:
>>>> 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
>> 
> 

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager