thanks, Steven. This is along the lines of what I was suggesting. I note
in the LD4L document that you list the RDAU relationship properties
and sub-properties, e.g.
Label: is derivative
Definition: Relates a resource to a resource that is a modification of a
●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"
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?
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. 
> 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?
>  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
[log in to unmask] http://kcoyle.net