RE: RDA and ranges - take 2

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.

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.

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

Received on Wednesday, 18 August 2010 19:50:02 UTC