Change Details

This is about creating a proof of concept of the solution that would allow to use the "universal" statement-editing API wbsetclaim to edit statements of Forms. This is about an approach where Forms are not EntityDocuments, and FormIds are not EntityIds. Doing this would most likely include: - getting all data needed from the API input. This would include: ID of the lexeme to be worked on. ID of the form in question. ID of the statement/claim - generating a ChangeOp that would be applied on the Lexeme entity, and do the desired change, to the needed form of this Lexeme. - making it possible to use/inject/etc WikibaseLexeme-specific code in wbsetclaim. This is probably not the last step, but something which wraps the whole work involved here. This is about the backend code only. It seems that making UI work with the API to be able to edit statements of Forms does not require investigation, and is rather generic and fairly straightforward problem. The result of this investigation should not be code covering all cases. It should allow though to assess whether the "Form is not an Entity" approach is applicable in this case, or is it make it all so cumbersome, that should not be used. Also as the result of the investigation are places that need to be handle for new kinds of "entities" (forms, senses), e.g. "parsing" API input, ChangeOps, generating API response, error handling, generating edit summaries, etc should be recognized. As a result of the investigation, we are going to be ready to decide on the details of the implementation, and the actual implementation will follow shortly * Timebox: 4 hours * Outcome:

This is about creating a proof of concept of the solution that would allow to use the "universal" statement-editing API wbsetclaim to edit statements of Forms. This is about an approach where Forms are not EntityDocuments, and FormIds are not EntityIds. Doing this would most likely include: - getting all data needed from the API input. This would include: ID of the lexeme to be worked on. ID of the form in question. ID of the statement/claim - generating a ChangeOp that would be applied on the Lexeme entity, and do the desired change, to the needed form of this Lexeme. - making it possible to use/inject/etc WikibaseLexeme-specific code in wbsetclaim. This is probably not the last step, but something which wraps the whole work involved here. This is about the backend code only. It seems that making UI work with the API to be able to edit statements of Forms does not require investigation, and is rather generic and fairly straightforward problem. The result of this investigation should not be code covering all cases. It should allow though to assess whether the "Form is not an Entity" approach is applicable in this case, or is it make it all so cumbersome, that should not be used. Also as the result of the investigation are places that need to be handle for new kinds of "entities" (forms, senses), e.g. "parsing" API input, ChangeOps, generating API response, error handling, generating edit summaries, etc should be recognized. As a result of the investigation, we are going to be ready to decide on the details of the implementation, and the actual implementation will follow shortly * Timebox: 4 hours * Outcome: Presentation and evaluation of results

This is about creating a proof of concept of the solution that would allow to use the "universal" statement-editing API wbsetclaim to edit statements of Forms. This is about an approach where Forms are not EntityDocuments, and FormIds are not EntityIds. Doing this would most likely include: - getting all data needed from the API input. This would include: ID of the lexeme to be worked on. ID of the form in question. ID of the statement/claim - generating a ChangeOp that would be applied on the Lexeme entity, and do the desired change, to the needed form of this Lexeme. - making it possible to use/inject/etc WikibaseLexeme-specific code in wbsetclaim. This is probably not the last step, but something which wraps the whole work involved here. This is about the backend code only. It seems that making UI work with the API to be able to edit statements of Forms does not require investigation, and is rather generic and fairly straightforward problem. The result of this investigation should not be code covering all cases. It should allow though to assess whether the "Form is not an Entity" approach is applicable in this case, or is it make it all so cumbersome, that should not be used. Also as the result of the investigation are places that need to be handle for new kinds of "entities" (forms, senses), e.g. "parsing" API input, ChangeOps, generating API response, error handling, generating edit summaries, etc should be recognized. As a result of the investigation, we are going to be ready to decide on the details of the implementation, and the actual implementation will follow shortly * Timebox: 4 hours * Outcome: Presentation and evaluation of results