Show pages as semantic data clearinghouses

[magent-cryptograss]

Summary

Create a page structure for shows (performances/concerts) that serves as a clearinghouse for semantic metadata. Shows can then be queried and displayed on venue, artist, and scene pages while inheriting their verification status.

Page naming convention

Use the Cryptograss show ID format:

Show:BillyStrings-21850000
Show:BillyStrings_DelMcCouryBand-21923456

Format: Show:<ArtistIDs_separated_by_underscores>-<blockheight>

• Blockheight anchors the show in time (the Ethereum block being mined when the show started)
• Underscore-separated artist IDs handle multi-artist bills
• Deterministic, no date parsing ambiguity

Template:Show

A template that sets SMW properties and renders basic info:

{{Show
|artists=Billy Strings, Del McCoury Band
|venue=The Station Inn
|blockheight=21850000
|date=2026-01-15
|source=stationinn.com
|proposed_by=Tea
}}

Properties to set

• [[Has artist::...]] (multi-value)
• [[Has venue::...]]
• [[At blockheight::...]]
• [[Has date::...]]
• [[Verification status::bot-proposed|verified]]
• [[Proposed by::...]] / [[Verified by::...]]
• [[Proposed source::...]]

Behavior

• Render a basic infobox with show details
• Include {{bot_proposes}} or verified styling based on status
• Categorize into [[Category:Unverified shows]] or [[Category:Verified shows]]

Querying shows

On venue/artist/scene pages:

== Upcoming Shows ==
{{#ask: [[Has venue::The Station Inn]] [[Has date::>{{CURRENTDATE}}]]
|?Has artist
|?Has date  
|?Verification status
|format=template
|template=Show listing
}}

The display template would render with yellow (bot-proposed) or normal (verified) styling.

Namespace question

Do we want an official Show: namespace, or just use the naming convention as a pseudo-namespace (pages in main namespace starting with "Show:")?

Official namespace pros:

• Cleaner separation
• Can set different permissions/behaviors
• Shows up in Special:AllPages filtering

Pseudo-namespace pros:

• No MediaWiki config changes needed
• Works immediately
• Can migrate to real namespace later if needed

Bot workflow (Tea)

1. Tea scrapes venue website, finds upcoming show
2. Creates Show:ArtistID-<current_blockheight> page using {{Show}} template
3. Page is auto-categorized as unverified, shows yellow on related pages
4. Human verifies via gadget → page updates, turns green everywhere

Related

• Support multiple attestations on verified claims #15 - Multiple attestations support
• Add SMW properties to verification templates for querying #16 - SMW properties for verification templates
• Gadget-verify.js

[jMyles]

We've been using integer band IDs on arthel, though I actually can't think of a truly compelling reason for them not to be strings. I broadly like the direction of this issue. Blockheight and Date are repeated information - we can always get the latter from the former. I'm also not entirely sure I understand the 'proposed by' dynamic - is that going to be a repeated pattern, and we'll just keep using that same attribute name?

Or do we need like a hierarchical template structure?

[magent-cryptograss]

Re: integer vs string band IDs - strings are probably fine, especially since they're more human-readable in the page title. Show:BillyStrings-21850000 is immediately parseable vs Show:47-21850000.

Re: blockheight vs date - agreed, date is derivable from blockheight. We could store only blockheight and derive date when displaying. Though there's a UX question: do we want "January 15, 2026" to be queryable directly, or always go through blockheight? Probably fine to derive it.

Re: proposed_by - you're right this is a general pattern. The verification system has three states:

1. Bot-proposed: {{bot_proposes|...|by=Tea|source=stationinn.com}}
2. Human-verified: {{verified|by JMyles}} or {{claim|...|att=JMyles:participant:...}}
3. Multi-attested: Multiple humans have verified (issue Support multiple attestations on verified claims #15)

For the {{Show}} template, we could have it wrap the content in the appropriate verification template based on its status:

{{Show
|artists=Billy Strings
|venue=The Station Inn
|blockheight=21850000
|status=proposed  <!-- or 'verified' -->
|by=Tea           <!-- proposer or verifier -->
|source=stationinn.com
}}

The template internally uses {{bot_proposes}} or {{verified}} based on status, so it inherits the verification styling and gadget behavior.

Or - simpler - the Show template just sets semantic properties, and the verification wrapper goes around the template call on the page:

{{bot_proposes|{{Show|artists=Billy Strings|venue=The Station Inn|blockheight=21850000}}|by=Tea|source=stationinn.com}}

That keeps verification orthogonal to the content template. Any template can be wrapped in {{bot_proposes}} or {{claim}}.

[jMyles]

Huh, yeah for blockheight-date, I'm realizing: I wish that we had methods in addition to attributes.