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.


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=""/>
>     <>
>     <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=""/>
>     <>
>     <!-- 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] <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Date: Tuesday, September 2, 2014 6:07 PM
> To: "[log in to unmask] <mailto:[log in to unmask]>" 
> <[log in to unmask] <mailto:[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
> <> .
>                mybibframe:numberOfInstruments "3" ) ;
>              mybibframe:instrument (
>                  mybibframe:mediumOfPerformance
> <> .
>                  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. 
> [2]
> 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

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