Introducing tags for filtering and extension point

[vmx]

All Matadisco records are using the same Lexicon. When consuming it from the firehose/jetstream, you can all records. Though you likely are only interested in a specific group, e.g. satellite imagery or podcasts. Therefore some additional data to allow filtering is needed. I propose tags. It would be a top-level field and contain an array of strings. Example:

{
  "tags": ["stac", "sentinel-2-l2a"]
}

The author of the record could put anything in there they like. One could put in wrong information, but as any record contains the originate account, you could filter adversaries/spammers out. Or you can make it opt-in and maintain an allowlist for your system and deny all other records for other accounts.

Tags can then even be used for extending the Lexicon independent of the main Lexicon. There could be a convention that each tag might add a top-level field of type ref. So you could then have:

{
  "stac": {
    "$type": "org.example.stac",
    "geometry": …,
  },
  "tags": ["stac", "sentinel-2"]
}

So communities could start experimenting with different lexicons for the same tag. Once there's an agreement of a single common one, it could be added to the main Matadisco Lexicon as top-level field with the corresponding ref to that lexicon.

[bumblefudge]

I definitely like the first part, the second part about arbitrary new objects... i will have to think on, it scares me a little.

[mishmosh]

Tags seem like the right concept, but getting the details right will be important.

• Is there any benefit to namespacing the tags by type or community, to minimize collision? E.g. [stac:sentinel-2], [stac:daily], or [iiif:british-museum].
• Is there any way to register or discover tags, to reduce duplication? Who would maintain the allowlists and can they be shared across communities?

Looking at how hashtags evolved in social media, they're good for broad discovery but the issues above (deduplication, collision) make them messy for comprehensive discovery or filtering.

Let's see what needs @exhibitso encounters as they implement Matadisco for IIIF.

[vmx]

• Is there any benefit to namespacing the tags by type or community, to minimize collision? E.g. [stac:sentinel-2], [stac:daily], or [iiif:british-museum].

I would expect that details like that will emerge from wider usage. I'd keep it simple for now.

• Is there any way to register or discover tags, to reduce duplication?

There could be a service running that consumes the Jetstream and extracts the tags. You could then display how often they occur. Similarly to what OpenStreetmap is doing with TagInfo.

• Who would maintain the allowlists and can they be shared across communities?

I would expect them to be pretty specific and hopefully the default would be that things are just open. Allowlists add process/burden.

Looking at how hashtags evolved in social media, they're good for broad discovery but the issues above (deduplication, collision) make them messy for comprehensive discovery or filtering.

Yes, things will get messy, but that's how the world is. I think OpenStreetMap shows that things are not perfect, but more successful than top-down standardization efforts.