bf:relation and the future of bf:relatedTo

[frosterus]

The change to indirect relations between Works and Instances is a very welcome one (#116).

Some questions about what this means with regards to existing BIBFRAME structures:

1. Will the newly introduced method replace the old one? In other words, will the subproperties of bf:relatedTo be deprecated?
2. What is the difference between bf:relatedTo and bf:associatedResource? The definition for the latter would be useful.
3. Should the Suggested value for bf:associatedResource include bf:Instance (and maybe bf:Item as well)? For example, bf:hasReproduction (rdam:P30039 in RDA) is between Instances.

[klngwll]

My 2 cents is I recommend against removal. I think they are very useful for some of the basic and most useful relationships including the structural ones within BIBFRAME and being able to use subClass-hierarchies within these. This leaves some design choice without being forced into the more complex relationship structure all the time. Also maintenance-wise I think breaking changes as severe as the one suggested in a minor revision would be bad practice in general.

However I totally agree that definitions to clarify ambigous relations would be helpful, and of course welcome more discussions on what this direction means in general usage before we hasten to remove useful bits :)

[kefo]

Will the newly introduced method replace the old one? In other words, will the subproperties of bf:relatedTo be deprecated?

No. There are no plans to. Who knows if that will be the case years from now, but, quite simply, there are no plans to do this even remotely soon. And, even then, no deprecation would happen with respect to these properties without ample community desire and notice.

[klngwll]

That is very reassuring @kefo! I was also reminded by a colleague about the second question regarding the differences between relatedTo and associatedResource if there is something about the usage that could be clarified in the definition?

[kefo]

So odd you commented on this today. Just yesterday I noted that I missed answering that particular question. It may boil down to a domain/range difference. associatedResource is meant to be used with the Relation class; so a domain of bf:Relation. We didn't want to overload relatedTo, which is meant to link two Works (ideally) together.