Print

Print


Dear Ray, Kevin and all,

Thank you very much for the response to the document! I didn't expect
anywhere near as much reaction as it received, particularly for something
in such a draft state of completion.  My intention was to get a few extra
eyes on it, before bringing a more complete document to the list for
discussion. Impossible to close that particular barn door now, of course,
but I'm glad that it has moved the conversation forwards.

I'll respond to the points in individual threads to avoid having epic
emails.

I'm glad that the authorities point has been taken up, as I strongly
believe it's at the heart of the matter.  Clarity here will make it much
easier to discuss other issues.

On Wed, Jul 9, 2014 at 5:12 AM, Ford, Kevin <[log in to unmask]> wrote:

> > However the definition of a Bibframe Person as it stands is a
> > “Controlled personal name”, not a person as such; foaf:Person is defined
> as
> > “A person” which does implicitly suggest that "bf:Person != foaf:Person".
> -- Agreed.  Two things here.  One, I can envision the definition of
> bf:Person changing (to what, I could not tell you, but the current
> definition seems narrow to how I think of bf:Person).  Two: while the
> second point is an intentionally technical point, we want it clear that
> we've made no such assertion explicit and that to suggest otherwise is to
> interpret beyond what has been stated at the vocabulary level.  I'm not
> saying that your assessment of the definitions is unreasonable, but that
> there is a way to assert (or not) this type of statement at the vocabulary
> level and we've not done that.



I don't think that I equate bf: and madsrdf: Authority classes, but I'm
pretty confident that bf:Person is (or should be) disjoint with
foaf:Person.  Instances of foaf:Person /are/ the person, not a document or
an authorized form of the person's name.  If there is any additional
explanation about what a bf:Authority is, as distinct (or not) from other
authority classes, person classes, or if it's just a string, that would be
extremely helpful.

While not explicit in Simon Spero's email, his example provides some great
examples of when the conflation of person and name-of-person result in
confusion, or worse inaccuracy: the person Mark Twain is clearly never
shorter than the person Samuel L. Clemens!


Rather, bf:Authority is an abstraction allowing the implementer to
> reference a traditional authority. It is these traditional authorities that
> include the strings in question.


Right, via the bf:hasAuthority relationship. My concern is whether this
intermediary node is actually necessary, or needlessly adds complications?
 Instead, a Work or Instance could have some relationship directly with the
authority, or (better) with the Person instead of the Authority for the
Person.

Please see below for an example of how this could be accomplished,
including all of the information currently in the model, but also providing
some assistance for the future state when people do have identifiers.

The explicit inclusion of the string within a bf:Authority (via property
> bf:label or bf:authorizedAccessPoint) is not mandated; it may be optionally
> included when a link to a traditional authority cannot be found, or for the
> benefit of a recipient who may be unable to follow the link.

I think between calling it an Authority and the other language surrounding
it, the distinction between name and authority is blurred in the current
model.  My understanding, based on what you say here, and please correct me
if I'm misinterpreting, is that bf:Authority __isn't__ an authority at all,
it's just the data that is in the source MARC record, for better or worse.
 If that's the case, then what we have is really:

_:LotR rel:cre [ a bf:CatalogResourceString;
       bf:value "Tolkien, J. R. R.";
       bf:hasAuthority <lcnaf:TolkienJRR>;
       xx:isLabelFor <person:TolkienJRR> ] .

Where <lcnaf:TolkienJRR> is a URI that identifies a particular
madsrdf:PersonalName, viaf:Person or similar authority record, and
<person:TolkienJRR> identifies the actual human being who wrote The Lord of
the Rings.


These carefully constructed strings allow us to create matches to strings
> in existing MARC records (if we broke them up, we'd have a problem
> re-creating them should we need to), they represent current cataloging
> practice (for better or worse), and they provide us with ready-made labels
> (and ones that the community expects to see in bibliographic data).
> Reliance on fabricated strings will diminish in time, some day they may go
> away and become a relic of 20th century cataloging but it is simply too
> early for that; for now they are imperative.  It will not happen until our
> reliance on identifiers outweighs our need for - and stakeholders'
> expectations of - those strings.


Completely agreed. I think this is the heart of the matter -- coming from a
perspective of having to provide a full and complete migration of all data
in MARC records into an equivalent structure does result in relying almost
exclusively on string authorities, as MARC does, rather than on identifiers.

However, if the intent is to transition (slowly and appropriately) away
from strings and towards identifiers and linked data, then it would seem
logical to me to build that transition into model early.  For example,
ensuring that all of the relationships still work when the object has a
global, unique URI and that doesn't result in unintended collisions or
semantic inconsistency (as I try to get at in the Identifiers discussion).

Currently, Bibframe has, as far as I can tell:

-----
  _:LotR a bf:Work ;
      rel:cre _:bfauth .

  _:bfauth a bf:Person ;
      bf:hasAuthority _:lcnaf .

  _:lcnaf a madsrdf:PersonalName ;
      madsrdf:identifiesRWO _:Tolkien .

  _:Tolkien a foaf:Person ;
      foaf:lastName "Tolkien" .
-----

To get from a Work to the actual Person.

One could imagine instead changing the structure around a bit, while still
maintaining all of the information:

-----
  _:LotR a bf:Work ;
      rel:cre _:Tolkien .

  _:Tolkien a foaf:Person ;
      foaf:lastName "Tolkien" ;
      bf:hasNameAuthority _:lcnaf ;
      bf:hasReference _:marc .

  _:lcnaf a madsrdf:PersonalName .

  _:marc a bf:CatalogResourceInfo ;
      bf:value "Tolkien, J.R.R" .
-----


Today, the _:Tolkien node would be a blank node or perhaps a locally
defined and maintained URI. In the future, when there are well known
identifiers for people, the additional references could be dropped or
maintained as desired:

-----
  _:LotR a bf:Work ;
      rel:cre <person:TolkienJRR> .

  <person:TolkienJRR> a foaf:Person ;
      foaf:lastName "Tolkien" ;
      (and as above plus additional as desired) .
-----

This allows other institutions to also contribute their information about
the agent (or other entity with an authority record) to the pool of human
knowledge, by using the global URI for the entity and making assertions
about it.  In the current structure, that information gets lost, and I
consider that a shame as the library world has a long and rich tradition of
knowledge management that I hope will help shape the way Linked Data moves
forwards, rather than trying to compete with it and inevitably being
drowned out.

I hope that helps, and look forwards to further constructive discussion :)

Kind regards,

Rob