Open mrivoal opened 5 years ago
I think you'll need to discuss this with @tobiasschweizer, who is on holiday, so please be patient.
Does this mainly affect SALSAH 1.5?
Since there is no alternative to edit data at the moment, yes.
But since it make take some time until there is a viable standoff editor in Knora-app, I think it could/should also affect Knora-app.
I think it could/should also affect Knora-app.
Are you solely referring to the GUI or do you think there are requirements affecting the Knora API?
I am referring to the GUI. I couldn't say if some of these requirements would affect the current Knora API.
This possibly will?
we could possibly use the
salsah-gui-guiAttributeproperty
to link aTextValue
property to the right standoff mapping
If you create or modify a TextValue
, a mapping has to be indicated. In the simplest case, an existing mapping can be used. Otherwise a new mapping has to be created first and then be indicated.
Yes, the idea here is that they would indicate the right (project-specific) mapping (which won't be the standard mapping) in the ontology itself for a given TextValue
.
issue moved to DSP-1219
After a discussion with @lrosenth and @subotic, here is an issue based on a use case we have : a project would like to submit and update a text (TEI-XML) in Knora using a graphic interface.
The corpus: 1000 to 1200 texts, ranging from one paragraph to 40 pages, with 10-15 tags
The workflow:
What we think we need in Knora:
salsah-gui:guielement
, similar toRichtext
, but not enforcing the choice of the standard mappingsalsah-gui-guiAttribute
property to link aTextValue
property to the right standoff mapping, such as: