add support for Venue objects

[carboxylman]

A Venue is yet another "first class" piece of Artifact Metadata, that represents a place of publication or appearance. We attempted to cover all know publication kinds that we could plausibly receive. We want users to be able to attach one or more Venues to an Artifact, since an Artifact could be "published" or appear in multiple places. This is important to be able to provide Venue-indexed lists of Artifacts.

The schema is at https://gitlab.flux.utah.edu/searcch/importer/-/commit/27b2785ced42c4192b12d8a4ce4e76e5c2fc6e00 , and will shortly be merged with importer master.

Venues are similar to existing objects like Badges or Organizations in our system, in that Venues are either verified or unverified. However, they are dissimilar to Badges in that we do not allow users to create Badges (yet), since the set of Badges is finite and knowable. Orgs and Venues are effectively infinite, so we allow users to create them, but in that case, they are not marked verified. The importer knows how to collect Venue information for some sources now.

The backend work is simply the database migration and a few basic endpoints that are clones of Organizations. Similar for the frontend.

[dpemmerich]

add venue box - include search for name/title based on title and abbreviation
if venue exists, show venue name as selectable
if venue does not exist, give option (press enter? click here? ...) to create new venue, and pop open expanded form for required details

[carboxylman]

The core of this is complete:

• backend: ITI/searcch-backend@63d7d89
• frontend: 8d46e5a
• importer: https://gitlab.flux.utah.edu/searcch/importer/-/commit/7d1c784a61f59c49256921032082876d94b732d8

The remaining bits are along the lines of those we are already missing for other objects -- widgets to create new Venues and RecurringVenues, and to mark them as verified. We need some patterns for these widgets.

[ckouder]

@carboxylman I'd like to clarify some details of this this task. I notice that there is no usage of /recurringvenue(s) and /venue in frontend. How are we going to use them?

In addition, there is no post, update, or delete functions for recurring-venue and venue in the backend?

[carboxylman]

I'd like to clarify some details of this this task. I notice that there is no usage of /recurringvenue(s) and /venue in frontend. How are we going to use them?

There is a usage of GET /venues; that is how the venue search dropdown is populated with verified venues. See the creation of venuesEndpoint in plugins/repository.js, and fetchVenues in store/user.js.

The idea is to display "index" pages of all artifacts that appeared in a given venue, and list all venues associated with a given recurringvenue. Take a look at the venue for my favorite artifact, stackdb: https://dl.acm.org/doi/proceedings/10.1145/2576195 . This is VEE'2014. That page shows you all the conference sessions, etc. We don't care about all the conference metadata, but we do want to list artifacts published at that venue in one place. Then, if you click on the overall VEE conference series link, you will wind up at https://dl.acm.org/conference/vee, which lists all occurrences of the VEE conference. In our model, that is a recurringvenue.

In addition, there is no post, update, or delete functions for recurring-venue and venue in the backend?

Correct, we will need to add some of this. Don't worry about delete unless admin since multiple records might link to a given Venue; and if the admin is forcing delete even if there are foreign key relationships, you will have to unwind those too; hence the importance of restricting to admins only. POST should only set the verified bit if admin; only admins can PUT on verified records for now. Mere users should not be allowed to POST nor PUT. User creation of Venue objects happens as a side effect of creating or updating an Artifact, the same as how Organizations are created. I can explain this in more detail on a call.

[ckouder]

@carboxylman ok i think i got the idea -
we want a page(?) for each venue session (VenueSession) and recurring venue (RecurringVenue)
in each page of VenueSession, we display artifacts that are published in the session
in each page of RecurringVenue, we display all sessions (perhaps session metadata?) of that Venue

Are venues artifacts? if so, i think both functions can be done by tweaking the existing search function and ArtifactShort

[carboxylman]

Venues are not Artifacts. There is a Venue, and a RecurringVenue. A RecurringVenue is an aggregation over many Venues that happen at discrete intervals. An example of a RecurringVenue would be the USENIX Security conference, and a Venue would be USENIX Security 2023.

Both RecurringVenue and Venue have metadata to display (https://github.com/ITI/searcch-backend/blob/11dc7ff4fae3b7b239529a002e2bdd62aa5ec3b5/searcch_backend/models/model.py#L468). For the RecurringVenue, the page is quite simple and just states the metadata; lists the recurrences (Venues, linking to the per-venue page). For the Venue, we display the metadata, then a list of Artifacts that appeared in that Venue.