Hi Kim, Good question.
I'd be interested to hear other opinions, but my immediate thought is that exercise of modeling/redefining Person / Project / Org makes better sense if we decide *against* leaning on / adopting DSpace-CRIS. As then we'd have to (re)build and re(model) these concepts ourselves within our existing DSpace data model. (That doesn't mean we cannot compare models against other things out there, like VIVO. But, it makes less sense to re-model things unless we are building it ourselves.) If we decide to go with all/part of DSpace-CRIS, then we'd be essentially deciding to go with their model (at least for now). However, there'd obviously be opportunities to later modify / enhance / refactor that model down the line (similar to how we recently refactored our DSpace data model to support metadata on all objects). There has not been any formalized additional modeling of this nature in the DSpace Entities Discussions. We did do some basic analysis of the DSpace-CRIS model in order to ensure it aligned with the requested use cases (and it does). Obviously the DSpace-CRIS team has used their existing models for many years in production for ~100+ institutions world-wide, so that, in itself, is some proof that their models are at least accurate for a CRIS use case. Thanks for the question, and feel free to keep them coming - Tim On Tue, Mar 6, 2018 at 3:26 PM Kim Shepherd <k...@shepherd.nz> wrote: > Made a long comment at the end of the doc so thought I'd post it here too! > > Should we be thinking about the models/schemas/ontologies used for > representing the (likely) core entities, as well as the nuts'n'bolts > implementations of how the DB tables, business layer methods &c are going > to work? > > In particular, I'm thinking about the Person and Org entities and the way > they're modelled/represented in DSpace-CRIS (CERIF Person / ResearchPage / > OrgUnit?), and how we might be able to learn from sister projects like VIVO > which is all about ways to model and publish these kinds of entities and > their relationships. (and tries to work in with a lot of existing concepts > like CERIF, CASRAI, &c) > > If the idea is that we should just be designing something extensible > enough to work with any models and this kind of abstract modelling is out > of scope, then fair enough... I just hadn't seen it mentioned and I wonder > if some decisions at the basic "what is a Person" or "what is a Project" > level might end up affecting implementation / design decisions in DSpace > itself later... > > -k > > On Friday, March 2, 2018 at 11:14:02 AM UTC+13, Tim Donohue wrote: >> >> Hello DSpace Developers, >> >> Per some discussion in yesterday's DevMtg [1], and based on ongoing >> discussions in the DSpace Entities Working Group [2], I would like to ask >> for your feedback on (likely) major enhancement to DSpace's data model in >> the near future. >> >> Simply put, in order to better align DSpace with current needs of >> institutions (especially to better support identifiers and >> author/researcher profiles), we (in the DSpace Entities Working Group) have >> been analyzing ways to enhance the DSpace data model to support additional >> "entities" , namely Authors (but also potentially Organizations and >> Projects). >> >> This is a significant change, as it would be the first new data type >> added to DSpace since it began. *So, before we go much further with this >> effort, I'd really like to hear from *you*, the developers using / building >> / customizing / maintaining DSpace.* >> >> In order to attempt to give everyone an overview of the discussion, and >> an (hopefully) unbiased analysis of our main options, I've drafted up a >> public Google Doc. If you don't like using Google Docs, you are also >> welcome to add thoughts into this email thread. >> >> DSpace Entities Overview / Discussion: >> https://docs.google.com/document/d/1exm_xLToxUMszOvX5itSMFTn5eiGCdggL0Mf522GjHU/edit# >> >> >> *Anyone* can add comments/suggestions to this document (even >> anonymously). I've also added a "Recommendations?" section near the bottom >> where I ask that you consider adding your own personal suggestions / >> recommendations (as a comment). >> >> At this time, this document is written by me (though based heavily on >> many other resources / documents linked to in the text). I attempted to >> give an unbiased lay of the land. But, if you feel anything is >> misrepresented / incorrect / missing, please do add a comment and I'll >> immediately correct it with your recommended changes. >> >> Thanks! I appreciate any time you can devote to reviewing this discussion >> and providing your feedback. Please do let me know if you have questions >> >> Tim >> >> >> [1] http://irclogs.duraspace.org/index.php?date=2018-02-28 >> [2] >> https://wiki.duraspace.org/display/DSPACE/DSpace+Entities+Working+Group >> -- >> Tim Donohue >> Technical Lead for DSpace & DSpaceDirect >> DuraSpace.org | DSpace.org | DSpaceDirect.org >> > -- > You received this message because you are subscribed to the Google Groups > "DSpace Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-devel+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-devel. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- You received this message because you are subscribed to the Google Groups "DSpace Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel+unsubscr...@googlegroups.com. To post to this group, send email to dspace-devel@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-devel. For more options, visit https://groups.google.com/d/optout.
