Print

Print


thanks, Steven. This is along the lines of what I was suggesting. I note
in the LD4L document[1] that you list the RDAU relationship properties
and sub-properties, e.g.

rdau:P60250
Label: is derivative
URI: http://rdaregistry.info/Elements/u/P60250
Definition: Relates a resource to a resource that is a modification of a
source resource.
Subproperties:
●rdau:P60115 "is modified by variation as"
●rdau:P60120 "is remade as"
●rdau:P60121 "is set to music as"
●rdau:P60177 "is abstracted in"
●rdau:P60178 "is indexed in"
●rdau:P60180 "is adapted as choreography"
etc.

Is LD4L using the full sub-property group? (Or potentially, could it?)
If so, that could go a long way to making more of a match between RDA
and BF in Joe's list, which only includes the higher level relationships.

Or, when you say: sticking to the general properties, do you mean only
the highest level, e.g. "is derivative"? Does your comment about
including resource types in properties as an "anti-pattern" include
properties like "is set to music as"? I think in a sense the rdau
property name is reflecting a range definition, and assumes perhaps a
point of validation for matching the relationship and the range. Is LD4L
taking a strict approach on that?

kc
[1]
https://wiki.duraspace.org/display/LD4P/bibliotek-o?preview=/79795231/83237330/bibliotek-o_pattern_relations_201612.pdf

On 10/20/17 12:30 PM, Steven Michael Folsom wrote:
> In the LD4L analysis and adoption of BF2 we chose simply to extend BF2 using select RDAU properties. [1]
> 
> RDAU isn’t perfect, but sticking to the general properties would get us pretty far. Our biggest reason for only using *select* RDAU properties is proliferation caused by the anti-pattern of minting new properties to account for the type of things being related; we don’t need “is opera adaptation of” if we have the more general “is adaptation of” and an Opera class/genre term. 
> 
> Similarly, using relationships to create new classes (as described in Joe’s bf:ChoreographicAdaption example below) causes unnecessary Class proliferation; each class would then require parallel classes for all the different types of relationships between resources.
> 
> The other option being floated below (using bflc:Relationship) seems like over engineering for a problem that could be solved with just reusing the parts of RDAU that are well designed.
> 
> Is this under consideration?
> 
> Respectfully,
> Steven
> 
> [1] For more information on the LD4L analysis of BIBFRAME, see:
> - https://bibliotek-o.org/overview/overview.html
> - https://wiki.duraspace.org/display/LD4P/bibliotek-o 
> 

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600