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