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 ;
<>]] ;...

what is the <> 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:

     [ a bf:Issn ;
      rdf:value “2168-7633” ;
         [ 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.


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.
> <>
> 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 
> <>, 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]
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600