Print

Print


What I'm trying to say is that you can get the same level of specificity through the relationships between the  bf:Cartographic/Dataset Work and an bf:Electronic Instance without introducing a new bf:DigitalCharacteristic subclass specific to cartography. A bf:DigitalCharacteristic IS a ex:CartographicRepresentation if it is linked to a cartographic/dataset work and an electronic instance.

Following the ex:CartographicRepresentation pattern, I'm afraid that we would find ourselves creating a bf:DigitalCharacteristic subclass for every bf:Work subtype.

Another observation about the bf:DigitalCharacteristics Pattern...

Examples of bf:FileTypes seem like they could be used as subtypes of bf:Electronic. E.g.,

<Text> a bf:Work ;
bf:instance <SomePDF> .

<SomePDF> a bf:Instance , ex:PDF .

ex:PDF a bf:FileType .



From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Joseph Kiegel <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Tuesday, May 24, 2016 at 10:59 AM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[log in to unmask]>>
Subject: Re: [BIBFRAME] Carrier description information

DigitalCharacteristic is very broad, including a range of other characteristics such as file type, file size, encoded bitrate, etc.  It is true you can map at that level, but you lose the information that the data pertain to digital cartographic material.  A class like CartographicRepresentation provides that information.

Joe

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Folsom, Steven
Sent: Tuesday, May 24, 2016 6:00 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] Carrier description information

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]<mailto:[log in to unmask]>> on behalf of Joseph Kiegel <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Monday, May 23, 2016 at 7:15 PM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[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.