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,