9 releases (4 breaking)

0.10.2 Oct 18, 2024
0.10.0 Oct 4, 2024
0.9.1 Sep 23, 2024
0.9.0 Aug 29, 2024
0.5.0 Feb 22, 2024

#263 in Text processing

Download history 48/week @ 2024-07-26 5/week @ 2024-08-02 82/week @ 2024-08-23 50/week @ 2024-08-30 13/week @ 2024-09-13 137/week @ 2024-09-20 46/week @ 2024-09-27 137/week @ 2024-10-04 14/week @ 2024-10-11 136/week @ 2024-10-18 4/week @ 2024-10-25

140 downloads per month

GPL-3.0-only

385KB
7K SLoC

stam logo

Docs PyPI PyPI GitHub build GitHub release Project Status: Active – The project has reached a stable, usable state and is being actively developed. Technology Readiness Level 7/9 - Release Candidate - Technology ready enough and in initial use by end-users in intended scholarly environments. Further validation in progress.

STAM Python binding

STAM is a data model for stand-off text annotation and described in detail here. This is a python library (to be more specific; a python binding written in Rust) to work with the model.

What can you do with this library?

  • Keep, build and manipulate an efficient in-memory store of texts and annotations on texts
  • Search in annotations, data and text:
    • Search annotations by data, textual content, relations between text fragments (overlap, embedding, adjacency, etc),
    • Search in text (incl. via regular expressions) and find annotations targeting found text selections.
    • Search in data (set,key,value) and find annotations that use the data.
    • Elementary text operations with regard for text offsets (splitting text on a delimiter, stripping text).
    • Convert between different kind of offsets (absolute, relative to other structures, UTF-8 bytes vs unicode codepoints, etc)
  • Read and write resources and annotations from/to STAM JSON, STAM CSV, or an optimised binary (CBOR) representation
    • The underlying STAM model aims to be clear and simple. It is flexible and does not commit to any vocabulary or annotation paradigm other than stand-off annotation.

This STAM library is intended as a foundation upon which further applications can be built that deal with stand-off annotations on text. We implement all the low-level logic in dealing this so you no longer have to and can focus on your actual application.

Installation

$ pip install stam

Or if you feel adventurous and have the necessary build-time dependencies installed (Rust), you can try the latest development release from Github:

$ pip install git+https://github.com/annotation/stam-python

Documentation

Usage

Import the library

import stam

Loading a STAM JSON (or CSV) file containing an annotation store:

store = stam.AnnotationStore(file="example.stam.json")

The annotation store is your workspace, it holds all resources, annotation sets (i.e. keys and annotation data) and of course the actual annotations. It is a memory-based store and you can put as much as you like into it (as long as it fits in memory).

You can optionally pass configuration parameters upon loading a store, as follows:

store = stam.AnnotationStore(file="example.stam.json", config={"debug": True})

Once loaded, you can retrieve anything by its public ID:

annotation = store.annotation("my-annotation")
resource = store.resource("my-resource")
dataset = store.dataset("my-annotationset")
key = dataset.key("my-key")
data = dataset.annotationdata("my-data")

You can also iterate through all annotations in the store, and output a simple tab separated format:

for annotation in store.annotations():
    # get the text to which this annotation refers (if any)
    try:
        text = str(annotation)
    except stam.StamError:
        text = "n/a"
    for data in annotation:
        print("\t".join(( annotation.id(), data.key().id(), str(data.value()), text)))

Adding a resource:

resource = store.add_resource(filename="my-text.txt")

Create a store and annotations from scratch:

from stam import AnnotationStore, Selector, AnnotationDataBuilder

store = AnnotationStore(id="test")
resource = store.add_resource(id="testres", text="Hello world")
store.annotate(id="A1", 
                target=Selector.textselector(resource, Offset.simple(6,11)),
                data={ "id": "D1", "key": "pos", "value": "noun", "set": "testdataset"})

In the above example, the AnnotationDataSet , DataKey and AnnotationData are created on-the-fly. You can also create them explicitly within the set first, as shown in the next snippet, resulting in the exact same store:

store = AnnotationStore(id="test")
resource = store.add_resource(id="testres", text="Hello world")
dataset = store.add_dataset(id="testdataset")
dataset.add_key("pos")
data = dataset.add_data("pos","noun","D1")
store.annotate(id="A1", 
    target=Selector.textselector(resource, Offset.simple(6,11)),
    data=data)

Providing the full data dictionary as in the earlier example would have also worked fine, with the same end result, but would be less performant than passing an AnnotationData instance directly. The implementation will always ensure any already existing AnnotationData will be reused if possible, as not duplicating data is one of the core characteristics of the STAM model.

You can serialize the entire annotation store (including all sets and annotations) to a STAM JSON file:

store.set_filename("example.stam.json")
store.save()

For more documentation, please read: STAM Tutorial: Standoff Text Annotation for Pythonistas.

Differences between the rust library and python library and performance considerations

Although this Python binding builds on the Rust library, the API it exposes differs in certain aspects to make it more pythonic and easier to work with. This results in a higher-level API that hides some of the lower-level details that are present in the Rust library. This approach does come at the cost of causing some additional runtime overhead.

The Rust methods will often return iterators, references or handles whenever they can, moreover it will do so safely. The Python API is often forced to make a local copy. For iterators we often decide to let the entire underlying Rust iterator run its course and then return the result as a whole as a tuple, rather than return a Python generator. Here you gain some speed at the cost of some memory.

Probably needless to say, but using Rust directly will always be more performant than using this Python binding. However, using this Python binding should still be way more performant than if the whole thing were implemented in native Python. The trick is in letting the binding work for you as much as possible, use higher-level methods whenever they are available rather than implementing your logic in Python.

Acknowledgements

This work is conducted at the KNAW Humanities Cluster's Digital Infrastructure department, and funded by the CLARIAH project (CLARIAH-PLUS, NWO grant 184.034.023) as part of the FAIR Annotations track.

Dependencies

~14–26MB
~395K SLoC