Print

Print


Hi, i wanna leave the group.
Thanks

19 Haziran 2015 Cuma tarihinde, Tim Thompson <[log in to unmask]> yazdı:

> Sorry, I got the first part wrong. I was actually thinking of holdings for
> a serial comprising 60 issues (as you can see from the first
> bf:ennumerationAndChronology) chunked into bound volumes of 10 issues each.
> The component items would be the 10-issue chunks and the top-level compound
> item would be the whole run of 60 issues. Hope the rest makes sense.
>
> Tim
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Fri, Jun 19, 2015 at 2:39 PM, Tim Thompson <[log in to unmask]
> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> wrote:
>
>> Ray,
>>
>> This modeling of items seems much more coherent. I would have liked to
>> have seen additional examples, however, particularly for serials/continuing
>> resources.
>>
>> In a MARC environment, "item" records do not necessarily correspond to
>> individual issues in a run of serials. So, if you have a bound volume
>> containing numbers 1-10 of a serial, the bound volume would be a compound
>> item comprising 10 component items, like the following, right?
>>
>> # Summary holdings for the serial (compound item)
>> <http://bibframe.example.org/item/item1>
>>     a bf:Item ;
>>     bf:hasComponent <http://bibframe.example.org/item/item2> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item3> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item4> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item5> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item6> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item7> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item8> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item9> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item10> ;
>>     bf:hasComponent <http://bibframe.example.org/item/item11> ;
>>
>>     bf:heldBy [
>>         a bf:Organization ;
>>         rdfs:label "NjP" ;
>>         bf:holdingOrganization <
>> http://id.loc.gov/vocabulary/organizations/njp> . ] ;
>>
>>     bf:subLocation "rcppa" ; # Offsite storage location
>>     bf:enumerationAndChronology "Ano I, no. 1 (julho 1987)-Ano XI, no.
>> 60" ;
>>
>>     bf:hasNote [
>>         a bf:Note ;
>>         rdf:value "DESIGNATOR: no." . ] .
>>
>> # First component item (issues 1-10 of the serial)
>> <http://bibframe.example.org/item/item2>
>>     a bf:Item ;
>>     bf:componentOf <http://bibframe.example.org/item/item1> ;
>>     bf:itemOf <http://bibframe.example.org/item/instance1> ;
>>
>>     bf:identifiedBy [
>>         a bf:Barcode ;
>>         rdf:value "32101089182479" .
>>     ] ;
>>
>>     bf:enumerationAndChronology "no. 1-10" ;
>>     bf:enumerationAndChronology "julho 1987-abril 1988" .
>>
>> That would seem to accommodate existing holdings information for serials.
>> But I'm still struggling with the level of granularity for items.
>>
>> Technically, each component item here would actually be a compound item
>> in itself, but our existing data (for serials at least) does not reflect
>> that level of detail. Getting there would seem to entail a lot of messy
>> string parsing. So, with legacy data, we probably won't be able to get to
>> the simple-item level.
>>
>> Which raises the question of how you count your holdings. BF does not
>> currently have a mechanism for recording piece counts. If you had a run of
>> simple items, you could tally them up, but we don't (currently) have that.
>> I'd like to see a subtype of bf:Note for recording piece counts on compound
>> items, and additional subtypes for serial designators and "lacks"
>> statements (e.g., "LACKS: no. 7-10, 12-14").
>>
>> I'd also like to see bf:enumerationAndChronology split into two separate
>> properties (which is how we record them on existing item records, and which
>> is needed for printing spine labels).
>>
>> As a general question, though, what should be our practice be, moving
>> forward? To create a simple item for each issue of a serial, or to continue
>> our current practice of representing holdings with summary strings and
>> piece counts? The former seems preferable but would entail a lot more work
>> on the data entry end.
>>
>> Thanks!
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> On Fri, Jun 19, 2015 at 11:41 AM, Denenberg, Ray <[log in to unmask]
>> <javascript:_e(%7B%7D,'cvml',[log in to unmask]);>> wrote:
>>
>>>
>>>
>>> Attached, the second of several proposals:  BIBFRAME Item Proposal.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Ray Denenberg
>>>
>>> Library of Congress
>>>
>>> 202-707-5795
>>>
>>
>>
>

--