Print

Print



On 3/30/15 12:46 PM, Karen Coyle wrote:
> Of course, applications do need to impose constraints on data. But 
> having those constraints bundled with the meaning of the data elements 
> greatly limits the flexibility of the metadata language. DC therefore 
> has defined an "application profile" that is where the 
> application-specific constraints (mandatory, repeatable) are defined. 
> So you have maximum interoperability built into the definition of your 
> metadata terms, and you still have the ability to customize the 
> metadata "record" for your particular needs using an application profile. 

Something else occurred to me after writing this, and it may not be 
obvious to others...

There is a significant difference between what the BIBFRAME vocabulary 
defines and the output from BIBFRAME programs. Because BIBFRAME is an 
RDF/OWL vocabulary, and because it does not define classes as disjoint, 
both of these are "valid" bibliographic statements based on the BIBFRAME 
vocabulary:

1.

ex:ResourceA
     bf:workTitle ex:AdventuresOfTomSawyer ;
     bf:hasInstance ex:ResourceB ;
     bf:creator lcna: n79021164 ;
     bf:language iso639-2:eng .

ex:ResourceB
      bf:providerDate "1996" ;
      bf:instanceOf ex:ResourceA ;
      bf:instanceTitle ex:TheAdventuresOfTomSawyer .

2.

     ex:ResourceC
         bf:creator lcna: n79021164 ;
         bf:workTitle ex:AdventuresOfTomSawyer> ;
         bf:language iso639-2:eng ;
         bf:instanceTitle ex:TheAdventuresOfTomSawyer> ;
         bf:providerDate "1996" .

In other words, the vocabulary does not determine that you must have a 
work "thing" and an instance "thing." It also does not have any say on 
whether properties are mandatory or repeatable. There is nothing in the 
vocabulary that would prevent you from having no work title, or a dozen 
work titles. This is inherent in RDF/OWL, which cannot enforce rules 
over a vocabulary, by its nature. Conversion of MARC records of course 
turns out bibliographic data consistent with what is in the MARC records 
(e.g. one 245). But the separation of properties into work and instance 
is a decision being made in the conversion programs. This means that 
there are rules being applied in the programs that process BIBFRAME 
records, but these rules are in addition to the BIBFRAME vocabulary, not 
part of it.

I don't recall any discussion of the rules that will be used in LC's 
implementation of the BIBFRAME vocabulary, but should this data become 
available on the open Web, only the essence of the vocabulary as defined 
in RDF/OWL will be applicable. It would be helpful to have clarity on 
the differences between the vocabulary and the implementation.

kc

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600