W3C home > Mailing lists > Public > public-lld@w3.org > August 2010

RE: RDA and ranges

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 18 Aug 2010 14:22:19 -0700
Message-ID: <20100818142219.y2jckvlecgkgsskw@kcoyle.net>
To: Jon Phipps <jonp@jesandco.org>
Cc: public-lld@w3.org
Quoting Jon Phipps <jonp@jesandco.org>:


>
> At one point it was the JSC's contention that all RDA properties had to
> describe a FRBR entity -- no FRBR-related domain? Then it's not RDA.
> Karen, this seems to be your position as well

No, not at all... so I will try to be clear when I am stating what I  
think JSC has expressed, and when I am talking about other options.

> and I fundamentally
> disagree. RDVocab.info is a specific domain intended to gather and
> organize the RDA knowledge domain. RDA-defined properties belong in that
> domain. The RDA domain-less properties _might_ belong in a different
> _namespace_ than the properties that are specifically describing one of
> the FRBRinRDA classes, but they're still RDA and belong in the
> RDVocab.info domain.

You may be reading too much into my use of name spaces in my examples.  
I'm really not concerned at this point about what name spaces are used  
for the properties (and I don't consider name spaces to be anything  
but opaque identifiers). I consider that to be a detail that can be  
dealt with later. More important is the question of how we define  
properties and subproperties, that is the relationship that we create  
between properties with different domains and ranges.


>
>> From the standpoint of semantic interoperability, it's useful to have
> domainless and rangeless generalized properties that can be subclassed
> and refined in other knowledge domains, or used as-is within a less
> FRBR-specific context. Interoperability in a world defined for machines
> by rdfs/owl is not necessarily about everyone agreeing to use the same
> properties to describe various closely-related things. It's about being
> able to express your organizational knowledge of your domain at any
> granularity you wish and to be able to create domain-specific classes
> and properties to express that knowledge while still expressing that
> knowledge in a broader context by subclassing or declaring equivalencies
> with the classes and properties defined in other domains.

Exactly. And this began when I tried to understand for myself what the  
meaning of the generic properties was in relation to the "official"  
RDA properties. What does it mean to declare the same property without  
the FRBR domain constraint? I may be making a hash of it, but that's  
what got me going.

>
> The challenge with macro-models like RDA is to express the
> domain-specific knowledge of the modelers, but leave the door open just
> a crack for different notions of that model. There's plenty of room for
> RDA-FRBR, IFLA-FRBR, Talis-FRBR, kcoyle-FRBR as long as it's possible to
> declare a semantic relationship between those models at some point so
> the machines have a chance to infer a clue as to what each metadata
> model means in relation to the others.

