 |
 |
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 >