On Sat, December 11, 2010 8:45 am, Karen Coyle wrote:
> Quoting Lee Passey <[email protected]>:
>
>> Let's start with FRBR group 1
>
> As per my previous note, this is Group 2.
Yeah, I knew this. I don't know why I got confused momentarily; perhaps it's
because it makes so much more sense to me to start with the authors before
moving to the work product.
>> -- "responsibleEntities", which I have simply
>> called "Entities" (I'm not very happy with this name--I've seen it variously
>> called "creators", "actors", "authors", etc.--but haven't yet come up with
>> anything more intuitive).
>
> Dublin Core calls these "Agents" -- that is, things that can act.
> Although I think it is broader than FRBR:
>
> A resource that acts or has the power to act. Examples of Agent
> include person, organization, and software agent.
The problem with "agent," like most of the other alternatives, is that it is
semantically overloaded. I think you would find almost every dictionary
definition of the word "agent" implies acting on behalf of someone (or
something) else.
But even if you limit the definition of the word "agent" to be synonymous with
"actor" (e.g. one who acts), it really can't encompass those entities who are
"NotAPerson." The 911 Commission did not write the "911 Commission Report";
one or more individual members of the Commission, or their staff, were the
true creators. The commission as a whole is /responsible/ for the document,
but it did not act to /create/ it. "Poems are made by fools like me..."
When it comes right down to it, I think "Responsible Entity," as cumbersome as
the term is, is the most accurate nominclature with the least semantic
overload.
>> While it is true that there is not anything that
>> comes anywhere close to being a unique, canonical "name" for an
>> entity, from a practical standpoint I needed /something/
>> to uses as a handle; something so
>> I know when I'm talking about /this/ Entity and not /that/ Entity. I think
>> that this is the problem the IFLA was trying to solve when they
>> specified that a "Name" is a required attribute of a Group 1 entity.
>> Well, if an assumed name
>> is as valid as a given name, I guess I could give an Entity a name as well,
>> valid inside my namespace. Thus, I could ensure both uniqueness and
>> immutability (something not supported by OL ids).
> It sounds like you are looking for an identifier.
Precisely. Unique, persistent, immutable and exclusive.
> The FRBR/FRAD "name" is a display form for human use.
I'm not convinced of that. The FRBR Final Report says that the Entity name "is
the word, character, or group of words and/or characters by which the [Entity]
is known.... A[n Entity] may be known by more than one name, or more than one
form of the same name. A bibliographic agency normally selects one of those
names as the uniform heading for purposes of consistency in naming and
referencing the [Entity]." This language leads me to believe that the purpose
of the 'Name' attibute is primarily to identify the Entity canonically or
authoritatively.
In any case, the report goes on to state, "The other names or forms of name
may be treated as variant names for the [Entity]." I have simply chosen to
assign the Entity 'Yet Another Name', unique to my database. Due to the fact
that /I/ am the ultimate bibliographic agency for my database, I have simply
chosen to use /my/ assigned name "as the uniform heading for purposes of
consistency in naming and referencing...." /All/ other names are stored as
variants of /my/ name.
> I'm not sure why you find that OL ids are neither unique nor
> immutable... perhaps you could explain?
Perhaps it would have been more precise to say that OL ids are neither
exclusive nor persistant.
Consider the problem discussed recently in other threads of merging duplicate
Authors/Works/Editions. Let us say we have two edition records, one for "The
Adventures of Huckleberry Finn" by Mark Twain, and one for "Huck Finn" by
Samuel Clemens. "Huck Finn" was assigned OL id OL12345W and "The
Adventures..." was assigned OL id OL54321W. Let's say Samuel Clemens was
assigned an OL id of OL11111A and Mark Twain was assigned an OL id of
OL22222A.
As I understand the merging process, when someone (or some 'bot) recognizes
that two author records represent the same Entity one of the records is
selected as the "master" record (in this case probably OL11111A, as it has the
lower id). The second record is then re-written to redirect queries to the
designated "master" record (presumably other data from the second record is
also merged into the first, but I'm not confident that that is happening).
Work/Edition OL54321W ("The Adventures of...") will continue to refer to
OL22222A (Mark Twain) as its author; it is the responsibility of the software
to follow the chain of redirection to OL11111A (Samuel Clemens). Effectively,
we now have two non-exclusive OL ids which both refer to a single Entity (Mark
Twain/Samuel Clemens).
As I was converting OL data sets into my database, I felt like it might be
useful to record these OL identifiers, but it is obvious I could not use one
of them as the exclusive, unique identifier in /my/ database. So just as I
felt no qualms about substituting my own identifier as the "uniform heading
for purposes of consistency in naming and referencing," likewise I felt no
qualms about storing OL identifiers as alternate names. Thus, in my database
Mark Twain/Samuel Clemens has a single "Entity" record, which might be linked
to at least 4 alternate names: Mark Twain, Samuel Clemens, OL22222A, and
OL11111A.
Now what happens if we merge "Huck Finn" with his "Adventures..."? Again, I
don't know if this is what actually happens, but I would expect that in this
case one of the Work records (probably OL12345W) would be designated the
"master" work record, and the second record (OL54321W) would be re-written to
become a redirection to the "master" Work. (A work record can have but one
title. I don't know how the alternate title issue would be resolved, but this
issue is actually unrelated to the current scenario.) We now have two unique
but non-exclusive identifiers for the Work as well.
Now, if we wanted to know the author of "The Adventures of Huckleberry Finn"
(OL54321W) we would need to follow the redirection to OL12345W and would find
a reference to OL11111A (Samuel Clemens). OL22222A apparently is now an
orphaned record: while it refers to OL11111A as the master, no Work refers to
it. Thus I conclude that it is non-persistent.
Whatever adjectives we choose to use, I think it is apparent that OL
identifiers cannot be used as a unique identifier in the kind of database
schema I have developed.
[snip]
>> In order to well and truly identify our archetypal Entity, we next need to
>> associate Events (and relevant dates) with it. As I see it, every Event has
>> two date/time values associated with it: the beginning, and the end. An
>> event may be virtually instantaneous (receipt of filing of articles of
>> incorporation) or it may go on for some time (the Thirty Years' War).
>
> Do you have a way to encode ongoing events? Library data uses
> open-ended dates (beginning but no end) a lot.
In my database schema both 'begin_date' and 'end_date' are nullable fields,
which means that either may contain either a valid 'date' type or no value at
all. Thus any event can represent a known time-span, an open-ended time span,
or a close-ended time span (we know when an event ended, but do not know when
it began).
> Looking forward to the next chapter!
It might be a few more days until I get to it. It certainly won't be as
complete as this discussion (or the reports I made last March) as I got
distracted by other demands on my time last spring,
Cheers,
Lee
_______________________________________________
Ol-tech mailing list
[email protected]
http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech
To unsubscribe from this mailing list, send email to
[email protected]
