Dear Rob, Tom:

I wonder if the heart of this problem is a definition issue. Tom asked about definitions yesterday, to which I replied in part but not whole. Rob's email only enforces my suspicion.

The definitions you see in the vocabulary at bibframe.org were established quickly and years ago (at this point). As I said yesterday, and taking the time to look at these select definitions freshly, I think the definition for bf:Person too narrow (if, in fact, it shouldn't be completely revised). I'm not trying to make an excuse so much as say that 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). In this particular case, it is very much about managing the expectations from different communities, all of which have valid and important concerns. So, working on the current definitions, which preference strings, Rob wrote:

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

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. Perhaps by then it's been dropped because the community has decided to generate display labels by another method and the community is happy to rely on other data points to establish identity/uniqueness. I personally see 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?

Also, Rob noted a strong preference for global URIs (sometimes saying "a global URI" and at other times saying "the global URI"). What follows should certainly be treated as a personal opinion, but the notion of one, single global URI bothers me. I agree that there has been a proliferation of URIs and that alone has led to some real problems, but at a big-view, political level I'm not convinced one, global URI, or even a few select global URIs, is the ultimate answer. Who will be the lucky controller of those global URIs? Do we as a community embrace a potentially non-negotiable dependency and, if so, who shall we choose to hold this monopoly? To whom shall we hand off our knowledge and would it be for forever and for good? Is such a thing even feasible at this time?

To conclude that multiple URIs for the same thing has been a major problem in the linked data space and to then swing to the other extreme seems premature. I suspect the solution is somewhere in the middle and as ill-advised Rob believes it may be to proliferate identifiers, it may be equally ill-advised for our community to blindly head off in the opposite direction.

But mostly, I actually think it is too early to tell. For example, we have talked about the idea of "web triggers" (publicly, but also in the Use Case document [1]) but little work has been done with these ideas. I bring this up because a workable solution may be found outside the traditional who-points-to-who discussion.

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

Are there mechanisms we could put in place to hopefully inhibit this? Probably, but crazy data finds its way everywhere and it's probably impossible to stop this from happening. Also, the global community might not care that that person "was there" in 1965 (or that it was "cool"). Being able to augment data was actually seen as a significant need and the bf:Authority construct recognizes this requirement while managing the problem of polluting the global graph.

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? Let me know your thoughts about the first part, but, like I said, don’t over interpret /my/ authoring revised definitions and them being adopted wholesale into the vocabulary. 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?

Warmly,
Kevin

[1] http://bibframe.org/documentation/bibframe-usecases/





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