Matchmaking service page

[pbuttigieg]

xref: iodepo/odis-arch#287

• Explore how to implement a subscription service / continuous search / push notification when an offer (approximately) matches a demand.
• Consider implementing a UI page where offers and demands can be created and pushed into the OIH SOLR backend.
• Consider registering this matchmaking service and its corpus in a dedicated ODIS node
• Consider requiring an OceanExpert login and authentication to use the service, and identify where to send notifications.
  • Explore leveraging "knows about" and other properties to boost matchmaking

On the UI/UX dev side, this should be a question of creating a form-like interface. IODE to provide backend elements.

[pbuttigieg]

A note for integration with DCO Data:

The Decade DCO for Data has a requests page - we can attempt to have this point to our ODIS Matchmaking interface.

[pbuttigieg]

The JSON-LD patterns needed for this are drafted in iodepo/odis-in#3

The minimum specifications for Offers and Demands are templates we can populate through a UI. This need not be complex, mostly a form that helps users enter valid schema.org values into the fields.

Minimum specs for

• Offer is here
• Demand is here

[pbuttigieg]

For the UI/UX and website @maicol07 et al.

The aim is to create a form where a user can create either an offer or a demand, with their inputs validated against the schema definitions above. Each offer or demand should then be rendered as JSON-LD/schema.org documents, and pushed to the backend (@fils @jmckenna) where the OIH team can then handle it (e.g. matchmaking via a standard query derived from the offer/demand.json).

For Demands: To avoid user / ID management, the UI should (on the completion and submission of the form) generate a persistent URL with a hash of the request, such that the user can use that URL to check for any (near) matches. We'll have to create the backend functions to serve this, but the creation of such URLs can be drafted now. (cc @arnounesco )

[pbuttigieg]

@fils - elements relevant to the backend here.

On Offers - the submitter of the offer should be able to delete it. As we're not using user management.

There's a field in the Offer pattern that is the expiration date of the offer. This should be mandatory, and the offer will expire after this date (i.e. the backend system will delete or disable it).

If they want to delete it before the expiration, there'll need to be another measure such as a one-time log-in using an email address or similar.

If the user enters a contact email (which we could verify, on submission), we can trigger an autoreminder that their offer is about to expire, and ask if they'd like to extend it. It would be very good if they could click a link to a pre-filled form that they can edit and resubmit.

[pbuttigieg]

On Demands:

We should allow the user to select whether they'd like to make the Demand public, so those that could meet it can see it and contact them.

@fils in the back-end, this would mean we can integrate these into the KG and expose them on the UI as another facet