Print

Print


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

Absolutely!


> 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
http://bibframe.org/resources/sample-pu/1133749topic22 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.
>

+1.


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

Absolutely!

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

Rob




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