this entire discussion has provided a good opportunity to revisit - and hopefully refine - work that was quickly executed years ago to get us up and running.

The very top-level classes (Work, Instance, Authority, etc) are intentionally broad and designed as abstractions.  This includes an equally broad definition, which, in the case of Authority, borders on unintelligible.  So, if I may proffer a revised definition of bf:Authority:
----
An Authority represents a key Concept or Thing.  Works and Instances, for example, have defined relationships /to/ these important Concepts and Things.
----
I'm not saying that that is perfect, but does it get closer?

I think that a revised definition for Authority would free us up to modify the definition of Person to something like:
----
A person, whether real, fictional, etc.
----

Monster caveat needed: This entire thread/email could be simply us three having a wonderfully public conversation about bibframe class definitions.  I - we - can come up with more workable definitions, but I don't want any of the above to imply that any positive outcomes of this conversation will be reflected in a future update to the vocabulary/model.  I do, however, think this conversation is valuable and needed because, without it, I am reasonably confident non-discussion will, predictably, have zero impact.

If the above, revised definitions are more acceptable, then I think we are a lot closer in opinion than it might seem.

 Despite the currently-established definition for bf:Person, I've not seen it as merely a housing for a string.  That said - and here is the concession, I think, everyone has to agree to live with until the transition period is safely behind us - those strings need to be carried along and things like bf:authorizedAccessPoint accommodated (until such time that people recognize that the URI is the access point, not the string).

Again, with the revised definitions, I actually think we're pretty close to this.  I can assuredly say that this is more or less how I have viewed bf:Person personally.  I would revise Rob's example ever so slightly (and make it even simpler):

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

 _:Tolkien a bf:Person;
     foaf:name "J.R.R. Tolkien" ;
     bf:hasAuthority _:lcnaf ;
     bf:authorizedAccessPoint "Tolkien, J.R.R" .

 _:lcnaf a madsrdf:PersonalName .

     madsrdf:authoritativeLabel "Tolkien, J.R.R" .

A little redundant?  Yes.  Have a string you'd not expect of a Person?  Yes.  In 10 years might there be any need for or desire to have bf:authorizedAccessPoint as a property of a bf:Person?  Perhaps not.

 a continuum of change, which is why I think some transitional concessions need to be accepted, but I most certainly agree we need to get the framework right so we do not find ourselves at a semantic dead end in 10 years.

Changing topics ever so slightly, Rob noted a few times a distinction between "a locally defined and maintained URI" versus a "global URI," preferring the latter.  For starters, I do not think a "locally defined and maintained URI" is a mutually exclusive concept with a "global URI."

 If the University of Minnesota were to publish resources for its researchers (who were not established in LC/NAF, VIAF, ORCID, VIVO, and so on) could that not become /the/ global URI for that individual?

But mostly, I actually think it is too early to tell.  

Editorializing aside, but on the topic of a global URI, one of the ideas behind a bf:Authority as a type of lightweight abstraction layer was actually to establish a mechanism that would permit organizations to make additional statements about a Concept or Thing /without/ risk of polluting a global graph.   For example, with a bf:Authority approach, one could do this:

ex:1234   bf:creator  ex:abcd

ex:abcd   rdf:type bf:Person
ex:abcd   bf:note  "This person came here once in 1965.  It was cool."
ex:abcd   bf:hasAuthority viaf:abcd

If a VIAF URI were used, this might happen:

ex:1234   bf:creator  viaf:abcd
viaf:abcd  bf:note  "This person came here once in 1965.  It was cool."

Also, being able to assign a bf:Authority a "local" URI (and let's say it is an HTTP URI) enables an implementing library to literally make it resolvable.  If, for example, we all used VIAF URIs, then that's where those URIs lead, of course, and the implementing library has missed an opportunity to literally make that resource a reference-able, local, authorized access point.

Golly, does all of that hold together?

As for the second part, we might have to agree to disagree but here’s the important thing:  I think if we can get agreement on the first part, then we've established a framework the does not preclude anything discussed in the second part.

 Perhaps the community, over time, wants to move in the direction of using global URIs as you've described them.  In that case, the model/vocabulary is positioned to make such a thing a relatively easy transition, correct?

> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum

> [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
> Sent: Wednesday, July 09, 2014 12:46 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Bibframe and Linked Data (Authorities)
>
>

> 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