Joe,

If I’m reading BIBFRAME correctly, it has one property: bf:digitalCharacteristic (which has a range of bf:DigitalCharacteristic). 

So if you had a geospatial data set, I imagine you would describe it as follows:

ex:Work1 a bf:Dataset , bf:Cartography ;
  bf:hasInstance ex:Instance1 .

ex:Instance1 a bf:Electronic ;
   bf:digitalCharacteristic ex:CartographicDataType1 , ex:ObjectCount1 , ex:DigitalCartographicObjectType1 .

If you didn’t want to describe the digital characteristics with that level of granularity, you could use the more general superclass of bf:DigitalCharacteristic. E.g.

ex:Instance1 bf:digitalCharacteristic ex:DigitalCharacteristic1 .

I don’t understand what the new Cartographic Representation class you propose will buy us. Isn't it really just a general bf:DigitalCharacteristic of an electronic bf:Instance of a bf:Work that is typed as a bf:Dataset, bf:Cartography?

Thanks,
Steven


 


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Joseph Kiegel <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Monday, May 23, 2016 at 7:15 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: [BIBFRAME] Carrier description information

It’s great that BIBFRAME 2.0 supports carrier description information.  Overall, it is well done and meets the needs of RDA cataloging. 

 

There is, however, one area that could use improvement:  digital representation of cartographic information.  Different cataloging codes or encoding schemas record this information with different levels of granularity.  RDA uses a single property (rule 3.19.8) that may contain three different types of information:  data type, object type, and number of objects.  BIBFRAME, on the other hand, uses three separate classes:  CartographicDataType, CartographicObjectType, and ObjectCount.

 

The result is that is difficult to impossible to map this RDA property into BIBFRAME cleanly.  This could be resolved by adding an intermediate level to the BF class hierarchy, e.g.

 

DigitalCharacteristic

               CartographicRepresentation

                              CartographicDataType

                              CartographicObjectType

                              ObjectCount

 

In this way, a code or schema at any level of granularity has a place for a mapping.  That is, RDA could map to CartographicRepresentation, while MARC, which uses separate subfields, can map to the appropriate subclasses.

 

The class name “CartographicRepresentation” can, of course, be whatever you deem best.