There was a thread where people suggested “standard.events” after seeing the work that @flo-bit.dev has done with https://atmo.rsvp - echoing Standard Site https://standard.site for long form content.
Standard Site is a meta lexicon that wraps multiple other long form lexicons.
For events, community.lexicon.events is the shared lexicon. Anyone can implement it and even extend it for their app by adding extra records as desired.
What’s not resonating about shared community lexicons?
I do think that a landing page at event.lexicon.community - essentially promoting and documenting apps and use cases - could be interesting.
Yeah, I’ve definitely dropped the ball on marketing there.
I don’t know if this is about things resonating or about different approaches to the same solution.
The folks who built standard.site realized they already knew what they wanted to build, and felt like they could do the same job faster among themselves.
The SmokeSignal lexicon does a great job of what it needs to do for the events space, so others don’t feel the need to re-invent the wheel.
Imo, Lexicon Community is useful for folks who need guidance on forming a shared lexicon and/or feel existing lexicons aren’t broad/similar enough for potentially interoperable platforms.
Branding is powerful. The NSID-as-docs-site pattern seems to work quite well for standard site. Even a redirect to the lexicon garden docs would likely be a good start.
We seem to have identified a relationship dynamic. Lexicons are a product which lexicon authors must sell to client app builders.
It’s a wrapper lexicon where three separate apps (to start) collaborated. I don’t know what “knew what they wanted to build” means in context - they did a process and made a lexicon.
This is not about not making a working group 
more like - how to better explain tha a re-usable lexicon exists (or can be created).
Ah, fair. My read on the topic was “why aren’t more folks engaging with lexicon community” when the topic is actually “hey, these lexicons exist, how do we draw awareness.” 
Yep exactly!
Thinking about this some more - if people look at the documentation on atproto.com, it’s all about how to create lexicons.
Here are some that exist that you can consume / produce would be good too.
Have an idea for an event app? Amazing! You can start pulling live data right away to inform your design.
yeah standard.site just does a very good job at presenting the lexicon i think + it’s very minimal so easy to use for whatever (e.g. blento actually uses `site.standard.publication` even though there’s still no blogging capabilities in blento itself [coming at some point though]) very much in favor of a version of that for the community event lexicon (+ adding something like that to atproto.com would also be nice).
i think this is also related to that community app lexicon discussion and one of the reasons why i think that should have custom collections in it (so you can quickly check what lexicons other similar apps are using and use them too).
regarding drawing awareness though, i’m not actually aware of any event atproto apps that don’t use the community event lexicon, so i guess awareness is actually already there at least for people building stuff with events? anyone else doesnt really need to know? 
(/ its our job as app builders to tell them: “your events on atmo.rsvp will also appear on smokesignals, openmeet, etc”)
(apps using the community event lexicon: smokesignal, openmeet, atmo.rsvp, blento, aktivi (not yet deployed anywhere))
This is a VERY good point!
Plus those that are publishing TO the lexicon - dandelion events, the other I forget about tech events in Boston???, and my friend Andy’s Vancouver music events aggregator.
So, given Flo’s post – we won already 
(+ adding something like that to atproto.com would also be nice).
i’d agree with this as someone fairly new! would be great to have https://lexicon.garden/ on there
It’s a bit off-topic, but it’s worth noting that the notion of “sharing” differs between the two schemas.
community.lexicon.calendar.event is a self-contained data model. In contrast, site.standard.document only requires title and reference. As you know, without relying on other lexicons, you can’t even write its content.
My understanding is that the primary goal of lexicon.community is to serve as an alternative to defining new schemas, whereas standard.site is designed as an extension layer to make content easier to discover, index, and move.
This likely lowers the barrier to adoption for developers, but I’m curious whether this is specific to long-form platforms or a more general design pattern.
For example, Open Evnt is aware of lexicon.community, but still defines its own incompatible collections. This seems to be because it aims to represent string fields (such as name) as language-to-string maps for multilingual support. While this might be possible with community.lexicon.calendar.event, it would likely not be a natural fit. Extension fields provide flexibility, but not always enough.
Ultimately, my point is that these approaches differ in purpose, and that this difference may significantly affect their adoption.
Yep, Standard Site is a meta lexicon that is a wrapper for disparate other ones.
I’d say the primary goal(s) are to collectively develop shared lexicons, sharing approaches to lexicon development, and some evolving governance tools over how to do that.
LC does not want to stand in the way of defining new schemas! But rather than everyone having to figure out how to start from scratch doing things collectively, having more tools over time, including a “default” domain.
Independently from your comment, I just invited the Evnt folks in here to discuss updating the community lexicon → Kicking off a dedicated space for discussion for Calendar, Events, RSVP
Multilingual is a great example of something that EVERY lexicon is going to have to figure out an approach for.