Karen, thanks for this summary of the process. It's pretty
disheartening, sadly.
I got 'uri' wrong, btw, it's "Universal Resource Locator'
<!--Property: Uniform resource locator-->
-
<rdf:Property rdf:about="http://RDVocab.info/Elements/uniformResourceLocator">
<rdfs:label xml:lang="en">Uniform resource locator</rdfs:label>
<skos:definition xml:lang="en">
The address of a remote access resource. </skos:definition>
<rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"/>
<reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"/>
</rdf:Property>
But again, not exactly the best use of the tools at their disposal.
All this being said, it's really not too late to fix any of this,
since nobody is implementing this and, realistically, nobody ever
will.
-Ross.
On Tue, Apr 7, 2009 at 1:15 PM, Karen Coyle <[log in to unmask]> wrote:
> Ross Singer wrote:
>>
>> So, thanks to the help of my coworkers, here's the RDA Elements schema
>> reformatted in an easier to read presentation:
>>
>> http://morph.talis.com/?data-uri[]=http%3A%2F%2Frdvocab.info%2FElements.rdf&input=&output=exhibit&callback=
>>
>> I have to say I feel like this schema is trying to both do way too
>> much and subsequently loses the resource specificity that RDF would be
>> providing.
>>
>
> Absolutely. I think there 's a real issue that NO technology folks were
> involved in the creation of RDA. So this is "data" from a cataloger's
> perspective, and from the perspective of guidance rules for creating
> bibliographic data. I'm pretty sure that we can't create a viable data
> record using the RDA data elements, and I hate the idea that the data
> format, once again, is an afterthought rather than integral to the data
> creation standard.
>
>> For one thing, it seems to reinvent a _lot_ of wheels. Why does it
>> define its own title property instead of using DC's?
>
> Because they wanted their own definition. Everything in the RDA element list
> has an RDA-specific meaning, which then makes it impossible to use any
> existing data properties. But there's more: RDA was defining RDA cataloging
> rules, not a schema or record format. Not only are there multiple data
> elements where one could do, there are things that are missing. For example,
> the FRBR "place" entity can ONLY be used as a subject, so it really means
> "place as subject". There's no general "place" element that could be used,
> for example, in place of publication. The latter has no relationship to FRBR
> place. This is a FRBR problem as much as an RDA problem, but again FRBR
> functions at a conceptual level and doesn't really provide a schema that one
> can work with.
>
>> By using
>> properties like titleOfTheWork, dateOfWork and all of the properties
>> that are specifically about TheSeries there is tremendous duplication
>> of text. If Work was its own class, you would only need say that this
>> manifestation was an embodimentOf of it and reuse all of the
>> title-based properties for manifestation.
>
> Exactly. This is what I've been saying (or trying to say) in relation to the
> bibo discussion. You should be able to use whatever properties you want with
> the FRBR classes, and not restrict data elements to a single class. This is
> a big problem in RDA, but I can say that when it was brought up to them
> (JSC) they strongly defended this choice and would not budge. RDA, to JSC,
> has a specific relationship to FRBR, and if you use a data element with a
> different FRBR class, then you are no longer doing RDA.
>
>> What does property 'uri' mean?
>>
>
> Did you look at the rdf/xml? I'm wondering if it isn't the display that's
> confusing.
>
>> I also can't figure out how people/institutions are modeled in this
>> schema, since none of the elements have ranges. Are they their own
>> resources? If so, what? The way it looks at a glance, they're
>> strings?
>>
>
> EVERYTHING is strings at the moment, with a very very few exceptions (like
> some dates, I think). Some data elements CAN use a controlled vocabulary,
> but I believe that all of those are a mixture of uncontrolled and controlled
> strings. People and institutions are mainly undefined because that is in the
> FRAD realm. And FRAD hasn't been finalized. Also note that the JSC didn't
> feel it could do anything that would be too incompatible with the 'legacy'
> -- that is, with all of our AACR/MARC data.
>
>> It seems to me that very little work was done find preexisting
>> vocabularies to reuse and this schema still presents a very
>> 'document-centric' or 'record-centric' view of data.
>>
>
> Absolutely. The catalogers are still creating a textual document, not data.
> At best you can mark up the text, as we do with the MARC record. I worry
> that we won't be able to mesh the cataloger's view with a data view -- that
> the two are some how inherently opposed. I'd like to start modeling a new
> data format but I can't imagine how we can bridge the gap between the
> catalogers and the system view. I suppose a very clever interface could hide
> the data view from the catalogers, but starting from either AACR2 or RDA and
> trying to get there feels extremely difficult. I guess my fear is that it
> will require compromises, and those will be hard to negotiate.
>
> kc
>
> p.s. The RDA element analysis is at
> http://www.collectionscanada.gc.ca/jsc/docs/5rda-elementanalysisrev2.pdf.
> That was the input to the registry.
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> [log in to unmask] http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>
