Additional fields advanced search

[prakhyatox]

Ticket: https://github.com/FAIRsharing/fairsharing.github.io/issues/2353

Adding additional fields to advanced search

[allysonlister]

Could you check with @knirirr and/or @ramGranell to see if there's any way to use tooltips that already exist for the Edit UI for databases and policies, as these will all have tooltips, and you might just be able to use them directly.

e.g. see Additional information tab in https://fairsharing.org/1998/edit

[ramGranell]

The description of the field (tooltip) can be found in the field "description " of the schema fields that are in the server repository. e.g. /lib/record_schemas/database_schema.json contain the specific fields for the databases. They are used in the edit code in this way https://github.com/FAIRsharing/fairsharing.github.io/blob/master/src/components/Editor/AdditionalInformation/EditAdditionalInfo.vue#L47

[allysonlister]

Thank you! Everything seems to be functioning, and I am happy with the tooltips :-)

Updates to pulldown labels:

• Recommends At Least One Database instead of Recommends Database
• Recommends At Least One Standard instead of Recommends Standard
• "Mandated DMP Creation" instead of "Mandated Dmp Creation"
• Updating of DMP instead of Updating of Dmp

However, I am wondering (and I would very much like @delphinedauga's thoughts here) about the boolean pulldown, now that all pulldowns have been added and I can view the updates to advanced search as a whole... The issue, as shown in the attached screenshot above, is that some booleans are generic (e.g. hasPublication), while others are specific to either databases (e.g. uses persistent identifiers, I think) or policies (e.g. guidance to help enable compliance).

This is confusing to a novice user, as why would you have registry-specific booleans mixed with generic booleans when you now have registry pulldowns further to the left?

As I see it, here are how the booleans split out:

Generic

• Has Publication

Policies

• Guidance To Help Enable Compliance
• Monitoring of Compliance
• Recommends At Least One Database
• Recommends At Least One Standard
• Updating of DMP

Databases

• Uses Persistent Identifier

Standards

• Is Implemented

Therefore I suggest the following update for the pulldowns, including modifying the order in which they appear:

Select a rule --> Select a generic rule

Update the name of the pulldown to make it clearer all items within that pulldown apply to all record types. Then this pulldown would include everything it has now plus Has Publication

Select a database rule

Include everything it has now plus Uses Persistent Identifier

Select a policy rule

Include everything it has now plus Guidance To Help Enable Compliance, Monitoring of Compliance, Recommends At Least One Database, Recommends At Least One Standard, Updating of DMP

Select an additional rule --> Select a standards rule

The only value here would be Is Implemented - at the moment.

I realise that this only has a single entry in it right now, and that's OK. I'm sure we'll have others in the next year or so, especially as relates to OSTrails and the metrics registry. For now, it's fine to just have Is Implemented, even if it looks odd. The clarity provided by pulldowns for each registry are great.

[prakhyatox]

Thank you! Everything seems to be functioning, and I am happy with the tooltips :-)

Updates to pulldown labels:

* Recommends At Least One Database instead of Recommends Database

* Recommends At Least One Standard instead of Recommends Standard

* "Mandated DMP Creation" instead of "Mandated Dmp Creation"

* Updating of DMP instead of Updating of Dmp

However, I am wondering (and I would very much like @delphinedauga's thoughts here) about the boolean pulldown, now that all pulldowns have been added and I can view the updates to advanced search as a whole... The issue, as shown in the attached screenshot above, is that some booleans are generic (e.g. hasPublication), while others are specific to either databases (e.g. uses persistent identifiers, I think) or policies (e.g. guidance to help enable compliance).

This is confusing to a novice user, as why would you have registry-specific booleans mixed with generic booleans when you now have registry pulldowns further to the left?

As I see it, here are how the booleans split out:

Generic

* Has Publication

Policies

* Guidance To Help Enable Compliance

* Monitoring of Compliance

* Recommends At Least One Database

* Recommends At Least One Standard

* Updating of DMP

Databases

* Uses Persistent Identifier

Standards

* Is Implemented

Therefore I suggest the following update for the pulldowns, including modifying the order in which they appear:

Select a rule --> Select a generic rule

Update the name of the pulldown to make it clearer all items within that pulldown apply to all record types. Then this pulldown would include everything it has now plus Has Publication

Select a database rule

Include everything it has now plus Uses Persistent Identifier

Select a policy rule

Include everything it has now plus Guidance To Help Enable Compliance, Monitoring of Compliance, Recommends At Least One Database, Recommends At Least One Standard, Updating of DMP

Select an additional rule --> Select a standards rule

The only value here would be Is Implemented - at the moment.

I realise that this only has a single entry in it right now, and that's OK. I'm sure we'll have others in the next year or so, especially as relates to OSTrails and the metrics registry. For now, it's fine to just have Is Implemented, even if it looks odd. The clarity provided by pulldowns for each registry are great.

This is implemented.

[delphinedauga]

I've never used the tool before so just tried it without reading @allysonlister comments and indeed, I did the following query but I don't have the expected results (and I guess this ties in with allyson's comment on generic rules versus specific rules)

My query : I want all the databases & standards dealing with genomics (Subjects), ciona robusta OR Ciona Intestinalis OR Ciona Savignyi (taxonomies) Ready OR In Development (Status) GENERIC RULES + Data Access Condition = open for databases SPECIFIC RULES

The results only shows databases : c85d2546-c4c5-48c3-a65e-7bfd8d4034d2.csv

I would expect those standards in the results : https://deploy-preview-2361--fairsharing.netlify.app/772 https://deploy-preview-2361--fairsharing.netlify.app/1338 https://deploy-preview-2361--fairsharing.netlify.app/655

[knirirr]

@delphinedauga only a database can have data_access_condition: open so this would exclude all standards from your result.

[allysonlister]

Ok I think I know what's happening here @delphinedauga

If you say "Databases or standard" AND "database-specific metadata field" then I'm guessing that you won't get any standards because non of them have the database-specific metadata field.

Instead, you'll need to separate the standards and databases and join with an OR:

[allysonlister]

Here's your full query:

[allysonlister]

Is this what you expected?

[allysonlister]

@prakhyatox This is all perfect, thank you. The only thing is the ordering. As said in my comment above, the ordering of the pulldowns should be

1. generic
2. database
3. policy
4. standard

thanks!

[prakhyatox]

@prakhyatox This is all perfect, thank you. The only thing is the ordering. As said in my comment above, the ordering of the pulldowns should be

1. generic

2. database

3. policy

4. standard

thanks!

@allysonlister This is updated.

[delphinedauga]

@allysonlister yes, it is that I expected and understood that the specific rules "data access condition" (database only) excluded standards from my query. And the only way to perform my search is to separate the two types (=2 groups).

If I want all the Databases OR standards dealing with Ciona Robusta (taxonomy), I can perform the search like this :

or like this :

Right ? For me it is just strange to have two different logic to access the results.

Concerning the the boolean pulldown, it is really clear, sounds perfect to me :)

[knirirr]

For me it is just strange to have two different logic to access the results.

We're somewhat constrained by the logic of the underlying query library:

https://github.com/ankane/searchkick?tab=readme-ov-file#querying

...which wouldn't support the conditional application of a filter field.

One thing to bear in mind overall is that whatever system we deploy, we're likely to get emails from users who haven't got results that match expectations.