Thanks for this, Kevin!
In summary: Yes! Hooray! :) 

On Thu, Jul 10, 2014 at 9:25 AM, Ford, Kevin <[log in to unmask]> wrote:
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's a great change and really does address the issue at hand -- that currently Authority seems to be a class that represents the name, whereas this is much clearer that it represents the actual /thing/ (be that a Person, as our examples, or anything else)
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.

Yes! A *person*, rather than the name of a person.  This would mean that bf:Person and foaf:Person are equivalent classes, and as per your example below, would simplify the model at the same time as making it much cleaner in the future.

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.

Understood! If there's anything that can be done to help move things along, rather than just being a nice discussion, let us know.  For example, if a separate MARC to revised-definition-bibframe conversion script (or current-bibframe to revised-bibframe) would help demonstrate the differences and benefits, I think that could be taken on.

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).

That's fine by me.  The strings are descriptive of the person, and hence there's no problem associating them with the person resource.  It's the current at least perceived primacy of the string over the actual person that's the concern, and this addresses it cleanly.
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" .

That looks great to me!  There are three clear resources:  A Work, a Person and a Name. If they had URIs, then there wouldn't be any confusion or ambiguity.

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.

Yeah, none of these are significant in my opinion. One of the strengths of RDF and Linked Data is that anyone can assert anything about resources. So having a few redundant fields is something that we have to deal with anyway.

 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.

This is perfectly said!  There will be some concessions to enable transition rather than starting from scratch, but the framework needs to not take those concessions as the foundation, but instead look to what the ideal situation is in the hypothetical perfect world, and then add in the concessions to allow moving in that direction.

Literally drawing a line between the topics as above we're in 100% agreement :)

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."

Sorry for not being clear!  I'm not at all against locally defined and maintained URIs, if they're globally useful.  I think when I said that, I meant the seemingly temporary URIs that we find in the example set associated with resources that in the documentation are all blank nodes.

 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?

I think that they would be great URIs for those researchers. So long as they're maintained, compared to, for example,
the automatically generated ones like which seem unlikely to be persistent :) 

Really my concern is the over abundance of blank nodes or the skolemized blank nodes in the samples, as per the Identifiers thread, so please don't read too much into my use of global URI.

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

I agree.  There are big challenges in this space, but let's get the model ready to accept whatever the result is, rather than baking in the reliance on blank nodes everywhere that we see currently.


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."

I see the general class of concern, but the only fix to the above to make it actually useful would be to change "here" to the name of the institution.  Then it could provide value to future researchers tracking ex:abcd's travels :)

On the other hand, there are definitely cases when you want to talk about an entity in a particular context.  ORE introduced Proxy nodes, for example, to refer to the aggregated resource in the context of the aggregation.  Open Annotation has SpecificResources which are a little broader, but could fill the same notion of resource in the context of this annotation.

I'm not going to argue against the utility, but having a stronger notion of when this localization of the entity is in effect, and why you might want to do that, would be very valuable.

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?

I think it does, and that we're if not completely in agreement, then I can't see where we're not! :)
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.

Yes. I actually don't think we have to agree to disagree even! It's mostly my unclear wording giving a poor impression, apologies for that.

 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?


Thanks so much for engaging with this, Kevin. And again, if there's anything that we can do to actively move things forwards, just say :)


> -----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

Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305