- From: Karen Coyle via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Sep 2020 22:04:18 +0000
- To: public-dxwg-wg@w3.org
Andrea, many of the relationships in FRBR express some type of "version." The problem with the FRBR properties is that they are all clearly defined as to domain and range, which means that they pertain to entities that have been defined as one of the FRBR WEMI classes, and the classes are defined as disjoint. Thus, "translation" has a domain of frbr:Expression and a range of frbr:Expression  and "alternate" has a domain of frbr:Manifestation and a range of frbr:Manifestation  Each of the classes in FRBR is also defined as disjoint:  You would need to make sure that you do not "cross the streams" - that is, mix the WEMI classes when using FRBR relationship properties in a way that would violate the disjointness. Within the ones you have listed (and there could be others that are useful, it seems to me), translation can be used only with Expressions and alternate only with Manifestations. This reflects the very strict concepts of WEMI for library data, which I doubt is how anyone outside of library catalog creation can operate. It is too bad that the properties, which could be useful in other contexts, are so constrained in their definitions. It very much limits the reusability of FRBR properties. I don't know how everyone feels about "going rogue" and possibly ignoring domains, ranges and disjoint declarations, but that might be what would be needed. I would be willing to give a general overview of possibly useful properties for versions, but ignoring for the moment the question of compatibility with the FRBR vocabulary. -- GitHub Notification of comment by kcoyle Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1251#issuecomment-694523464 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 September 2020 22:04:20 UTC