RE: RDA and ranges - take 2

Quoting Jon Phipps <jonp@jesandco.org>:

> Karen,
>
> Wherever we thought it was possible to embody the RDA rules into a
> single, relatively simple dcam:SyntaxEncodingScheme, we created a SES as
> a rdfs:datatype class, for instance:
> http://rdvocab.info/Elements/PublicationStatementEncodingScheme
> ....and assigned it to the range of the property. There's no formal
> mechanism in RDF to define a domain-specific datatype, so we just made
> the construct part of the definition for now.

Jon, yes, and yet I do think that RDA, as defined by the JSC, is  
probably under-defined in some ways. My assumption has been that we'll  
need to tightened things up a bit in order to create an actual  
machine-readable format. Or you could assume that RDA will consist  
mainly of literals, like MARC. That, of course, doesn't take us very  
far in the linked data world, because it generally doesn't provide  
enough structure to make the use of URIs feasible. For example, if  
Extent is treated as a literal, then there can be no use of the URIs  
for carrier, yet there is a defined vocabulary, with URIs, for  
carrier. If that can't be coded in RDA, then we miss an opportunity to  
be precise.


>
> My question about your current diagram is whether the range of
> rdvocab:extent, continues to be valid, according to the RDA knowledge
> domain, if applied to any owl:thing regardless of rdf:type? I'm inclined
> to think that once you 'dumb-down' rdvocab:extent(Manifestation) to a
> domainless rdvocab:extent, the range encoding as defined by the RDA
> rules makes quite a bit less sense and rdvocab:extent might be more
> generally useful without a range, making it easier to subclass within
> other knowledge domains.

That's an excellent question, and my answer is: I'm not sure. When I  
read through the rules in the section on Extent, I don't think that  
the domain of manifestation affects my ability to use the rules to  
construct the necessary description. In fact, I think that this is  
what the libraries that are about to start testing RDA will be doing,  
since they will encode RDA-guided properties into a non-FRBR structure  
(MARC21). Of course, that might be a totally illogical thing to do,  
and not very meaningful, as some have argued.

However, we know that JSC intends "RDA" to mean only those properties  
with the domains and ranges as defined by them. So anything else that  
we postulate is by definition "not RDA" to the JSC. This, however, is  
generally seen as keeping libraries in their usual silo and therefore  
not desirable.

One of the ideas of the general properties (as you undoubtedly know  
well) was to allow some in the library community or related  
communities to use RDA for guidance in creating metadata instances,  
but with a different binding of the properties to FRBR. For example,  
there is an RDA property "colour of moving image" that has as domain  
Expression in RDA, but we know that there are folks in film archives  
that wish to use that property with domain Work. (This of course  
argues for APs again.) If a domainless property must also be  
range-less or at least cannot be defined with an RDA range, then these  
communities cannot use RDA at all. I think they would like to create  
metadata that is substantially compatible with RDA, but with some  
differences, including differences in how the FRBR domains are defined.

This gets us into one of your favorite arguments: do the FRBR domains  
define the properties, or do the properties define the domain? My  
question is: If you remove FRBR from the equation, how much of RDA is  
still usable? Since I come from the pre-FRBR generation, and the  
library metadata I have worked with for 30 years is not defined in  
terms of FRBR entities, I tend to see the FRBR domain declarations as  
informative but not decisive. To me, FRBR is one interesting way to  
think about bibliographic metadata, but I'm not convinced it is the  
only possible structure for bibliographic metadata. Be that as it may,  
at some point we'll have to decide how to define properties for LLD.  
For the moment, I'm just interested in brainstorming on the various  
possibilities. It would be good to be able to present a broad set of  
options should we get a chance to explain how APs could help us have a  
flexible but interoperable data environment.

kc


>
> Jon
>
> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Karen Coyle
> Sent: Wednesday, August 18, 2010 1:03 PM
> To: public-lld@w3.org
> Subject: Re: RDA and ranges - take 2
>
>
>
>>
>> What I am getting at is that we may need a hierarchy that goes like
>> this (from most specific to most general):
>>
>> 1. RDA + FRBR -- range is as defined in RDA; domain is FRBR entity 2.
>> RDA alone -- range is as defined in RDA; no domain?
>> 3. Property with definition -- range and domain are open
>>
>
> I've re-done the diagram using Extent, which I think better illustrates
> the issue:
>
> http://kcoyle.net/domainsrangesExtent.pdf
>
> What is doesn't cover is a 4th possibility:
>
> 4. Property with definition + FRBR
>
> This might be useful in creating a FRBR-zed version of MARC (but maybe
> not) -- but in any case it is a logical extension of all of this.
>
> kc
>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
>
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 18 August 2010 21:07:59 UTC