Re: RDA and ranges

On Wed, Aug 18, 2010 at 8:47 PM, Diane I. Hillmann <metadata.maven@gmail.com
> wrote:

> 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).
>
>
I  guess it depends whether you think about the issue with the concern of
creating new, RDA-compliant data, or with the concern of putting library
legacy data into the semantic Web.

Regarding the latter, it is an issue to me that we will need some poperties
that do exist in RDA (TitleProper for example, maybe others) but the data
actually is legacy data, and it has not been created in conformance to RDA,
but rather ISBD+ french standards.

So, I agree with Karen, there is a difference here, and does it mean that if
I want to express BnF data in RDF, I'd rather not use RDA properties, and
create my own ?  If a national libray producing data in a Universal
Bibliographic Control process is not able to use the RDA properties, who
will ?
The idea to have a more generic, unbounded (or at least, less bounded) set
of RDA properties seems useful to me, in a very pragmatic way. It's both
about interpreting FRBR (which we may want to do slightly differently from
RDA) but also about content rules, and legacy data that is not RDA
compliant, and never will be.

Emmanuelle




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