Print

Print


I agree.

My preference would be to base the authority approach on the current practices for linked library data, which commonly use existing vocabularies (FOAF, SKOS). The basic pattern is to use skos:Concept for the authority entity, with a foaf:focus on the foaf:Person (the ”real” thing, culturally speaking, including personas and fictional characters). The latter is ideally owl:sameAs more well-known URI:s, e.g. defined by DBPedia, for which there are richer descriptions than we could possibly maintain ourselves).

At KB, we have published RDF like this for many years, as has e.g. VIAF. This approach is also continued in our new cataloging system at KB. We map our data to multiple vocabularies [1], including BibFrame, but these kinds of model divergences (or in this case, conflations) make it quite difficult at times. It seems that BibFrame stays very close to MARC, and in so doing it becomes hard to align with the above approach.

For reference, Getty has published a very interesting and thorough document describing (among other things) this approach: http://vocab.getty.edu/doc/#Concept_vs_Place_Duality

Cheers,
Niklas

--
Niklas Lindström
Systems Developer
National Library of Sweden (KB)


27 okt 2014 kl. 18:59 skrev Tim Thompson <[log in to unmask]>:

To echo Thomas, the term "Authority" can't escape the baggage of its string-based history. Doing authority control means establishing the "authorized" form of a name string. As long as we continue using this terminology in a linked data context, won't there will always be ambiguity? By definition, an "Authority" is a "representation," not the thing itself. I don't see how we can have our cake and eat it too.

Wouldn't it be more coherent to just remove bf:Agent and its subclasses from bf:Authority? A simple property like bf:hasAuthority could point us to the "authorized" form of a name or label for the real-world entity.

Tim

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
[log in to unmask]


On Mon, Oct 27, 2014 at 11:29 AM, Robert Sanderson <[log in to unmask]> wrote:

To try and bring the thread back to the subject ...

On Fri, Oct 24, 2014 at 5:54 AM, Meehan, Thomas <[log in to unmask]> wrote:

I like the increased clarity that Person etc represents the person rather than the authority concept but wonder now whether the class Authority has some ambiguity:

 

-          the name/label Authority still suggests something like an authority record for an entity rather than an entity as such.

-          the definition of an Authority says “Representation of a key concept or thing”, which to me doesn’t suggest the concept or thing itself. Shouldn’t it be just “A key concept or thing”. Or perhaps just “A concept or thing”.

Agreed.  If bf:Person is a real world person, then Authority should be "A concept of thing".  It must certainly not be a "Representation" of that, especially given the web semantics for "representation" (being the bytes received when dereferencing a resource via its URL).

Thanks for bringing this up, Thomas, and look forwards to any responses.

Rob
 

 

Thanks,

 

Tom

 

---

 

Thomas Meehan

Head of Current Cataloguing

Library Services

University College London

Gower Street

London WC1E 6BT

 

[log in to unmask]

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
Sent: 24 October 2014 13:06
To: [log in to unmask]
Subject: [BIBFRAME] [Topic] Authority Subclasses

 

 

Hi Ray, Kevin,

 

The revised description is better, but still ambiguous as to whether the bf:Person *is* the person or is a record that *describes* the person.

 

The definition implies that it is the person, the text below implies that it's the record about the person.  It would be great to be explicit about this.

 

Thanks!

 

Rob

 

--

Rob Sanderson

Technology Collaboration Facilitator

Digital Library Systems and Services

Stanford, CA 94305




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