WE've already got about 5 different FRBR's -- they seem to spring up  
like mushrooms!

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 11:11 AM
> To: Emmanuelle Bermes
> Cc: public-lld@w3.org
> Subject: Re: RDA and ranges
>
> Quoting Emmanuelle Bermes <manue.fig@gmail.com>:
>
>> In your diagram, I see no middle-term between defining a very precise
>> range, and no range at all.
>
> Right. That's where I got stuck, myself.
>
>
>   However, it could be useful to determine at least if
>> the range should be a literal, or a resource with a URI.
>
> Exactly. And somewhere in the text of RDA we should be able to discover
> that, although it's often not clear. It's not clear because most
> sections of RDA have a number of "if" "else" and other options.
>
>
>>
>> When you state that the range for rdavocab:titleProper(Manifestation)
>> is "RDA 2.3.2", what you actually mean is that the range is a literal,
>
>> and the literal should be constructed by the cataloguer following RDA
> rules 2.3.2.
>> This is something that cannot be checked by a machine, and we have to
>> remember that ontology semantics is meant for machine interpretation.
>
>
> Yes, you are right. The cataloguing rule itself isn't going to be
> something that can be validated. However, I can assure you that it is
> the intention of the RDA developers that the elements they have defined
> are only to be used following the rules that, in a sense, "spawned" the
> elements. So perhaps what would be more correct would be to add the rule
> number into the definition, and derive the range from what we can
> understand from the guidance text. (Not an easy job, btw).
> However, there must be a distinction between a titleProper created
> following the RDA guidance rules and, as an example, a titleProper
> created following the AACR2 guidance rules. These are different
> properties. I realize that not all communities approach metadata at this
> level of specificity, but ... well, welcome to my world. :-) For those
> of us who lived through the change in name forms between AACR and AACR2,
> we know that rule changes can actually mean the creation of
> different/incompatible data for what may appear to be "the same thing."
>
> This still leaves us with the question of how do we generalize RDA?
> And my idea is still that the big difference between general and not
> general is not limited to the RDA vocabularies' binding with FRBR, but
> also its binding with the rules themselves. So this is in response to
> the treatment of the FRBR binding as being overly ontologically strict
> (as Tom described it). I agree with Ross that the FRBR binding could
> more easily be handled like:
>
> _:a
>    rdvocab:titleProper "A proper title"@en;
>    rdf:type frbr:Manifestation.
>
> And that seems to me to be a logical role for an application profile.
> (Something we tried desperately to convince the JSC to accept, but that
> approach was rejected.)
>
> I am saying that we now have yet another "facet," which is whether the
> data has been created following the RDA guidance rules. This, too, could
> be expressed in an application profile. However, if we do not use APs,
> then we have yet another duplication of every RDA property:
> uses RDA rules/other. (Either doesn't use the rules or is unknown.)
>
> I admit that this is a mess, and maybe I shouldn't have brought it up,
> but it doesn't make sense to me to discuss RDA properties'
> relationship to FRBR while ignoring the relationship to the guidance
> rules.
>
> Diane will kill me for this (because it would mean a huge amount of work
> on the registry) but I have often thought that the generalized terms
> should be placed under a different URI (and didn't Gordon say recently
> that that had been discussed in the JSC?), and those would implicitly be
> separate from the RDA rules. We shouldn't call those generalized terms
> "RDA" any more than we would give the MARC elements a URI that implies
> that they are derived from AACR2.
>
> Now I think I have to create a new diagram. :-)
>
> kc
>
>> Even in current library systems, the adequacy of the content of
>> metadata fields to cataloguing rules is not checked by machines. It is
>
>> checked in a quality assessment process by humans (at least, in my
>> library - well if someone knows how to check that in an automated way,
>
>> please send me an e-mail ;-). This adequacy relies on guidelines and
>> training of cataloguers, and not on a formal metadata structure (be it
>
>> MARC, MARCXML, MODS, DC or any other).
>>
>> So, to go back to the model, here is how I see things could be done :
>> - rdavocab:titleProper(Manifestation) would be declared as a property
>> with "literal" as range
>> - in the note or description, it would be stated that the literal is
>> expected to be constructed according to RDA rule 2.3.2.
>> I have to dive deeper into application profiles to see how they can
>> help with expressing this constraint in a more explicit or formal way.
>>
>> Then the "super-properties" (in your example rdavocab:titleProper and
>> rdavocab:title) could be declared with only "litteral" as a range and
>> no precision on how the litteral should be constructed. That would
>> make them sub-properties of DC:title, which has no range. Maybe they
>> could have at least "FRBR group 1 entity" (WEMI) as a domain (well,
>> that's another discussion).
>> Or even, if they have no domain and no range, I don't see a reason why
>
>> they couldn't be declared equivalent to DC:title (rather than
> subproperties).
>> I guess it was the point made by Dan, but I must admit there are some
>> things that are not completely clear to me in his comment.
>>
>> Obviously, the range discussion is completely different when the range
>
>> is not a literal but a class or a resource.
>>
>> Emmanuelle
>>
>> On Wed, Aug 18, 2010 at 9: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
>>> >
>>> >
>>> >
>>>
>>>
>>
>
>
>
> --
> 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:22:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:57 UTC