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.


Joe

--------------------------------------------------
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 
> class."
>
> On 3/27/15 8:04 AM, Joseph Kiegel wrote:
>>
>>
>> Identifiers:
>> 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.
>
> kc
>
>>
>> Subjects:
>> 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
>>
>> Series:
>> RDA provides properties for all parts of series statements, while 
>> BIBFRAME has a single property:  series.
>>
>> Notes:
>> 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
>