My dilemma is that I can't understand (as a human, and it may be even
more difficult for a machine) what the admin metadata modifies. So, in
this example:
a bf:Instance ;
bf:title rdfs:label “Medical history” ;
bf:title [a bf:AbbreviatedTitle ;
rdfs:label “Med Hist” ;
bf:adminMetadata [
a bf:AdminMetadata ;
bf:source
<http://id.loc.gov/vocabulary/organizations/dnlm>]] ;...
what is the <http://id.loc.gov/vocabulary/organizations/dnlm> the source
of? I'm guessing it's thesource of the value of rdfs:label. Is that the
case? If that is the case, then a SKOS-like solution (and analogous to
one used frequently in BIBFRAME, e.g. for titles) would be to make the
label into a THING that the adminMetadata can address.
Similarly, in the ISSN example:
bf:identifiedBy
[ a bf:Issn ;
rdf:value “2168-7633” ;
bf:adminMetadata
[ a bf:AdminMetadata ;
bf:assigner "United States" ] ] ;
with the "bf:assigner 'United States'" it is the rdf:value that has an
assigned "United States", not the bf:identifiiedBy. This can be
expressed in RDF.
My question is: is it always clear what in the graph the adminMetadata
refers to? I fear that is not the case, but more use case would be
needed to test that out.
kc
On 1/5/16 12:44 PM, Denenberg, Ray wrote:
>
> Hi Tim –Your point is completely valid. We recognize that the solution
> isn’t perfect but it does serve the desired purpose, to isolate
> administrative and provenance metadata, even though technically the
> admin metadata is still a property of the resource, which in a perfect
> solution, it would not be.
>
> We settled on this approach after examining alternative approaches
> that would have achieved this secondary objective, for example,
> reification, and VOID.
>
> We had been advised by a number of RDF experts to avoid reification
> because it is complex and difficult to implement. We chose not to use
> VoID for a number of reasons; one, because it seems to be overkill for
> our purpose, and second, because as far as we can tell it is not a
> well-accepted nor vetted technology.
>
> We want to move forward with BIBFRAME 2.0 using simple approaches
> where possible, and we chose this simple approach with the idea that
> it is a temporary solution to the problem, pending a stable,
> implementable, and well-adopted solution.
>
> Thanks.
>
> Ray Denenberg
>
> Library of Congress
>
> *From:*Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] *On Behalf Of *Tim Thompson
> *Sent:* Monday, January 04, 2016 8:11 PM
> *To:* [log in to unmask]
> *Subject:* [BIBFRAME] Administrative Metadata proposal
>
> Hello, happy 2016 to all.
>
> I've had a lingering question about the BF 2.0 Admin Metadata
> proposal[1]. It seems to take a step in the right direction, in that
> it makes admin metadata easier to isolate, but in the end I don't see
> how it is conceptually any different from the BF 1.0 approach.
>
> The property bf:adminMetadata is still a property of the description
> of a resource, not of the resource itself, and as a wise man once
> wrote, "The same URI cannot identify both a document that describes
> the resource and the resource itself."
>
> This becomes more apparent when the resource being described is, for
> example, a person, rather than an abstraction like bf:Instance.
>
> <http://id.loc.gov/authorities/names/n94064763#RWO>
>
> a bf:Person ;
>
> rdfs:label "Rineer, A. Hunter (Amos Hunter), -1985" ;
>
> bf:adminMetadata [
>
> a bf:AdminMetadata ;
>
> bf:changeDate "2009-09-28T18:43"
>
> ] .
>
> It's not the RWO that has admin metadata, but
> <http://id.loc.gov/authorities/names/n94064763>, the authority record
> that describes the real person.
>
> Wouldn't it be more coherent to recommend that separate URIs be used
> for RWOs and the documents that describe them, as exemplified by the
> hash URI above?
>
> Best,
> Tim
>
>
> [1] http://www.loc.gov/bibframe/docs/pdf/bf2-draftspecadmin-10-29-2015.pdf
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600
