Re: RDA and ranges

Quoting Ross Singer <ross.singer@talis.com>:


> I've told you before my personal beef with the RDVocab-isms of
> titleProperManifestation
> and chronologicalDesignationOfFirstIssueOrPartOfSequenceManifestation,
> cataloguersNoteWork, etc.

:-)


>
> Again, since most agents won't have the capacity to know that
> titleProperManifestation is a subproperty of titleProper (which is
> subproperty of rdvocab:title), they'll have to look for: titleProper,
> titleProperManifestation, titleProperExpression(?), titleProperWork(?)
> (these last two don't exist and I don't know if that's intentional or a work
> in progress - there is, for example, "title", "titleManifestation" and
> "titleOfTheWork").

This is a bit of an aside, but not all concepts are valid for multiple  
FRBR group 1 entities -- in fact, the greatest area of "duplication"  
(or overlap, depending on how you look at it) is between Manifestation  
and Item. Again, this is relatively easy to see in this table:

   http://kcoyle.net/rda/group1propsby.html

especially in the areas of dimensions and extent. The issue of  
titleProper v. titleProperManifestation is explained in:

   http://dlib.org/dlib/january10/hillmann/01hillmann.html

It had to do with the need to have both FRBR-less and FRBR-bound  
entities in the registry, where the JSC only recognized the FRBR-bound  
entities. Therefore they needed to be given different names. I agree  
with you that this has resulted in messy names, although even without  
this particular issue, one does have to wonder if  
chronologicalDesignationOfFirstIssueOrPartOfSequence couldn't have  
been stated more succinctly.

kc




>
> This sort of defeats the purpose of RDF, though.  Rather than duplicating
> (quintupling, really) every property to infer the domain, it would be much
> easier on both ends to simply have:
>
> _:a
>   rdvocab:titleProper "A proper title"@en;
>   rdf:type frbr:Manifestation.
>
> If the application of the properties is different depending on the class of
> the resource it is being asserted to, then I think that can be worked out in
> documentation or an application profile or something.
>
> -Ross.
>
> On Wed, Aug 18, 2010 at 3:01 AM, Dan Brickley <danbri@danbri.org> wrote:
>>
>> On Wed, Aug 18, 2010 at 2:09 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>> > There's been something tickling my brain for a bit, so I sat down to try
> to
>> > draw up a diagram. Essentially, the question is: what is the domain &
> range
>> > of an RDA property? Then I began to wonder what is the domain and range
> of a
>> > property based on RDA but not bound to a FRBR domain?
>> >
>> > My unfinished diagram is here:
>> >
>> > kcoyle.net/domainsranges.pdf
>> >
>> > and I now realize that title isn't the best example to use. But the key
>> > element, in my mind, is that the RDA guidance rules both guide the
> metadata
>> > creator and define the range of the element. Those ranges are inherent
> in
>> > the rules but have not been extracted into the registry, in part because
>> > many of the ranges are quite complex. In the rules you find how the
> property
>> > is to be structured and what values are valid, which to me is the
> definition
>> > of the range.
>> >
>> > Note that in the diagram I have only filled in the domain and range at
> the
>> > bottom (most specific) level. That is because I'm not sure what to do
> beyond
>> > that. If we treat the RDA rules as describing the ranges for the
> properties,
>> > then all of the properties, regardless of whether they are bound to
> FRBR,
>> > are very tightly defined (probably what Tom would call ontologically
>> > strict). If we wish for other communities to provide guidance rules of
> their
>> > own for the properties, then it becomes hard to think of them as RDA
>> > properties. (This is a can of worms that has been a matter of discussion
>> > between JSC and the registry.)
>> >
>> > 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 hope I've made some sense here. Although we've discussed whether RDA
>> > properties must be bound to FRBR, in fact I think that RDA's definition
> of
>> > the values/ranges is more of a constraint than FRBR.
>>
>> This is a useful exercise!
>>
>> Quick question. Going from the diagram alone, it isn't clear to me
>> exactly how dcterms:title is more general than rdvocab:title.
>>
>> * dcterms:title, definition: A name given to the resource.
>> * rdvocab:title, definition: A word, character, or group of words
>> and/or characters that names a resource or a work contained in it.
>>
>> >From those definitions alone, it seems that rdvocab:title allows some
>> cases that aren't anticipated by dcterms:title, namely when the value
>> is a name for a work contained within the main thing we're describing.
>>
>> I read "a word, character, or group of words and/or characters" as
>> approximating the concept of "text", although on a strict reading, it
>> seems a little confused as to whether the group of words/characters is
>> necessarily ordered. Presumably the ordered group of characters [ "H",
>> "a", "m", "l", "t", "e" ] isn't a name given to Shakespeare's Hamlet,
>> whereas the ordered group  [ "H", "a", "m", "l", "e", "t" ] is?
>>
>> If we proceed with this level of nitpicking it'll take forever; is it
>> OK to assume "text that" when I see "A word, character, or group of
>> words and/or characters that"? In which case, next question is whether
>> the text can be a separate entity/resource/thing rather what RDF would
>> call a literal. If 'yes', I can't see anything that would be a value
>> fitting the dcterms:title definition but fails to match rdvocab:title;
>> if 'no', it seems the properties as defined have only partial overlap
>> rather than forming a hierarchy.
>>
>> All that said, your main point seems to be around the RD vocab and
>> FRBR, perhaps the DC aspect is a distraction?
>>
>> cheers,
>>
>> Dan
>>
>>
>> > kc
>> >
>> > p.s. I will try to locate some better examples of RDA rules as ranges.
>> >
>> > --
>> > Karen Coyle
>> > kcoyle@kcoyle.net http://kcoyle.net
>> > ph: 1-510-540-7596
>> > m: 1-510-435-8234
>> > skype: kcoylenet
>> >
>> >
>> >
>>
>>
>> Please consider the environment before printing this email.
>>
>> Find out more about Talis at http://www.talis.com/
>> shared innovation™
>>
>> Any views or personal opinions expressed within this email may not be
> those of Talis Information Ltd or its employees. The content of this email
> message and any files that may be attached are confidential, and for the
> usage of the intended recipient only. If you are not the intended recipient,
> then please return this message to the sender and delete it. Any use of this
> e-mail by an unauthorised recipient is prohibited.
>>
>> Talis Information Ltd is a member of the Talis Group of companies and is
> registered in England No 3638278 with its registered office at Knights
> Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>



-- 
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 23:02:25 UTC