Print

Print


Hello, Karen,
Thank you for reading my composition on BIBFRAME Model.
You wrote: "So it seems to me that
linking a bf:Instance to a bf:Work ("isInstanceOf") fits the workflow best".
That is absolutely what I meant in cited area. Your example, as it seems, is a lepton to the same money-box.

As to bi-directional links, I doubt they coresspond to  RDF, and, hense, may cause problems when search engines are oriented on RDF.

I look forward to hear from you on the rest of my composition.
Vladimir.

Четверг, 8 августа 2013, 0:00 -04:00 от BIBFRAME automatic digest system <[log in to unmask]>:
There is 1 mess age totalling 65 lines in this issue.

Topics of the day:

  1. Modeling

----------------------------------------------------------------------

Date: Wed, 7 Aug 2013 07:23:16 -0700
From: Karen Coyle <[log in to unmask]">[log in to unmask]>
Subject: Re: Modeling

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.

kc


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,
> Russia

--
Karen Coyle
[log in to unmask]">[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

------------------------------

End of BIBFRAME Digest - 6 Aug 2013 to 7 Aug 2013 (#2013-138)
*************************************************************


--
Владимир Скворцов