Layers

Layers

@layers.pub

Linguistic annotations on ATProto. https://layers.pub

43 followers7 following39 posts

Layers reposted

Replying to @chive.pub

You can also point a paper at a @layers.pub dataset it introduces or uses. A dataset is named by at-uri rather than by a URL at some host, so the reference is to the record and doesn't depend on a particular page staying up.

didactic is itself built on panproto.dev, which handles migration within and between formats (e.g. between layers data model versions or from CoNLL-U to layers).

If you find this stuff interesting, also check out the broader @atproto.science ecosystem!

ATProto Science@atproto.science

We made a thing! Check out our new #ATScience ecosystem map ✨ All projects, organized in one place: atproto.science/ecosystem/

On the writing side: you can author records as typed models and lairs applies them to your PDS as a minimal diff. It also has codecs for converting between Layers and formats like CoNLL-U and brat, and exporters to HuggingFace datasets, PyTorch, and WebDataset.

The lairs client is set up to make it easy for you to post your own data to your PDS and to access and work with others' data.

On the reading side: you can pull an account's records into a local repository, materialize a corpus or judgment study to Arrow/Parquet to query with DuckDB, and browse it in a terminal explorer.

Layers reposted

Replying to @robmalouf.bsky.social

You could certainly define similar schemas for XML or use vanilla JSON schemas or whatever. From my perspective, one point in favor of ATProto is about the infrastructure it provides for discovery + sharing: defining lexicons (rather than another schema) supports hooking into that infrastructure.

Layers (v0.5.0) now has a pub.layers.changelog lexicon for targeted semantic versioning of all data and metadata components in the pub.layers namespace. docs.layers.pub/lexicons/cha... We've also documented plans for developing an AppView. docs.layers.pub/appview/ Discussion welcome.

docs.layers.pubpub.layers.changelog | Layers DocumentationStructured changelog records for tracking changes to any Layers record. Adapted from Chive's pub.chive.eprint.changelog pattern but generalized to target any of the 26 pub.layers.* record types, with ...
View full thread
View full thread

Layers is a sister project to @chive.pub. The idea is bidirectional linking between annotation resources and eprints: datasets link to the papers that describe them, and papers link back to their data. This works with eprints on Chive and other repositories.

The plan is for community governance to follow @chive.pub's approach. All the enums (annotation kinds, tagsets, categories, formalisms) are community-expandable. Anyone can mint new ones by publishing ontology records in their own PDS without any schema changes on our end.

View full thread

Layers also covers offline judgment experiments with four orthogonal design dimensions (what you measure, the response instrument, how stimuli are presented, and what captures the data) and annotation project design metadata for things like annotator redundancy, adjudication, and quality criteria.

For knowledge representation, there's a typed property graph (pub.layers.graph) that works similarly to how @chive.pub does its knowledge graph with pub.chive.graph.*. Annotations ground to Wikidata, FrameNet, WordNet, PropBank, and so on through knowledgeRef links.

View full thread

For computational linguistics and NLP, the goal is a common interchange format you can import training and evaluation data through. The docs cover how Layers subsumes a bunch of data models (CoNLL, brat, ELAN, TEI, AMR, LAF/GrAF, and others), and the plan for the appview is adapters from each.

Beyond annotation, Layers covers psycholinguistic and neurolinguistic signals: eye-tracking fixations, EEG/ERP waveforms, MEG sensor data, fMRI activations. These use the same anchoring and annotation primitives as text, just with temporal and spatial selectors.

View full thread

The format doesn't commit to any particular tagset or theoretical framework. Whether you work in UD, HPSG, LFG, or Minimalism, your labels and categories are data values within the schema, not baked into it. The same primitives represent your annotations regardless of formalism.

If you do fieldwork or language documentation: the same schema that handles treebank annotations also handles interlinear glossed text, ELAN-style time-aligned tiers, and multimodal alignment across audio, video, and images. All linked to the same expressions and living in your own PDS.

View full thread

On top of that, most annotation data lives in isolated repositories on centralized services, and there's no standard way to link annotations to the experiments that produced them or other signals (e.g. neural recordings) they were collected alongside. Layers tries to address both of these problems.

The core idea is a small set of shared primitives (anchors, selectors, feature maps) that all data types compose from. Expressions are recursive: a document contains paragraphs, which contain sentences, which contain words, which contain morphemes. Annotations attach to any level of that hierarchy.

The motivation is pretty simple. There are tons of linguistic annotation formats, and they don't really talk to each other. If you want to use annotations from one tool in another, you end up writing conversion scripts that inevitably break on edge cases.

You are up to date.