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> ;
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" ;
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> ;
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!