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] >
>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] 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)
>*************************************************************
--
Владимир Скворцов
