StocksAndFisheriesKB

Thanks for this Costantino. Based on the information in the description. Let me know if it does make sense to use the following object as a request.

{
    "catalog_id": "...",
    "knowledge_base_id": "...",
    "old_status": "...",
    "new_status": "...",
    "annotation_message": "...",
    "short_name_old": "...",
    "short_name_new": "...",
    "traceability_flag": true/false,
    "administrator_name": "...",
    "similar_grsf_records": [{
        "knowledge_base_id": "...",
        "merge": true/false
    }]"connections": [{
        "source_knowledge_base_id": "...",
        "dest_knowledge_base_id": "...",
        "source_domain": "..." 
    }]
}

and the response remains unchanged. i.e.

{
    "catalog_id": "...",
    "knowledge_base_id": "...",
    "new_status": "...",
    "short_name_new": "...",
    "update_result": true/false,
    "error_message": "..." 
}

Furthermore, as regards merging, we could do the following. As soon as there are records to be merged, I can re-publish them with a new status type that you will use as a flag for annotating the records as a record to be merged.

The status could be "to_be_merged". This means that when we republish a record that will be merged it will contain this status and then the publisher service could identify (from the status) that this record will be merged and you will annotate it in a proper way in the catalog.

Let me know.

Yannis Marketakis wrote:

Thanks for this Costantino. Based on the information in the description. Let me know if it does make sense to use the following object as a request.

{
    "catalog_id": "...",
    "knowledge_base_id": "...",
    "old_status": "...",
    "new_status": "...",
    "annotation_message": "...",
    "short_name_old": "...",
    "short_name_new": "...",
    "traceability_flag": true/false,
    "administrator_name": "...",
    "similar_grsf_records": [{
        "knowledge_base_id": "...",
        "merge": true/false
    }]"connections": [{
        "source_knowledge_base_id": "...",
        "dest_knowledge_base_id": "...",
        "source_domain": "..." 
    }]
}

and the response remains unchanged. i.e.

{
    "catalog_id": "...",
    "knowledge_base_id": "...",
    "new_status": "...",
    "short_name_new": "...",
    "update_result": true/false,
    "error_message": "..." 
}

Yep Yannis, it seems ok to me.

Let me just clarify if I got it right with the "connections": once an admin connects a record, there is no way to remove such connection. Is this right?

Yannis Marketakis wrote:

Furthermore, as regards merging, we could do the following. As soon as there are records to be merged, I can re-publish them with a new status type that you will use as a flag for annotating the records as a record to be merged.

The status could be "to_be_merged". This means that when we republish a record that will be merged it will contain this status and then the publisher service could identify (from the status) that this record will be merged and you will annotate it in a proper way in the catalog.

Let me know.

Also this sounds ok to me. I'm just wondering about the involved records. For instance, I'm working on record A and I suggest to merge it with record B. We update both records and mark them as "to_be_merged"; that's fine. The management panel cannot be opened to perform other operations but the revert one (I still need to figure out how I can do it). Now, let's suppose I open record C and I suggest a merge of this record with either B or A (or both): is this allowed? I guess so

Costantino Perciante wrote:

Let me just clarify if I got it right with the "connections": once an admin connects a record, there is no way to remove such connection. Is this right?

I think @aureliano.gentile@fao.org should answer this (if we want to add/remove connections). From the service perspective, I just suggest submitting always the list of connections (so if there are connections to be removed they will simply be absent from the submitted json request).

Costantino Perciante wrote:

Also this sounds ok to me. I'm just wondering about the involved records. For instance, I'm working on record A and I suggest to merge it with record B. We update both records and mark them as "to_be_merged"; that's fine. The management panel cannot be opened to perform other operations but the revert one (I still need to figure out how I can do it). Now, let's suppose I open record C and I suggest a merge of this record with either B or A (or both): is this allowed? I guess so

IMHO, we should somehow prevent merging records that have not been actually merged (i.e. they are in status to be merged).

