Yes... this version of perfect world is quite within reach. The use of
Authority records will satisfy this requirement.
I am not much in favor of *requiring* perfection of everyone, however...
there will be applications that want to do simple, straighforward things
without the added benefits and associated costs of authority control, and
there should be room in the tent for this style of application as well.
The same architecture will support the spectrum of quick-and-dirty to
rich-and-elegant. Managing the costs and benefits along this spectrum will
give implementors the freedom to populate the niche most appropriate to
their particular service model while staying in the same semantic tent.
stu
-----Original Message-----
From: James Weinheimer [mailto:[log in to unmask]]
Sent: Wednesday, July 21, 1999 9:06 AM
To: [log in to unmask]
Cc: [log in to unmask]; [log in to unmask]
Subject: Re: Agent qualifiers and the 1:1 principle
Peter,
I vote for the perfect world.
Jim Weinheimer
Princeton University
[log in to unmask]
[log in to unmask] wrote:
> This will probably bring some heat, but a guy's got to do what the guy's
> got to do...
>
> I've noticed a lot of qualifier sets incorporating sub elements that
appear
> to be designed to encompass metadata that does not belong to the resource
> in hand. For example, email addresses for agents. In a perfect world we
> would be strongly discouraged from putting email address, which really
> belongs to the agent, in the metadata of the resource. It will create
> havoc when email addresses change. (For example, multiple occurrences of a
> now outdated email address. For you fellow former and/or peripheral
> techies, it's the old data management saw about redundant data.)
>
> In that perfect world (the one in which we don't live), the email address
> would be stored (along with the rest of the metadata that describes the
> agent) in a separate record creating a single central point for reference
> and maintenance.
>
> Just some fodder [sic] for discussion...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|