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.Tim
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 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 SandersonTechnology Collaboration FacilitatorDigital Library Systems and ServicesStanford, CA 94305