GSoC-2017 OCL Project Discussion

Projects Open Concept Lab
1

Hi all, We’re really excited that Xu Hao (@hao555sky) is working on OCL this summer as part of GSoC 2017. Here’s the link to the original project proposal:

https://wiki.openmrs.org/display/projects/Open+Concept+Lab+enhancements

We’ll use this for discussions about the project.

Jon

1 Like
2

Hi @hao555sky,

Thanks for your message! I’m moving your questions over to a public forum so that others can feed in:

1. How do we want to support “forking” concepts?

Here’s an idea for starting simple with forking concepts: Concept 123 from Repository A (A:123) is “forked” into Repository B by creating a duplicate of A:123 and any mappings that originate from A:123 that are also stored in Repository A into Repository B. Additionally, a new mapping is created in Repository B with “from_concept”=B:123, “map_type”=Forked From, “to_concept”=A:123

@darius @raff @akanter @burke @ball – What do you think of this concept “forking” approach? I’m worried about licensing/copyright issues with this approach. Would we want to restrict this behavior to the owner of the concept?

2. How do User Permissions work?

  • Owners
    • Users - All user profiles can be viewed by authenticated users; a user profile may only be edited by the owner of the profile; user’s may be members of organizations
    • Organizations - To view an organization, you must be authenticated; if the org’s “public_access” field is set to “View”, then anyone can view the organization, if it is “None”, then only members of the org can view it; a user may edit the organization details if it is a member of the organization
  • Repositories: Sources/Collections - If a repository’s “public_access” field is set to “View”, then anyone can view the repository; if “public_access”=“None”, then only an “owner” or member of the “org owner” can view it; a user may edit the repository details if it is an “owner” or if it is a member of the “org owner”; anyone can edit the repository if “public_access”=“None” (though probably no good reason to do this)
  • Concepts/Mappings - permissions for concepts/mappings are inherited from the repository

3. Should Organizations in Django Admin be throwing a NotImplementedError?

Yes, that is actually correct, though not what we would like! Our original developer implemented a custom “organization” object rather than extend the built-in django “Organization” object from the admin panel. If we stay with Django long-term, then we would probably switch eventually to using the built-in django “organization” object.

-Jon

3

I thought the primary use case of forking concepts is when you are not the owner. E.g. CIEL publishes a concept with 3 answers, but in my implementation I want a custom 4th answer, so I fork the CIEL concept.

If we want to support a licensing/copyright model where you don’t allow people to fork your concepts in OCL then I think we should add this as an attribute at the source level, where you opt-in or opt-out of letting your concepts be forked. (I assume that copyright/license is at the source level.)

I don’t think it’s enough to know which concept you’re forked from: you also need to know which specific concept version was forked. That will let us (eventually) do some sort of merging and conflict resolution.

Also, I would tend to make this a top-level attribute of a concept (instead of a mapping), because in the future we’re going to want to write code against this (e.g. when comparing/merging).

1 Like
4

I have an immature idea.

  1. At first, we should know who can fork and what the fork will do. Condition 1: A user who is a member of this organization wants to edit a concept, he can edit this concept directly, not fork. If he is not a member of organization, then he can fork it, and modify. Condition 2: A user wants to add another meaning of a concept, like above, if he is a member of this organization, he can edit directly, not fork. If he is not, then he can fork and modify, then create pull request.
  1. About concept version, sorry to @darius, maybe I have another thoughts. I don’t think we need to know which concept version was forked. In my opinion, just latest version concept can be forked.
  1. About licensing/copyright issue, I am not familiar, so I do not comment.

Please excuse me if I say something wrong.

Thank you.

Hao

5

I agree that the most important use case is to fork the latest version.

I mean that when this forking happens we should record which version is forked. That way in the future we can look back and determine what changes have been made to the original and to the fork, since the forking happened, and potentially merge these.

(I would only support forking the latest version in the UI, but I would probably have the underlying API support forking from any concept version.)

6

“Forking” should not be confused with “Editing”. Simply editing a concept follows the rules/permissions I described in my message above.

“Forking” is when you want to create a copy of a concept, usually because you want to update it without affecting the original concept. There are definitely reasons when a user may want to create a copy of a concept to a different source within the same organization. There are other reasons a user may want to create a copy to a source in a different organization.

I agree with @darius: Let’s use a concept-level attribute to store which version of a concept it was forked from, rather than a mapping. And we definitely do want to store the original concept version, not just the concept, so that we can do conflict resolution and merging in the future (like Darius said).

Also, agree that we should use a source-level attribute to control permissions for forking.

Finally, API should allow forking from any version of a concept. UI encourages use of the latest version of a concept, but I don’t see any reason for us to prevent forking of a previous version if the user has already navigated to an older version of a concept.

@hao555sky: Could you write a short proposal for how you want to approach concept forking and post here so that we can review? Thanks!

Jon

7

Hi, @paynejd, @darius I am not good at proposal because I almost never wrote except GSoC proposal. So please tell me if there is any error in it.

proposal

objective

Fork This Concept

Description

User can fork this concept if he/she wants to edit it. Like the way that forking in github

How

Concept structure in data dictionary:

organization/user → source → concept

According to everyone’s thoughts, I think

  • If we want to fork a concept like orgA/sourceA/conceptA, we should create a copy of all structure in user’s space, like userA/sourceA/conceptA.
  • Some new attributes to store additional information. Like from_concept, to_concept, map_type, version.
  • Add a new attribute of concept to manage the permission for forking.
  • Redirect to the new concept when forking ends.

So we need API:

  • get concept and source information, like detail, mapping and so on, but the new concept’s history is empty.
  • create source and concept which is same with original version in destination
  • create some new attributes to store additional information

Thank you.

Hao

8

Thanks Hao! Some revisions to your approach:

  • If a user wants to fork a orgA/sourceA/conceptA, then the user must select which existing source that they want the concept to be copied into. We should not create a new org/source structure for it.
  • The user should have the opportunity to change the concept ID of the forked concept before it is actually created (because you can’t change the ID of a concept after it has been created)
  • The relative url of the original concept version should be stored in an attribute of the forked concept — “fork_source_url”: “/orgs/orgA/sources/sourceA/concepts/conceptA/conceptAversionId/”
  • Add a new attribute to the source object to manage the permissions for forking – e.g. “allow_forking”: “True” or “False”
  • Redirect to the new concept when forking ends.

Regarding the API, I would recommend taking a look at other REST APIs and proposing a specification based on that. Here is the GitHub API for forking: https://developer.github.com/v3/repos/forks/#create-a-fork

This is also a good place for @darius and @raff to feed in – ideas for a RESTful approach to forking/copying a concept into a different repository?

Thanks, Jon

9

Hi, everyone

I have created a separate google doc to discuss the first task “Fork This Concept”. Looking forward to your suggestions. @paynejd @ball @raff @darius @akanter @burke

The google doc link is: https://docs.google.com/document/d/1jOOjVfIsDbgD1Z3frE6cQDcurmSk_jlgxQJqXqkDYw8/edit?usp=sharing

Thanks

Hao