Comments (14)
Overall I think that this is a good idea however I'm not so sure it is a good idea to allow changes to the project settings after indexing has taken place. I discussed this with @bug-rancher and @virdiignis and we'd rather stay on the safe side when it comes down to modify project settings (for now).
from collaborative-platform.
There are three different topics here:
- Specifying the number and type of the taxonomy categories and TEI entities.
- Specifying the color and icons used for the taxonomy categories and TEI entities.
- The moment and scope of specifying these settings.
I propose setting all of them upon project creation, and then allow per user tweaking
of the colors and icons for the entities.
from collaborative-platform.
Please read this proposition for this issue before the tomorrow cal:l
https://docs.google.com/document/d/1X4b4EMl1wzyZ_-c6uTJ2EkT_36ODCUJeEp-sOJzECNQ/edit
We can talk about it tomorrow.
from collaborative-platform.
Today I started work on this issue in flexible_taxonomy branch. I will work on that and related issues regaring API endpoints tommorow.
@Janchorizo I need you to change front-end, so the load to the project create endpoint looks like below:
{
"taxonomy": [
{
"name": "ignorance",
"color": "#FF00FF",
"icon": "",
"description": "Category desc."
},
{
"name": "imprecision",
"color": "#00FF00",
"icon": "",
"description": "Category desc."
}
],
"entities": [
{
"name": "Person",
"color": "#FFFFFF",
"icon": "",
"properties": {
"attributes": [
"sex", "age", "role"
],
"sub-elements": [
"persName", "birth", "death"
]
}
},
{
"name": "Ingredient",
"color": "#A0A0A0",
"icon": "",
"properties": {}
}
]
}
Tommorow I will expose default values for that lists in the same format as an endpoint. Also please write here what should I put in icon and color fields for default entities. You're welcome to do changes in the same branch. We'll only merge it after all changes are done.
@michalkozak should I include all available (by the TEI docs) properties, or some subset of those? If latter, also write it down and post here please.
Best regards,
from collaborative-platform.
This was discussed in the dev channel, and a different approach explained in issue #86 .
Basically, users should not have to deal with TEI properties as the only action to do at
project creation is removing some properties which they can nonetheless omit when annotating.
Therefore properties should be shown (for clarity and informative reasons), but maybe we
omit them in the project creation message payload.
from collaborative-platform.
The default values that I show at project creation are the following:
"date": {"icon": "\\f073", "color": "#868788" },
"event": {"icon": "\\f274", "color": "#cecece" },
"location": {"icon": "\\f5a0", "color": "#ff6464" },
"geolocation": {"icon": "\\f5a0", "color": "#ff6464" },
"occupation": {"icon": "\\f0b1", "color": "#3c8745" },
"object": {"icon": "\\f466", "color": "#b4d38d" },
"org": {"icon": "\\f1ad", "color": "#b4edfc" },
"person": {"icon": "\\f007", "color": "#ff7f00" },
"place": {"icon": "\\f279", "color": "#204191" },
"placeName": {"icon": "\\f279", "color": "#204191" },
"country": {"icon": "\\f279", "color": "#204191" },
"time": {"icon": "\\f017", "color": "#eab9e4" },
"ingredient": {"icon": "\uf787", "color": "#395b50" },
"productionMethod": {"icon": "\\f542", "color": "#291528" },
"utensil": {"icon": "\uf6e3", "color": "#96031a" },
from collaborative-platform.
Therefore properties should be shown (for clarity and informative reasons), but maybe we
omit them in the project creation message payload.
It's easier for me if I have them in the payload – I won't have to guess which entities are default and which are added by the user. I will pass those values to front by different endpoint, so you'll just have to send them back to me along with names, icons and colors.
from collaborative-platform.
@virdiignis You shouldn't require in the API the structure of properties:
"properties": {
"attributes": [
"sex", "age", "role"
],
"sub-elements": [
"persName", "birth", "death"
]
}
This is a matter of logic in backend how to deal with these properties. Some of them are attributes of the entity, some are subelements of entity, but very often these are attributes or subelements of subelements. We shouldn't expose in API the structure of properties in TEI. Moreover in #85 I listed properties for each entity. There is no persName
, but forename
and surname
.
from collaborative-platform.
Ok, so @Janchorizo let's omit properties in the payload. We'll handle this on backend.
from collaborative-platform.
I am currently working on another task, but will try to make some time this morning and push the changes so that you can test you code with the new project settings ui.
Do I understand it well that both the entities and taxonomy may have an arbitrary (but not zero)
amount of elements?
from collaborative-platform.
Do I understand it well that both the entities and taxonomy may have an arbitrary (but not zero)
amount of elements?
That's correct.
from collaborative-platform.
I have some few last suggestions regarding the payload for project creation.
TEI does have location entities, as it does have geolocation and similar ones. Even if we handle
geolocation as an attribute of the first, there is the possibility of getting a TEI file with geolocation
and country entities.
I think giving the entities alias would facilitate handling them, as we could handle geolocation,
country, place and location entities as the same one.
Another issue I find with the current proposal is that it does not handle the use case for specifying
which entity lists will be present in the body and which in the header.
from collaborative-platform.
Let's just add "body_list": true/false to payload.
from collaborative-platform.
So, in the end format would be:
{
"taxonomy": [
{
"name": "ignorance",
"color": "#FF00FF",
"icon": "",
"description": "Category desc."
},
{
"name": "imprecision",
"color": "#00FF00",
"icon": "",
"description": "Category desc."
}
],
"entities": [
{
"name": "Person",
"color": "#FFFFFF",
"icon": "",
"body_list": false,
}
},
{
"name": "Ingredient",
"color": "#A0A0A0",
"icon": "",
"body_list": true,
}
]
}
from collaborative-platform.
Related Issues (20)
- Missing the ability to add uncertainty to the text, without creating an entity
- A request that adds uncertainty to the text fragment that is a reference to an entity has an incorrect value
- Missing the ability to add uncertainty to reference to entity
- Missing the ability to add uncertainty to another uncertainty
- Wrong "start_pos" in request for already tagged text
- "Text fragment" in "Entity type" drop-down list in Annotator
- Uploading csv or txt does not show error message (server throws 500)
- Alex's error on the annotator HOT 1
- Show the degree attribute to the user HOT 1
- Move lists of entities to the one dedicated element in TEI HOT 4
- Replace the ab tag with the seg tag HOT 4
- Text longer than 1 word in Asserted Value must be wprapped in a separate tag HOT 1
- Object name must be embeded in more complex structure HOT 1
- `start_pos` and `end_pos` are equal in request in Annotator HOT 1
- The annotator fails to annotate HOT 1
- Entities and annotations are not preserved upon upload HOT 4
- In Annotator, after adding entity, interface disappear. HOT 4
- Postgres: Name or service not known HOT 1
- Adding uncertainty to a new entity property sends an invalid request
- Adding uncertainty to text sends an invalid request
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from collaborative-platform.