Vladimir, there is much in here so it will take many readings to fully
comprehend. I did want to make a comment on one area, however. You say:
"For instance predicate hasInstanse gives downward link, while upward
links are more preferable. Having downward links only, to create record
at Instance level one should change record at Work level, meanwhile
these operations may request employees of different qualification."
I think that you are right in that the linking must be related to the
workflow. To my mind, the key aspect of the workflow is that the
cataloger works with the bf:Instance in hand, and logically from that
seeks out the appropriate bf:Work to link to. If there is no appropriate
bf:Work, then one must be created. But one would never create a bf:Work
if there were no bf:Instance being cataloged. So it seems to me that
linking a bf:Instance to a bf:Work ("isInstanceOf") fits the workflow best.
Note, however, that bf:Instance includes a property "instanceOf" which
doesn't appear on the diagram, so the arrow on the diagram could be
bi-directional. However, there is another aspect to this. It is probably
best to have a single property, not two properties that could be used in
conflict with each other, e.g.
AWork > hasInstance > BInstance
BInstance > isInstanceOf > FWork
This violates the statement in the Primer "Each BIBFRAME Instance is an
instance of one and only one BIBFRAME Work."
The two properties could be defined as the inverse of each other, but
all that does is to make clear that the above two triples cannot both be
true. Inverse-ness allows you to use one and infer the other, but it
doesn't keep you from making that kind of mistake.
On 8/6/13 8:09 AM, Vladimir Skvortsov wrote:
> Dear collegues,
> Please find athttp://www.rusmarc.ru/soft/bibframe_model.pdf
> my 'Some general ideas on BIBFRAME Model'. I will be happy if it seems
> interesting to you.
> Vladimir Skvortsov
> Head of department,
> National Library of Russia,
> Saint Petersburg,
[log in to unmask] http://kcoyle.net