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