Rob - thanks for your comments, and just a few more of mine. I'll
try to reduce things down a bit.
First, it has occurred to me that, perhaps ironically, the
"Functional Requirements for Authority Data", FRAD, [1] is very
close to OA. Unfortunately, the English version isn't available
online, but if you grab one of the ones whose language you can make
out, all that really matters is Figure 2 (p. 7 in the French
version, for example). It's not exactly the same, but I sense a
similarity in the intent, especially in terms of making clear WHO is
making the statement. FRAD adds one more thing, which is under which
rules the statement is being made. I could imagine, therefore,
BIBFRAME authorities looking much like OA if FRAD is adopted.
On 5/5/13 2:17 AM, Robert Sanderson
wrote:
[log in to unmask]"
type="cite">
Yes, and this is bringing up for me some work I'm doing around the
Dublin Core Application Profiles [2]. I need to catch some other
folks to have a discussion of this, but will get back to you if
anything interesting arises.
[log in to unmask]"
type="cite">
I'm still having a hard time with the dividing line between stuff
and annotations of stuff. A recent article explaining the OA concept
[3] said:
"Annotations describe resources with additional information, which
is valu-
able to other users, who are searching and browsing resource
collections."
If you have "additional information" then there must be
"non-additional information" -- and if you have a third party then
there must be a first party (the second seems to get skipped over in
that analogy). I don't think this is a generalizable question (one
person's "additional"... etc.), but at least for any community like
libraries some definition is going to be needed if annotations will
have some operational meaning. That's what I think is not clear
(yet) in the BIBFRAME document. I suspect that the division in
library data will be based on provenance, but that's not how
BIBFRAME defines annotation.
[log in to unmask]"
type="cite">
Right. But then again, DC types doesn't include "literal" as a type.
The whole typing thing is something I would need to think about
more. If your only interest is literal v. URI, then the BIBFRAME
choice is fine. If you have a video or sound file, that would be a
URI. Something that is interesting in the OA model is that it allows
you to make statements about the thing the URI points to [e.g.
annotating a particular coordinate area on a map]. I hadn't thought
about that, and now will have to go back to the OA document and see
where that fits in. This is one of those areas where the "meta"
aspect of library data has an affect. Must think more.....
[log in to unmask]"
type="cite">
I see this differently, perhaps because of my work on Application
Profiles. I think that many communities will have an internal view
of their data, and another "face" that they present to the open
world. The basic structure of RDF, that is, triples, and the use of
defined ontologies, is a good way to organize data whether it is
open or not. In fact, there are enterprise uses of linked data.
Modeling your enterprise data on RDF makes it much more likely that
you will be able to extract a public view. In the Dublin Core arena
we are looking at Application Profiles as a way to add the
constraints that are needed within a community or enterprise that
has some non-open needs, while easily allowing the derivation of an
open view.
[log in to unmask]"
type="cite">
Rob, what you and I are doing here is the full extent of our ability
to interact in the BIBFRAME process. If you look at the "Contribute"
page [4] of BIBFRAME you will see that the only involvement for the
community in the BIBFRAME development is discussion on this list.
Discussion that, like this thread, takes place generally between
list members with no direct involvement in BIBFRAME development. I
would have simply replied to you individually, but I'm of the mind
that a few readers on the list might find our musings interesting.
In terms of having any influence over the development of BIBFRAME, I
have no such conceit.
kc
[1]
http://www.ifla.org/publications/functional-requirements-for-authority-data
[2] http://dublincore.org/documents/dc-dsp/
[3]
http://www.springer.com/computer/information+systems+and+applications/journal/11042
[4] http://bibframe.org/contribute/
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet