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.

Reply via email to