I agree with your point about strings vs identifiers in RDA. Depending
whether rdaw:mediumOfPerformance contains a URI or a literal, it must be
conditionally mapped to bf:musicMedium or bf:musicMediumNote.
However, while BIBFRAME properties have their ranges set either to a literal
or a URI, the paired properties needed to cover both cases are not always
defined. For example, for rdam:mediaType, rdam:carrierType and
rdae:contentType, the value may be either a literal or URI under RDA. Of
course, we would prefer URIs in linked data. On the BIBFRAME side, the
corresponding properties are mediaCategory, carrierCategory and
contentCategory, all of which have a range of bf:Category. Of the
properties with a domain of bf:Category, we have only bf:categoryValue in
which to put a value, and its range is a literal. There is no
bf:categoryUri with a domain of bf:Category and a range of rdfs:Resource,
which is needed to contain category values when they are URIs.
The same thing is true with identifiers in BIBFRAME. Conceivably, you could
decompose identifier URIs into bf:identifierScheme (range: rdfs:Resource)
and bf:identifierValue (range: rdfs:Literal), but that is doing it the hard
way. It would be better to have a property bf:identifierUri with a domain
of bf:Identifier and a range of rdfs:Resource, which could contain an
identifier expressed as a URI. As it stands now, even bf:uri has to have a
literal as its value.
From: "Karen Coyle" <[log in to unmask]>
Sent: Saturday, March 28, 2015 7:05 AM
To: <[log in to unmask]>
Subject: Re: [BIBFRAME] BIBFRAME and RDA/RDF
> Joseph, thanks for doing a comparison. Note that BF has about 400
> properties, while RDA has nearly a thousand, so it is true that RDA is
> more detailed that BF. However, RDA has virtually no class
> relationships -- it's essentially a flat data space. This will have
> implications for the use of RDA in actual systems, since class
> relationships help you do things like "search all properties in the title
> On 3/27/15 8:04 AM, Joseph Kiegel wrote:
>> Under the influence of MARC, BIBFRAME has a large set of properties for
>> identifiers while RDA is limited.
> The RDA rules often allow either strings or identifiers. RDA in RDF is
> essentially silent in most cases on whether the value for a property is
> expected to be a string or an identifier, and therefore it can presumably
> be either. This, however, is highly problematic when working with RDF
> data. In general, it's never good to not know what kind of data to expect
> for a field in your metadata -- it complicates input interfaces and the
> programs that use the data. However, if you want to have the possibility
> in your data to accommodate both strings and identifiers, you are kind of
> forced to create different properties for those different choices, which
> would mean nearly doubling the number of RDA properties. Although I find
> the use of blank nodes in BF to be a complicating factor, I assume that in
> many cases those blank nodes are there as a way around this
> string-vs-identifier problem, allowing each statement to point to a blank
> node that can have either or both.
> To me this is evidence that we need to re-iterate back from our attempts
> to create a viable RDF version of library data to the cataloging rules,
> and create at least a subset of the rules that can support a viable data
> format with clearly defined data values for each property. The "string or
> identifier" in the rules just isn't workable in a data format.
>> RDA is not yet able to express subject relationships (RDA chapters 33-37)
>> and BIBFRAME has a mechanism for this.
>> Holdings Information:
>> Although not fully elaborated, BIBFRAME has properties for holdings
>> information while RDA has almost nothing.
>> RDA is richer than BIBFRAME
>> RDA provides properties for all parts of series statements, while
>> BIBFRAME has a single property: series.
>> RDA has more properties for specific types of notes. While BIBFRAME has
>> note properties, the term "note" in a property name may mean simply that
>> its range is a literal, e.g. findingAidNote, musicMediumNote.
>> Technical Details of a Resource:
>> RDA has a large number of properties for technical details of resources
>> such as polarity, playingSpeed, fileSize, etc. It is not clear how
>> BIBFRAME handles this type of information.
>> Inverse Properties:
>> RDA provides inverse properties (e.g. animator and animatorOf) while
>> BIBFRAME lacks them.
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600