Quoting "Myers, John F." <[email protected]>:
If I understand things correctly, Dan's example is actually an RDF
triple serving the Work 'Moby Dick'. To address the Manifestation
issues raised by Mac, one might have:
URI(Particular Manifestation of Moby Dick) -- URI(has Statement of
Responsibility/is the Statement of Responsibility for) -- URI(Herman
Melville ; illustrated by Tony Millionaire ; foreword by Nathaniel
Philbrick.)
This is definitely the right idea, and I'm amazed at how far these
concepts have spread compared to just a year ago.
We may be at a point where we can make them our own... in the sense
that we have a lot to contribute to the development of this
interlinked metadata standard (which isn't quite standard yet, IMO).
The linked data movement, which is the most active implementation of
semantic web concepts, is active primarily among communities whose
data is very "data-based." Facts and figures are much easier to model
than the true complexity of bibliographic data. The pure "triple" is
both artificial and awkward, just as the pure MARC record is. It's
something for machines, not people. We need a way to represent the
next level up, the logical view that makes more sense to humans,
rather than the atomized triple. So something like (and I'm doing this
very schematically):
author123 -- has preferred name -- H Melville
-- and is author of -- book456 -- which is called "Moby Dick"
-- and was manifested as....
The triples string together to make more human-understandable
statements. This works well with pictures, but is very hard to do in
writing. I am however convinced that all of this can be hidden by an
easy to understand user interface so that the cataloger doesn't even
have to think "triple." We do need a way that at the time of
cataloging it is relatively easy to see and complete the the
connections -- connections like we make today between bib and
authority data. But there will be many more, so that part needs to be
very efficient.
Not everything can be represented with a URI. In particular, the
transcribed parts of the bibliographic record are necessarily text,
since they must transcribe the text from the piece. You can have free
text in your data, and it's not much different to how we do things
today:
book456 -- has statement of responsibility -- "by Herman Melville."
Which is not much different from putting "by Herman Melville" in the
260 $c in a MARC record for a particular manifestation.
Conceptually, you want to represent as data ("1999") anything that can
be data, you want to identify anything that you can reasonably give an
identifier to (and usually this something that will be re-used in
different records and possibly in different contexts, like identifying
a person who can be an author or a subject heading), and you should
use controlled vocabularies where you can.
None of this is new to us because library data *already* does this --
we identify, although using text strings rather than URIs; we have
some data that is naturally and necessarily free text; and we have
many controlled vocabularies. Transforming this to semantic web or
linked data ways of encoding data isn't a huge leap for us. There are
some differences: we need to use formal identifiers rather than texts
(an identifier for a subject heading rather than the display form),
and there are data elements that we treat as text (pagination, extent,
volume numbers, ISBNs, etc.) that we could get more mileage out of if
we gave them a more formal treatment that would make them directly
usable in computer programs.
I am struggling to try to create something visible that we can work
with, because none of this really makes sense in the abstract. I guess
I'm working from two directions at once: defining elements for RDA and
identifying the data elements in MARC. This latter is harder than it
sounds:
http://kcoyle.blogspot.com/2010/03/marc-from-mark-up-to-data.html. The
reason I'm looking at both is that we have been creating elements in
MARC that aren't directly covered by the cataloging rules, so having a
full list of the MARC elements should help us understand what elements
we really need (which I think are sometimes hidden in the MARC
complexity). Some people have created triple-type records out of MARC,
and I want to learn more about that.
Whew! There's a lot to be done.
kc
[email protected]
-----Original Message-----
From: J. McRee Elrod
Dan Matei said:
I would prefer something like:
(URI(Moby Dick) -- URI(hasAuthor/isAuthorOf) -- URI(Melville)) -- (who
sa=
id so) -- (when) -- (based on what)
Mac responded:
So based on this we would know we have listed "a" manifestation of
Moby Dick. But without an actual transcription of what is *on* the
item, how can we match that description with a particular item in
hand?
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
