Closed mrpatrickwest closed 8 years ago
Be very careful with ths one, Grasshopper...there is a ton of functionality that relies esp on communities working correctly...
On Monday, August 10, 2015, Patrick West notifications@github.com wrote:
seems they should be foaf:Group
dco:PortalGroup a owl:Class ; rdfs:label "Portal Group"@en-US ; rdfs:subClassOf foaf:Organization , owl:Thing , foaf:Agent , dco:Object ; owl:equivalentClass dco:PortalGroup .
dco:ResearchCommunity a owl:Class ; rdfs:label "Research Community"@en-US ; rdfs:subClassOf vivo:ResearchOrganization , foaf:Organization , owl:Thing , foaf:Agent , dco:Object ; owl:equivalentClass dco:ResearchCommunity .
— Reply to this email directly or view it on GitHub https://github.com/tetherless-world/dco-ontology/issues/25.
John S. Erickson, Ph.D. Director of Operations, The Rensselaer IDEA Deputy Director, Web Science Research Center (RPI) http://tw.rpi.edu erickj4@rpi.edu Twitter & Skype: olyerickson
I agree with Patrick that research communities and portal groups are not organizations and should be represented in the ontology as groups.
Let's enumerate on the functionality within VIVO related to these groups so we can thoroughly test any changes.
One of the reasons (I believe) we considered what we now call DCO Communities to be organizations was, originally they were a sub-part of the greater DCO organizational structure known as a directorate. They've always had a consistent structure, having co-directors and scientific steering committees. So, in my view they are organizations.
If you feel they are groups, that's great, but the Colin Powell Principle applies ;)
On Tuesday, August 11, 2015, Stephan Zednik notifications@github.com wrote:
I agree with Patrick that research communities and portal groups are not organizations and should be represented in the ontology as groups.
Let's enumerate on the functionality within VIVO related to these groups so we can thoroughly test any changes.
— Reply to this email directly or view it on GitHub https://github.com/tetherless-world/dco-ontology/issues/25#issuecomment-130070043 .
John S. Erickson, Ph.D. Director of Operations, The Rensselaer IDEA Deputy Director, Web Science Research Center (RPI) http://tw.rpi.edu erickj4@rpi.edu Twitter & Skype: olyerickson
I am not sure what Colin Powell principle you are referring to.
As for research communities and portal groups. Research communities are not structured and the membership does not generally hold positions. I think research communities are foaf groups. No one works for or at a research community.
Portal groups are... wait for it... foaf groups! It's in the name. At best if we want to be more specific we can call them a vivo:Team (subclass of foaf:Group, defintion: A group of people working together.)
Perhaps the best way to proceed is to define what the desired behavior is for different classes within the VIVO application and then classify these entities based on that behavior. The reason I think this matters is so that groups/organizations/teams/etc show up in the application in the expected places and the application allows only the desired behaviors on them.
Right now there are multiple entities for engagement (a portal group, two organizations, a team, a skos concept, and a research community). New users were allowed to select engagement as their research community because of the mis-classification - and it is only because of an explicit filter on the query used to populate the form that it is no longer a selectable option (i.e. we didn't fix the classification, we put duct tape on the form). Right now any user can update their profile to say that they are a member of engagement, and we don't currently have a means to prevent them from doing that. We have no way to control membership in groups/teams such as secretariat, engagement, or data science except to discover when the membership is wrong and manually fix it.
If we clearly define what it means to be an organization, a team, a group, etc. within the VIVO application we can attempt to configure the application to support the desired behavior.
Pros:
This was resolved as part of the team/community/organization changes
seems they should be foaf:Group