You have the urge to define classes in order to avoid duplicating
definitions?
Becuase RDA duplicates definitions in different parts of itself,
defining differnet things the exact same way in multiple places, instead
of including the definition once and then refering to it multiple times?
I don't see any problem with you going ahead and defining those classes
in order to avoid duplicating definitions, even if RDA doesn't. After
all, the _product_ will be the same; the thing you are defining will
still be exactly the same thing as RDA defines, you've just taken a step
to define it more economically than RDA does. But you've still defined
the same thing. No?
That seems like a fine way to go to me, it doesn't seem to me a problem
that RDA doesn't use that economy of definition.
Alternately, it doesn't seem the end of the world to me to just go ahead
and define the different elements exactly the same way, multiple times.
Not usually the way we like to do things, but if your sense of adhering
to RDA says you should do it that way, doesn't seem like a disaster to
me. Will this cause problems for implementors? I don't _think_ so, I
could be wrong.
Am I the reasons this is problematic? It doesn't seem that problematic
to me either way? Am I missing the problem you are looking for a
solution to, it's not simply that you would like to economically define
in one place what RDA profligately defines identically in multiple places?
Jonathan
Karen Coyle wrote:
> But RDA doesn't define classes -- that's the problem. We can try to
> define them for RDA, but that isn't a concept in the RDA elements that
> we've been given. And I'm not at all sure that the aggregate elements
> will work as classes, for reasons I gave above. So I'm trying to find
> a practical solution for the moment, one that doesn't violate RDA.
> (Note that RDA may NOT be RDF compatible as defined in the current RDA
> documentation, and we need to work around that at the moment.)
>
> kc
>
> On Fri, Jan 2, 2009 at 1:54 PM, Mikael Nilsson <[log in to unmask]> wrote:
>
>> The "right" RDF-y way to do it is to set the range of the properties to
>> the appropriate class.
>>
>> That way, values are known to be of the right type. Application profiles
>> can then decide how they want to describe instances of that class.
>>
>> Thus, there is no conceptual difference between the two kinds of
>> "properties" you see in RDA. The substructure is only an artifact of the
>> application profile.
>>
>> /Mikael
>>
>> fre 2009-01-02 klockan 13:18 -0800 skrev Karen Coyle:
>>
>>> Back to place and date...
>>>
>>> On Mon, Dec 22, 2008 at 9:00 AM, Alistair Miles
>>> <[log in to unmask]> wrote:
>>>
>>>
>>>> Not directly related to any scenarios, I found that rda:placeOfCapture
>>>> is a sub-property of rda:placeAndDateOfCapture, which doesn't look
>>>> right. This looks like a case where Tom Delsey's "sub-elements"
>>>> pattern got wrongly translated to RDF sub-properties, where rather it
>>>> should be modelled in RDF as an n-ary relation.
>>>>
>>> This still leaves us with the question of what to do with these in the
>>> registry. I don't think there is an 'n-ary' capability, whatever that
>>> would look like. Also, I'm not sure that these empty properties make
>>> sense in the property list... I think you would want to manage them in
>>> an application profile. Here are some examples from RDA:
>>>
>>> Place and date of capture (empty)
>>> - Place of capture
>>> - Date of capture
>>>
>>> Publication statement (empty)
>>> - Place of publication
>>> - Parallel place of publication
>>> - Publisher's name
>>> - Parallel publisher's name
>>> - Date of publication
>>>
>>> If we can imagine any use of these properties OUTSIDE of the
>>> particular empty node, then I think they need to be separately defined
>>> as properties, not as dependent on the empty node. We also have the
>>> problem that RDA doesn't make use of classes so that there is a great
>>> deal of repetition in the property/element list. As an example, there
>>> are four different sets of elements that are the same as the
>>> Publication statement, but that substitute one of these words for
>>> Publication: Production/Publication/Distribution/Manufacture. And as
>>> you can see, they also share some meaning with the "capture" concept,
>>> in terms of place and date. I immediately want to take these and
>>> rationalize them by defining simple properties:
>>>
>>> - date
>>> - agent name
>>> - place
>>>
>>> ... and allowing any element to have a 'parallel' (which is the same
>>> value in a different language).
>>>
>>> Unfortunately, at the moment we are trying to be true to RDA's
>>> definition of its properties, so I need to sit on my virtual hands and
>>> not mess with what they have defined.
>>>
>>> Any ideas what we can do with our empty nodes/Tom's sub-elements,
>>> given this info? In many cases we just entered each element as a
>>> separate property, including the empty node one. Is there a down side
>>> to this solution?
>>>
>>> kc
>>>
>>>
>>>
>>>
>> --
>> <[log in to unmask]>
>>
>> Varning! E-post till och från Sverige, eller som passerar servrar i
>> Sverige, avlyssnas av Försvarets Radioanstalt, FRA.
>> WARNING! E-mail to and from Sweden, or via servers in Sweden, is
>> monitored by the National Defence Radio Establishment.
>>
>>
>
>
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
|