1) connect records and merge records are two different actions; 2) both actions performed by the management panel should be revertible; 3) merged records and connected records are displayed/referenced also in the GRSF sheet, the merged ones in the data source box, the connected ones in a dedicate field next to the similar records.

Thanks for your feedback. I see, but If I'm not wrong we said the all actions but merges do have immediate effects. This means that if one just suggests connections, then the records will be updated immediately. Does the "remove connection" facility still make sense here?

However, I guess it is better to discuss about the workflow in a telco (I will send an email to schedule a date for it)

Costantino Perciante wrote:

To be implemented:

• about Connections:
  • The KB suggests potential connections through Exploiting Fisheries and Resources Exploited fields (in a stock record and fishery record respectively). It puts there the urls in the catalogue of these records;
  • initially the administrator can "Connect" one or more of the suggested records. This means that these will be moved into another field, i.e. "Connected Records";
  • From there the "Connected Records" can be either unconnect (the url is put back into the Exploited field) or "Removed"(see note 2); ... 2) The connections field accepted by the grsf-updater service from FORTH now looks like:

"connections": [{
        "source_knowledge_base_id": "...",
        "dest_knowledge_base_id": "...",
        "source_domain": "..." 
    }]

We should change it a bit. Something like this may work:

"connections": [{
        "source_knowledge_base_id": "...",
        "dest_knowledge_base_id": "...",
        "source_domain": "...",
        "remove" : true/false
    }]

"Remove" allows to completely remove the record among the connected ones (and it is not put back into the Exploited field). The management panel will NOT send the connections to be "unconnect" (in this case their urls are put back into the Exploited field)

Moreover, the object accepted by the grsf-publisher is still:

"connected": [{
        "semantic_identifier": "...",
        "short_name": "...",
        "knowledge_base_id": "..."
    }]

@aureliano.gentile@fao.org could you check if the above steps are correct/make sense?

looks good as proposed.
Regarding rejecting a GRSF record merged from two sources: this means that the GRSF rejected record is deleted and the two sources goes back to generate two distinct NEW GRSF records (or back to the formers) in pending status for being re-analyzed and approved/re-merged.

@minadakn@ics.forth.gr @costantino.perciante@isti.cnr.it Please confirm such understanding.

Aureliano Gentile wrote:

looks good as proposed.
Regarding rejecting a GRSF record merged from two sources: this means that the GRSF rejected record is deleted and the two sources goes back to generate two distinct NEW GRSF records (or back to the formers) in pending status for being re-analyzed and approved/re-merged.

@minadakn@ics.forth.gr @costantino.perciante@isti.cnr.it Please confirm such understanding.

Yes, this is what I understood.
@marketak@ics.forth.gr and @minadakn@ics.forth.gr since the dissect requires 24 hours as well, we should add a new temporary status for a record born from a merge but rejected. Does "To be dissected" sound good to you?

As we discussed yesterday with @aureliano.gentile@fao.org the rejected merged records will be re published not after 24 hours but when the periodical refreshing of the GRSF will take place (one per two weeks for example). So imagine GRSF record A that has been merged from GRSF B ( that comes from source record S1) and GRSF C (that comes from source record S2) then by rejecting this merging the GRSF record is being deleted directly and at the reconstruction of the GRSF KB the records S1 and S2 will produced again GRSF B and GRSF C. So there is no need for flagging or doing anything else.

Nikos Minadakis wrote:

As we discussed yesterday with @aureliano.gentile@fao.org the rejected merged records will be re published not after 24 hours but when the periodical refreshing of the GRSF will take place (one per two weeks for example). So imagine GRSF record A that has been merged from GRSF B ( that comes from source record S1) and GRSF C (that comes from source record S2) then by rejecting this merging the GRSF record is being deleted directly and at the reconstruction of the GRSF KB the records S1 and S2 will produced again GRSF B and GRSF C. So there is no need for flagging or doing anything else.

This means that there is no way of reverting the operation, doesn't it? If the administrator rejects the record, then he/she cannot say "no, I was wrong, please ignore this operation" later on

please @costantino.perciante@isti.cnr.it reassign the ticket to the person responsible for this component from tomorrow.