ask: in the statement
the source of?
a good question.
the example is wrong, which may be the cause of some of the
should be something like this:
a bf:AdminMetadata ;
rdfs:label “dnlm” ] ;...
the reason for this is that <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
let’s say hypothetically some day this list will be
available in RDF; we could then say something like
bf:source < https://www.loc.gov/standards/sourcelist/abbreviated-title/dnlm>
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.
we envision ( this is not reality yet) is that someday there
actually would be some list and the (hypothetical) 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
which would give you a wealth of information about that title.
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: VariantTitle ;
rdfs:label “--Ahead of
their time : history of the WLSC” ;
bf:mainTitle “--Ahead of their
time :” ;
bf:subtitle “history of the
“spine “ ] .
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.
identifier example is simpler and more straightforward.
Again the example is a bit off, instead of
bf:assigner "United States" ;
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.
in this case, the assigner is an ISSN member country, from
the list at
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.
this helps some.
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
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” ;
a bf:AdminMetadata ;
what is the <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:
[ 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
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.
settled on this approach after examining alternative
approaches that would have achieved this secondary
objective, for example, reification, and VOID.
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.
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
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
happy 2016 to all.
had a lingering question about the BF 2.0 Admin
Metadata proposal. 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
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."
becomes more apparent when the resource being
described is, for example, a person, rather than
an abstraction like bf:Instance.
rdfs:label "Rineer, A. Hunter (Amos Hunter),
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?
[log in to unmask] http://kcoyle.net