 |
 |
Thanks, Ray. I have to say that to me this makes more sense if I think of the adminMD as something like the W3C annotation, that explicitly connects info about something. So my "picture" is something like: adminMDx -> title1 adminMDx -> [source,etc.] which also looks like title1 <- adminMDx -> [source, etc.] which makes adminMDx a central node. Rather than title "having" adminMD, adminMD has a target title. But perhaps our models do the same thing? The definition of source needs to make clear that it's the source of the "thing" the adminMD links to, not the source of the adminMD (this is getting too meta!). kc On 1/6/16 2:58 PM, Denenberg, Ray wrote: > > Hi Karen – > > You ask: in the statement > > bf:source <http://id.loc.gov/vocabulary/organizations/dnlm> > <http://id.loc.gov/vocabulary/organizations/dnlm>] > > what is <http://id.loc.gov/vocabulary/organizations/dnlm> > <http://id.loc.gov/vocabulary/organizations/dnlm> the source of? > > It’s a good question. > > First, the example is wrong, which may be the cause of some of the > confusion. > > Instead of > > bf:adminMetadata [ > a bf:AdminMetadata ; > bf:source > <http://id.loc.gov/vocabulary/organizations/dnlm><http://id.loc.gov/vocabulary/organizations/dnlm>] > ] ;... > > It should be something like this: > > bf:adminMetadata [ > a bf:AdminMetadata ; > bf:source > > a bf:Source ; > > rdfs:label “dnlm” ] ;... > > And the reason for this is that > <http://id.loc.gov/vocabulary/organizations/dnlm> > <http://id.loc.gov/vocabulary/organizations/dnlm> identifies an > organization, but the “source” is supposed to be a list, not an > organization. So what we intend to indicate as the source is the list > of variant titles at NLM. But there isn’t any URI for that list so > the best we can do is provide a label that hopefully will be > recognized to indicate the NLM list. “dnlm” is taken from the list at > https://www.loc.gov/standards/sourcelist/abbreviated-title.html > > So let’s say hypothetically some day this list will be available in > RDF; we could then say something like > > bf:source > /<//<%20https:/www.loc.gov/standards/sourcelist/abbreviated-title/dnlm>https://www.loc.gov/standards/sourcelist/abbreviated-title/dnlm/> > . > > But as to the question “what is it the source of”. I don’t think I > would characterize it as the source of the label. It’s the source of > the title, which is a resource. > > What we envision ( this is not reality yet) is that someday there > actually would be some list and the (hypothetical) > <%20https:/www.loc.gov/standards/sourcelist/abbreviated-title/dnlm>https://www.loc.gov/standards/sourcelist/abbreviated-title/dnlm > would point you to it, and at that list you could look up “Medical > history” and you would get pointed to > <http://www.ncbi.nlm.nih.gov/nlmcatalog/401052>http://www.ncbi.nlm.nih.gov/nlmcatalog/401052 > which would give you a wealth of information about that title. > > So you might argue that for this example, it is actually the source of > the label, but that’s only because only the label is supplied. The > title resource could however be structured, for example : > > bf:title [ > > a bf: VariantTitle ; > > rdfs:label “--Ahead of their time : history > of the WLSC” ; > > bf:mainTitle “--Ahead of their time :” ; > > bf:subtitle “history of the WLSC” ; > > bf:variantType “spine “ ] . > > And it this case, the source (if supplied, and I don’t have a source > for this one, examples are hard to find) would be the source of all of > the information in this resource. > > The identifier example is simpler and more straightforward. Again the > example is a bit off, instead of > > > bf:assigner "United States" ; > > it should be … > > [ bf:assigner a bf:Assigner ; > > rdfs:label "United States" ] ] ; > > …. for reasons similar to above: the assigner should be a resource so > that a URI may be provided instead of or in addition to the label. > > Anyway, in this case, the assigner is an ISSN member country, from the > list at > > <http://www.issn.org/wp-content/uploads/2014/06/LISTE-DES-PAYS-MEMBRES-2016.pdf>http://www.issn.org/wp-content/uploads/2014/06/LISTE-DES-PAYS-MEMBRES-2016.pdf > > and somewhat similar to the above example this list might someday be > available as linked data, providing the means to get more information > about the identifier. > > Hope this helps some. > > Ray > > *From:*Bibliographic Framework Transition Initiative Forum > [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle > *Sent:* Tuesday, January 05, 2016 9:32 PM > *To:* [log in to unmask] > *Subject:* Re: [BIBFRAME] Administrative Metadata proposal > > 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> > <http://id.loc.gov/vocabulary/organizations/dnlm>] ] ;... > > what is the <http://id.loc.gov/vocabulary/organizations/dnlm> > <http://id.loc.gov/vocabulary/organizations/dnlm> the source of? I'm > guessing it's the source 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] <mailto:[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] <mailto:[log in to unmask]> http://kcoyle.net > m: +1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 -- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600