Re: RDA and ranges

On 8/18/10 11:10 AM, Karen Coyle wrote:
>
> The cataloguing rule itself isn't going to be something that can be 
> validated. However, I can assure you that it is the intention of the 
> RDA developers that the elements they have defined are only to be used 
> following the rules that, in a sense, "spawned" the elements. So 
> perhaps what would be more correct would be to add the rule number 
> into the definition, and derive the range from what we can understand 
> from the guidance text. (Not an easy job, btw). However, there must be 
> a distinction between a titleProper created following the RDA guidance 
> rules and, as an example, a titleProper created following the AACR2 
> guidance rules. These are different properties. I realize that not all 
> communities approach metadata at this level of specificity, but ... 
> well, welcome to my world. :-) For those of us who lived through the 
> change in name forms between AACR and AACR2, we know that rule changes 
> can actually mean the creation of different/incompatible data for what 
> may appear to be "the same thing."
>

While I agree that the connection with the rule numbers would be really 
useful somewhere, I don't think the definition is the proper place for 
it.  For one thing, it is one of those things that will need to be 
maintained properly (we know those numbers are not cast in stone) and 
'churning' definitions by adding that kind of data strikes me as a bad 
idea. It might be better to express that as part of a specifically 
'library' Application Profile.

Although I agree that titleProper created under RDA is different from 
titleProper under AACR2, I'm not clear about why we need to worry about 
AACR2 in the context of a discussion of RDA properties. It certainly is 
an issue if we had a similar set of declarations for MARC, which has 
explicitly said it can accommodate RDA as well as AACR2 (something I 
question, but won't bore anyone with those arguments here).

> This still leaves us with the question of how do we generalize RDA? 
> And my idea is still that the big difference between general and not 
> general is not limited to the RDA vocabularies' binding with FRBR, but 
> also its binding with the rules themselves. So this is in response to 
> the treatment of the FRBR binding as being overly ontologically strict 
> (as Tom described it). I agree with Ross that the FRBR binding could 
> more easily be handled like:
>
> _:a
>   rdvocab:titleProper "A proper title"@en;
>   rdf:type frbr:Manifestation.
>
> And that seems to me to be a logical role for an application profile. 
> (Something we tried desperately to convince the JSC to accept, but 
> that approach was rejected.)

I'm not sure I agree with Ross's arguments but will respond to them 
explicitly at another time.  I think the DCMI/RDA TG still wants to do 
an Application Profile, and as I've said before, I believe the addition 
of Domains to the RDA properties is a start on that.

>
> I am saying that we now have yet another "facet," which is whether the 
> data has been created following the RDA guidance rules. This, too, 
> could be expressed in an application profile. However, if we do not 
> use APs, then we have yet another duplication of every RDA property: 
> uses RDA rules/other. (Either doesn't use the rules or is unknown.)
>
> I admit that this is a mess, and maybe I shouldn't have brought it up, 
> but it doesn't make sense to me to discuss RDA properties' 
> relationship to FRBR while ignoring the relationship to the guidance 
> rules.

I agree this is an important issue, but I don't think it's going to be 
accomplished easily, and I'm not sure how relevant it is to the machines 
consuming the data, though for sure some of the human users will care 
(and there should still be room for them to care and use quality control 
assessments to rate compliance).  And, as we know from our many years 
with AACR2, there are always alternative approaches to application, even 
within the same rules, particularly when we're talking about contexts 
like public libraries vs. specialized libraries.  In my view, the 
differences between how these communities will interpret FRBR, and how 
this will be accomplished within Application Profiles (which is, in my 
opinion, where that effort belongs) is a much more interesting issue, 
and one we need to address before we'll get much uptake with RDA.

>
> Diane will kill me for this (because it would mean a huge amount of 
> work on the registry) but I have often thought that the generalized 
> terms should be placed under a different URI (and didn't Gordon say 
> recently that that had been discussed in the JSC?), and those would 
> implicitly be separate from the RDA rules. We shouldn't call those 
> generalized terms "RDA" any more than we would give the MARC elements 
> a URI that implies that they are derived from AACR2.
>

Now, now, no violence!  It seems to me that an approach that is even 
more useful is that the generalized RDA properties be considered RDA, 
and the properties that are FRBR-bounded (and perhaps with references of 
some kind to RDA rules) be considered the AP version. (Honestly, I just 
don't see the analogy with AACR2 and MARC as being very useful.) One 
thing is for sure, Diane's not doin' nuttin' with changes like that 
until the issues and implications have been thoroughly explored, which 
they certainly haven't been yet.

Diane

Received on Wednesday, 18 August 2010 18:48:20 UTC