Jun 11, 2012 at 12:03
Congratulations with a much improved editor!! :)
Here are some comments on the META-SHARE editor on behalf of Meta-Nord/UIB (University of Bergen) and Carla Parra Escartín, who is a resource provider (developer of the TRIS corpus, a Spanish-German parallel corpus being made available through META-SHARE).
All comments are based on the most recent META-SHARE version (v2.1), and we have used the Finnish node:
(I don’t suppose any of our comments below could be somehow specific to the Finnish node, though)
To make it easier for you to refer to each question, we organized our comments as items.
item 1. status for multiple editors of a resource
In a previous discussion,
we have suggested multiple editors for a given resource. META-SHARE replied:
“We have raised an issue to discuss the user management with the technical team. The idea of having a resource owner providing editing rights to other users is very intuitive and probably the one that will be implemented. We will check with the technical team to see how we will solve such problems.”
Any progress on this?
item 2. status for standard attribution text
META-SHARE replied at: http://www.meta-share.org/forum/question/13/0 that you can provide an example of standard Attribution text: "What is envisaged is that we will include an example that will exemplify what the user should input there. This will be visible as guideline together with the element."
We still wait for an example text. We have an internal deadline in META-NORD for the upcoming upload of metadata for batch 2, and it would be great to have a complete description by mid-June. Is it possible?
item 3. language of metadata
If our platform aims at being available for any researcher in the world, the English description should be explicitly mandatory. Currently, the choice of English is only “indicated” by the default language code in the editor for some fields. When clicking on the “information button” for the field specifying language (which leads to the knowledge base), there is nothing in the instructions that tells the user to use English as default. The Knowledge base only explains that “the element can be repeated only if provided in a different language”.
Maybe the languages other than English should be optional to the resource provider? We have discussed this and from our view the metadata description should completely be filled in in English and then we can probably add translations of the schema to other languages as having resources described in several languages will not make the platform really user-friendly and when a particular user is trying to find a resource, (s)he may not have as results valuable resources just because those descriptions were not in English.
Maybe the editor could check automatically that the new field is in another language than English? (or even apply a language recognizer?)
item 4. contact person
We like that the "contact person" is a repeatable element, so you can add more than one.
But if there will be more than one contact persons, maybe it would be a good idea to add a short description of the position/role of the contact person in the project. For instance, if you need information on the resource, maybe the resource creator is the best person to be address, whereas if you need information on the license and there is a contact person specifically for that, it should be stated somewhere.
We agree that the resource and metadata providers are responsible for their metadata records, but we should also not forget that this applies only in the beginning when they are actively involved in making their resources available through META-SHARE. For a long-term perspective, META-SHARE should also have envisaged strategies regarding the validity and up-to-date-status of the resources it has in its database. Maybe resource providers have to confirm once a year that the data for the resource still hold, or there should be a "contract" between META-SHARE and resource owners/providers to guarantee and ensure that any changes will be duly notified? These are just brainstorming ideas that we hope help to improve the platform and the overall project. As we see it, we should not only try to solve problems on-the-fly but rather foresee possible “bottlenecks” and draft some contingency plans.
item 5. Availability end date
We asked about Availability end date (cf. http://www.meta-share.org/forum/question/13/0): how do we express that there is no foreseen end date?
META-SHARE explained that by not using the field you imply that there is no availability end date. This element serves basically the cases where a resource is available for a well defined time period.
We would like to point out that this has still not been explained in the knowledge base: http://metashare.ilsp.gr/knowledgebase/availabilityEndDate
We think it should be explained, to avoid misunderstandings.
Btw, it is actually a good thing to have that for instance to keep track of no longer available resources. This will allow researchers to reference the resources used and if they are not available any more when someone else is trying to trace back that research (s)he will not struggle to find the resource and still be able to at least access a description of it.
item 6. Metadata language name
We asked (http://www.meta-share.org/forum/question/13/0): "As a matter of user-friendliness, would it be possible to offer a scroll-down menu here? We had to spend time Googling the correct code."
META-SHARE response: "You are absolutely right. This issue is currently under development. Values are to be taken from IETF BCP47 standard."
Great! We hope that the current solution in 2.1 is only temporary. In the info box for “Language of this entry”, there are two links:
For the user, it is confusing that there are two links? The first one is rather misleading (all I want is to click and get a list that leads me to my correct language code). From our experience using the v2.1, it is difficult to remember which of the two links to click on. We think it should be a scroll-down menu, and the second link you provide could be used as a reference document in case of doubt.
item 7. Mandatory vs optional fields
Mandatory vs optional fields: it is not clear anywhere in the editor that text in bold means “mandatory” and that plain text means “optional”. This should be clear as soon as a user opens the editor!
item 8. URL confusion
URLs are scattered through the editor, and we have found the intentions of them unclear, as we wonder if they overlap.
The first URL a user will encounter, will normally be the one in the identification component, which has a rather vague explanation:
“A URL used as homepage of an entity (e.g. of a person, organization, resource etc.) and/or where an entity (e.g.LR, document etc.) is located”
Based on this explanation, we might be lead to believe that this is where the download URL comes (we thought so first).
But in fact, the "download location URL" appears later, in the Distribution component!
The user might think, then, that the first-mentioned URL must be a link to a documentation webpage or something, but such a URL also comes under the “Resource documentation” which appears later. Therefore we do not see the point of this first URL, and it needs a much clearer explanation.
By itself, we understand that the URLs are scattered, since the editor is organized as components that contain semantically coherent information). But maybe the knowledge base could group all requested URLs, so that if a user clicks for info on a URL (for instance the first-mentioned, or the "download location" URL) (s)he will immediately get an overview of which URLs will become available in the different components in the editor.
item 9. download location
In some cases, the resource is not directly downloadable because of certain user restrictions, or maybe the resource is only located on somebody’s personal computer. Can META-SHARE assist providers in making such resources available on a server?
(since sometimes the researcher does want to share a resource, but has no clue where to put it)
item 10. Editing information about existing persons and existing projects
We appreciate the lists of persons and projects, which saves us the effort of filling in data about the same person more than once! :)
But it is not clear to us how to update/merge records.
For instance, Carla Parra appears five times in the list of persons (in the UHEL node: http://metashare.csc.fi/), Arne Lindstad appears seven times! From the limited information in the list, it looks as if all entries are OK, and we have no way of finding how they differ and which one to choose.
10 a. We do not see how to merge/edit/correct this. We could do it for you, but how?
10 b. And since we have filled in metadata for many resources already: could the person info be updated automatically (or with the click of a button) for all records?
10 c. The same applies for projects: Currently we can only see the name of the project. How can we see the information already provided by previous users about that project, and eventually add details/edit information?
10 d. Have you given any thoughts to who is authorized to change such information? In the case of a person, the person him/herself could be authorized. In the case of a project, somebody should control that the information provided is correct.
We see the problem that it is not possible to make automatic validations of duplicates. In a previous discussion (http://www.meta-share.org/forum/question/13/0), META-SHARE commented that one could merge “similar” person and organization names but that in that case we should think how to decide on the correct value, especially since the values may come from different persons.
We think that maybe a master user account could be created for the people responsible in each country. From our perspective it would not be a huge work load to filter out which resources have for instance the erroneous values such as "University in Bergen" and replace it with "University of Bergen" before deleting the wrong name and updating the list.
Another solution could be that every time a new value is added by a user someone in META-SHARE “validates” it to avoid spelling errors, etc. but this solution might be more demanding than filtering similar values periodically and doing some routines before merging them etc.
item 11. Warn the user that their session is about to expire
In a previous discussion (http://www.meta-share.org/forum/question/13/0) we suggested that it might be a good idea to warn the user that their session is about to expire so that data are not lost. Otherwise, there should be an automatic save function to prevent these things.
META-SHARE replied that they would check it with the technical team to see why this is happening and they would let us know.
Any development on this issue? We don’t think it should be too difficult to implement something similar to what we suggested.
item 12. Allow to save and quit at any time for internal (still unpublished) records
We support that the required data (the minimal schema) must be filled in prior to publishing a resource.
But it should be possible to save what has been filled in so far, even if the minimal schema is still incomplete, to avoid user complaints about lack of user-friendliness and loss of data (this can be really annoying from a user perspective. And yes, we lost data..;).
Sometimes people cooperate in filling in metadata (for instance, META-NORD/UIB fills in metadata in cooperation with Carla for the TRIS resource, and it may happen that we don’t know all the necessary information right away.)
In a previous reply, META-SHARE state that
“To avoid ending up with many incomplete metadata records, the user has to fill in all the required fields that correspond to the minimal metadata schema and then he/she is able to quit. Please keep in mind that you can use the “save and continue editing” button, in order to temporarily save the fields you have filled in.”
Our point is that as long as a metadata record is internal (i.e. unpublished), there is no reason to require that all the mandatory fields are complete before saving and trying to leave the page.
Currently, if you click on “save and continue editing”, without all the mandatory fields having been filled in, the record is actually not saved!
What about having an intermediate solution in which the user is given for instance 24/48 hours to complete the required fields and otherwise the data are lost? We think this is possible from a technical perspective. Or maybe it could also be nice to have an offline version that allows you to prepare all the metadata and then upload the finished metadata descriptions for publication.
Besides, the user should be warned about this in a clear way (whatever decision is taken) to avoid any misunderstandings and complaints.
I hope you find this useful, best regards from
Carla & Gunn
Re. Item 2 (Attribution)
There is no standard attribution statement. It depends on the objectives of the licensor and the creator of the work. This LR has been created by <creator's name AND/ OR URL > and is licensed by <licensor's name AND / OR URL > under a <licence name AND/ OR licence URL > Please let me know should you need any additional clarifications.
on behalf of the MetaShare Legal Helpdesk
Hi, Gunn here.
Concerning item 10: Editing information about existing persons and existing projects:
I finally discovered that I can click Update > Person or Update > Organization.
I love to see that by Updating my Person info here, this is automatically updated in all the records where I used this "person template" - well done!! :)
Various answers coming up:
Item 1. multiple editors
The issue of multiple editors for the same resource has been raised up with the technical team in the general framework of user management. Various shortcomings have been identified, mainly related to the fact that one editor may undo what another editor is doing.
For the time being, what we do at ILSP while editing metadata records is that one person is assigned the metadata record for a specific resource and he/she edits it after getting information from the various people. Once the record is finished, he/she invites the responsible people to check it and he/she makes the corrections.
Item 3. language of metadata
This is already under implementation for version 3.
Item 4. contact person
Role assignment for contact persons has been discussed but we think it might be too heavy. Being a contact person doesn't mean that one must know everything; it's the focal point (person or, in some cases, even just an email address) for addressing questions; if he/she does not know something, he/she knows to whom the request should be forwarded. Please, note also that for licensing, it is more appropriate to use the "licensor".
As for the maintentance of metadata records, indeed there are such clauses in the MoU/Charter/Depositors' Agreement (depending on relation to METANET and position in network) that each LR provider will sign when entering META-SHARE, so this need not be re-stated every year; it is considered part of their obligations.
Item 5: Availability end date
Thanx for pointing it out again; we're currently revisiting the documentation and will edit such points.
Item 6. metadata language name
Language id & name (in whichever element these appear) will be updated in version 3, so that the users use a user-friendly menu to select the appropriate language.
Item 7. Mandatory vs. optional fields
There will be a general stylistic redesign of the editor to improve the user friendliness; if time permits, this will be integrated in v3.
Item 8. URL confusion
Same reply as for item 5.
Item 9. download location
There is a facility for uploading the resource: it's in the editor, at the upper menu while viewing a metadata record (together with options for exporting the metadata description etc.).
Please note that we also intend to provide documentation for people that wish to share their resources through META-SHARE with step-by-step guidelines for doing so (soon!). And with more guidelines on using the editor itself!
Item 10. editing information about existing persons ...
Ok, you've seen how you can edit an existing entity. I suppose the fact that you cannot delete them has to do with the rights assigned to your account by the administrator; so, for that please contact him/her.
Currently, it's not possible to merge existing records (e.g. the various records for the university of Bergen). And it's not even easy to decide who will do this: we've had long talks on this and no satisfactory solution has come up. Even for persons, there can be records for persons who have now left the organization, so they cannot be responsible for their own metadata. Still, this is an issue still under discussion.
So, what we do at ILSP for near-duplicates (exact duplicates are filtered out by the s/w), is that we correct one of them, delete the rest of the records, and then re-link all the resources with the correct record. This is not the best way to do it but we try to gain time until we have a better solution.
Item 12. Allow to save and quit
Issue under discussion.
Thanx again for all the comments,
the discussion of item 11 (session timeout) has moved over to our technical issue tracker at https://github.com/metashare/META-SHARE/issues/315. Could you please drop by and help us with some answers there?