Quoting Lee Passey <[email protected]>:
> Let's start with FRBR group 1
As per my previous note, this is Group 2. (And note that the FRBR
Review Group has actually refused to give the groups names, so they
are only officially referred to by their numbers -- which I think
makes it harder to understand, since 1 and 2 aren't meaningful as
bibliographic entities.)
> -- "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.
> 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 I 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. The FRBR/FRAD "name"
is a display form for human use.
I'm not sure why you find that OL ids are neither unique nor
immutable... perhaps you could explain?
> An entity may be labeled by any number of names, so next we need an
> open-ended
> list of names; each entry should be unique. As a name may be used by any
> number of entities, the list must be non-volatile; a unique name may
> be added,
> but no name may be removed.
This is very similar to what OL does when named entities are combined.
All new 'variants' are added to the 'master'. I think that some names
can be removed, but removal means that the name form no longer
displays, while the identifier for that name form still exists as a
link to the 'master.'
>
> 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.
Looking forward to the next chapter! BTW, I think it's time to gather
a bunch of different FRBR-izations and analyze them. I have never seen
any two that are alike, but we probably have enough of them now to
begin to see some patterns. It'll be a hard analysis to do, though.
kc
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
_______________________________________________
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]
