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:numberOfInstruments
"1"] ;
mybibframe:instrument
[
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:
[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.
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:
[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
