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