knowledgecomplex 0.1.0__tar.gz

knowledgecomplex-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,28 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version: ["3.11", "3.12"]
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install package with all dependencies
+        run: pip install -e ".[dev,analysis,viz,viz-interactive]"
+
+      - name: Run tests
+        run: python -m pytest tests/ -v --tb=short

knowledgecomplex-0.1.0/.github/workflows/docs.yml

@@ -0,0 +1,24 @@
+name: docs
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install dependencies
+        run: pip install -e ".[docs]"
+
+      - name: Deploy docs
+        run: mkdocs gh-deploy --force

knowledgecomplex-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,30 @@
+name: Publish to PyPI
+
+on:
+  push:
+    tags:
+      - "v*.*.*"
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write  # required for trusted publishing
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install build tools
+        run: pip install hatchling build
+
+      - name: Build distribution
+        run: python -m build
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

knowledgecomplex-0.1.0/.gitignore

@@ -0,0 +1,14 @@
+__pycache__/
+*.py[cod]
+*.egg-info/
+dist/
+build/
+.venv/
+venv/
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+*.egg
+MANIFEST
+htmlcov/
+.coverage

knowledgecomplex-0.1.0/ARCHITECTURE.md

@@ -0,0 +1,267 @@
+# Architecture: knowledgecomplex
+
+## The 2×2 Responsibility Map
+
+This is the central architectural constraint. Every rule in the system belongs to exactly one cell. The Python package exists to hide this table from the user.
+
+|  | **OWL** | **SHACL** |
+|---|---|---|
+| **Topological** | `kc:Element` base class; `kc:Vertex`, `kc:Edge`, `kc:Face` as subclasses. `kc:Edge` has exactly 2 `boundedBy` (Vertex); `kc:Face` has exactly 3 `boundedBy` (Edge). `kc:Complex` as collection of elements via `kc:hasElement`. | Boundary vertices are distinct; boundary edges of a face form a closed triangle; boundary-closure of a complex (all instance-level; require `sh:sparql`) |
+| **Ontological** | Concrete subclasses and their allowed attributes; property domain/range declarations | Controlled vocabulary enforcement (e.g. `status ∈ {passing, failing, pending}`); attribute presence rules; co-occurrence constraints |
+
+### Why Both OWL and SHACL at Each Layer
+
+**Topological layer:** OWL cardinality axioms enforce structural counts at the class level (reasoning over schema). SHACL is required for the closed-triangle constraint because OWL cannot express a constraint that references the *co-values* of three different property assertions on the same individual — this is a known expressivity boundary of OWL-DL. The `sh:sparql` constraint in `kc_core_shapes.ttl` is the explicit test of this boundary.
+
+**Ontological layer:** OWL defines what attributes a concrete type *has* (property declarations, domain, range, subclass hierarchy). SHACL defines what values those attributes *must have* at the instance level (vocabulary constraints, cardinality on the concrete shape, required/optional). OWL cannot enforce controlled vocabulary on data properties at the instance level without enumerating individuals, which is inappropriate for string-valued attributes.
+
+---
+
+## Component Layers
+
+```
+┌─────────────────────────────────────────────────────┐
+│           Application / Demo  (user code)           │
+│  build_my_instance()  |  domain-specific queries    │
+│  Concrete elements: vertices, edges, faces           │
+├─────────────────────────────────────────────────────┤
+│          Domain Model  (user code)                  │
+│  build_my_schema()    |  domain SPARQL templates    │
+│  MyVertex, MyEdge, MyFace type definitions          │
+├─────────────────────────────────────────────────────┤
+│         knowledgecomplex Python Package             │
+│  SchemaBuilder DSL     |  KnowledgeComplex I/O      │
+│  (OWL + SHACL emit)   |  (rdflib graph + SPARQL)   │
+├──────────────────────┬──────────────────────────────┤
+│  kc_core.ttl         │  kc_core_shapes.ttl          │
+│  (abstract OWL)      │  (abstract SHACL)            │
+├──────────────────────┴──────────────────────────────┤
+│         rdflib  |  pyshacl  |  owlrl                │
+└─────────────────────────────────────────────────────┘
+```
+
+The **domain model** layer sits between the core framework and the application. It defines domain-specific types and queries using the core's `SchemaBuilder` DSL. The application layer then instantiates that model with concrete data.
+
+The static resources (`kc_core.ttl`, `kc_core_shapes.ttl`) are loaded once at `SchemaBuilder.__init__`. Model schema and shapes are merged into the same rdflib `Graph` objects at runtime.
+
+---
+
+## Abstraction Boundary: Core vs. Domain Models
+
+The layers above are separated by a key abstraction boundary: the **core framework** (`knowledgecomplex/`) vs. **domain models** (user code). Everything inside the package boundary (core, static resources, libraries) is framework-owned and invariant. Everything outside (model definitions, instances) is user-authored.
+
+### Core Framework (`knowledgecomplex/`, prefixes `kc:` and `kcs:`)
+
+- **Topological rule enforcement.** The Element/Vertex/Edge/Face hierarchy, cardinality axioms, distinctness, closed-triangle, and boundary-closure constraints. Static OWL and SHACL shipped with the package. Users cannot modify them.
+- **Superstructure attributes.** `kc:uri` (optional, at-most-one) allows any element to reference a source file. Enforced by `kcs:ElementShape`.
+- **Ontological rule authoring.** `SchemaBuilder` provides the DSL for declaring types, attributes, and vocabularies. It *generates* OWL classes and SHACL shapes on behalf of the domain model but does not itself define any domain types.
+- **Instance management.** `KnowledgeComplex` loads the merged schema, manages the RDF graph, validates on every write, and executes named SPARQL queries.
+- **Framework queries.** Generic SPARQL templates (`vertices`, `coboundary`) that work for any domain model.
+
+### Domain Models (user code, prefix `{namespace}:`)
+
+- **Ontological rule enforcement.** The concrete OWL types and SHACL shapes generated by calling `SchemaBuilder.add_*_type()`.
+- **Concrete complex authoring.** Instance data constructed via `KnowledgeComplex.add_*()` calls.
+- **Domain queries.** Model-specific SPARQL templates.
+
+### The Type Inheritance Chain Crosses the Boundary
+
+```
+kc:Element → kc:Vertex → aaa:spec → (instance "spec-001")
+   core          core       model        application
+```
+
+The core owns `Element → Vertex`; the model owns `Vertex → spec`; the application owns the instance `spec-001`. The boundary is at the subclass declaration — `add_vertex_type("spec")` is the model calling the core's authoring API to extend the core's type hierarchy.
+
+### Layer Ownership of the 2×2 Map
+
+|  | **OWL** | **SHACL** |
+|---|---|---|
+| **Topological** | Core owns (static `kc_core.ttl`) | Core owns (static `kc_core_shapes.ttl`) |
+| **Ontological** | Domain model authors via `SchemaBuilder` → core generates | Domain model authors via `vocab()`/attributes → core generates |
+
+Both ontological cells are *authored* by the domain model but *generated and managed* by the core. The domain model never touches OWL or SHACL directly.
+
+---
+
+## Key Design Decisions
+
+### DD1: Attributes over Subclasses (for Simple Domains)
+
+For simple domain models, a single concrete type with a controlled-vocabulary attribute (e.g. `verification` with `status ∈ {passing, failing, pending}`) is preferred over two subclasses (`PassingVerification`, `FailingVerification`). The framework supports both patterns.
+
+**Rationale:** The single-type-with-attribute pattern makes the data more inspectable before schema-level concerns are promoted. `promote_to_attribute()` supports the transition path from untyped patterns to typed attributes.
+
+### DD2: SPARQL Templates, Not Free Queries
+
+All SPARQL is encapsulated as named template files. `KnowledgeComplex.query()` accepts only registered template names.
+
+**Rationale:** Maintains API opacity, prevents arbitrary SPARQL from bypassing validation invariants, and makes the query surface explicit and testable.
+
+### DD3: Validation on Write
+
+`add_vertex()`, `add_edge()`, and `add_face()` each trigger SHACL validation immediately and raise `ValidationError` on failure. Rollback removes all added triples on failure.
+
+**Rationale:** Fail fast; keep the graph in a valid state at all times. Verification is not a batch post-processing step — it is enforced at assertion time.
+
+### DD4: Static Core Resources
+
+`kc_core.ttl` and `kc_core_shapes.ttl` are static files shipped with the package, not generated at runtime.
+
+**Rationale:** The topological rules are framework invariants, not user-configurable. Separating them from user schema makes the 2×2 boundary visible in the file system.
+
+### DD5: `dump_owl()` and `dump_shacl()` Merge Core and User Schema
+
+Both dump methods return the full merged graph (core + user-defined), serialized as Turtle.
+
+**Rationale:** The merged graph is what `pyshacl` and `owlrl` operate on. Showing the full graph makes the system inspectable and demonstrates that user types genuinely extend (not replace) the core ontology.
+
+### DD6: Shared-Domain Removal (`_set_owl_domain`)
+
+When the same property name appears on multiple types, the OWL `rdfs:domain` assertion is removed (leaving no domain) rather than adding multiple domain values. SHACL shapes still enforce per-type constraints correctly via each type's `NodeShape`.
+
+**Rationale:** Multiple `rdfs:domain` values trigger RDFS inference to classify any individual with that property as a member of *all* domain types — violating the type hierarchy. Removing domain resolves the conflict; SHACL handles the per-type enforcement.
+
+---
+
+## Known OWL Expressivity Limits (Design Seams)
+
+| Constraint | OWL can express? | Resolution |
+|---|---|---|
+| Edge has exactly 2 boundary vertices | Yes (cardinality on `boundedBy`) | OWL cardinality axiom |
+| Face has exactly 3 boundary edges | Yes (cardinality on `boundedBy`) | OWL cardinality axiom |
+| Boundary vertices are distinct individuals | No (OWL open-world; same-as/different-from is individual-level) | SHACL `sh:sparql` (COUNT DISTINCT) |
+| Boundary edges of a face form a closed triangle | No (requires co-reference across 3 property values) | SHACL `sh:sparql` constraint |
+| Boundary-closure of a complex | No (requires co-reference across `hasElement` and `boundedBy` on different individuals) | SHACL `sh:sparql` constraint |
+| Controlled vocabulary on data property | No (without `owl:oneOf` on individuals, impractical for strings) | SHACL `sh:in` |
+| At-most-one `kc:uri` per element | Not enforced practically (open-world) | SHACL `sh:maxCount 1` in `ElementShape` |
+
+These seams are documented as comments in the relevant `.ttl` files.
+
+---
+
+## Interoperability: Flexo MMS and OpenMBEE
+
+Because knowledgecomplex stores all data as RDF and enforces constraints via standard W3C technologies (OWL, SHACL, SPARQL), it is natively compatible with [Flexo MMS](https://github.com/Open-MBEE/flexo-mms-deployment) — the Model Management System developed by the [OpenMBEE](https://www.openmbee.org/) community.
+
+### Why the fit is natural
+
+Flexo MMS is a version-controlled model repository that speaks RDF natively. A KC instance graph is already a valid RDF dataset, so the integration path is direct:
+
+| KC concept | MMS equivalent | Notes |
+|---|---|---|
+| `kc:Complex` (instance graph) | MMS model/branch | A KC export is a self-contained RDF graph that can be committed as an MMS model revision |
+| `kc:boundedBy`, `kc:hasElement` | MMS element relationships | Topological structure is expressed as standard RDF triples |
+| SHACL shapes (`kc_core_shapes.ttl` + user shapes) | MMS validation profiles | Shapes can be registered in MMS to enforce KC constraints on committed models |
+| `kc:uri` | MMS element cross-references | Provides traceability from KC elements to external artifacts (files, documents, URIs) |
+| JSON-LD export (`dump_graph(format="json-ld")`) | MMS ingest format | JSON-LD is the primary API format for Flexo MMS |
+
+### Integration patterns
+
+**Push to MMS:** Export a KC instance via `kc.export()` or `dump_graph(format="json-ld")`, then commit to a Flexo MMS repository via its REST API. The OWL ontology and SHACL shapes can be committed alongside the instance data, enabling MMS-side validation.
+
+**Pull from MMS:** Retrieve a model revision as JSON-LD from Flexo MMS, then load it into a KC instance via `load_graph(kc, "model.jsonld")`. The KC's SHACL verification (`kc.verify()`) ensures the imported data satisfies all topological and ontological constraints.
+
+**Version control:** MMS provides branching, diffing, and merge capabilities at the RDF triple level. KC's `ComplexDiff` and `ComplexSequence` classes complement this by providing simplicial-complex-aware diffing (element-level adds/removes rather than triple-level changes).
+
+### What KC adds beyond MMS
+
+Flexo MMS manages RDF models generically — it stores, versions, and queries them but does not enforce simplicial complex structure. KC adds the topological layer: boundary-closure, closed-triangle constraints, typed simplicial hierarchy, and algebraic topology computations (Betti numbers, Hodge decomposition). Together, MMS provides the model management infrastructure and KC provides the mathematical structure.
+
+### Reference
+
+OpenMBEE (Open Model-Based Engineering Environment) is an open-source community developing tools for model-based systems engineering. Flexo MMS is its core model management system. See [openmbee.org](https://www.openmbee.org/) and [github.com/Open-MBEE](https://github.com/Open-MBEE).
+
+---
+
+## Deployment Architecture
+
+The internal design described above (2x2 map, component layers, static resources) is the library's foundation. In practice, a knowledge complex is deployed through a stack of five layers, each building on the one below:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  5. LLM Tool Integration                                    │
+│     Register KC operations as callable tools for a language  │
+│     model. The complex serves as a deterministic expert      │
+│     system — the LLM navigates, queries, and analyzes via    │
+│     tool calls; the KC guarantees topological correctness    │
+│     and returns structured, verifiable results.              │
+├─────────────────────────────────────────────────────────────┤
+│  4. MCP Server                                               │
+│     Model Context Protocol server exposing KC as tools for   │
+│     AI assistants (Claude, etc.). Each KC operation becomes   │
+│     a tool: add_vertex, boundary, betti_numbers, audit, etc. │
+├─────────────────────────────────────────────────────────────┤
+│  3. Microservice (REST API)                                  │
+│     Python-hosted service exposing KC operations over HTTP.   │
+│     CRUD for elements, SPARQL query execution, SHACL         │
+│     verification, algebraic topology analysis, export/import.│
+├─────────────────────────────────────────────────────────────┤
+│  2. Concrete Knowledge Complex                               │
+│     An instance using a specific ontology. Typed vertices,   │
+│     edges, and faces with attributes. SHACL-verified on      │
+│     every write. Serialized as RDF (Turtle, JSON-LD).        │
+│     Versioned via Flexo MMS or git.                          │
+├─────────────────────────────────────────────────────────────┤
+│  1. KC-Compatible Ontology                                   │
+│     OWL class hierarchy extending kc:Vertex/Edge/Face.       │
+│     SHACL shapes for attribute constraints. Publicly hosted  │
+│     at persistent URIs (w3id.org). Dereferenceable — tools   │
+│     can fetch the ontology and understand the type system.    │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### Layer 1: Ontology
+
+A KC-compatible ontology is an OWL ontology whose classes extend `kc:Vertex`, `kc:Edge`, and `kc:Face`, paired with SHACL shapes for instance-level constraints. Ontologies are authored via `SchemaBuilder` and exported as standard `.ttl` files. For public use, the ontology should be hosted at a persistent URI (e.g. `https://w3id.org/kc/`) so that other systems can dereference the IRI and retrieve the OWL/SHACL definitions. The `knowledgecomplex.ontologies` package ships three reference ontologies (operations, brand, research) as starting points.
+
+### Layer 2: Concrete Complex
+
+A concrete knowledge complex is an RDF instance graph conforming to a specific ontology. It contains typed elements (vertices, edges, faces) with attributes, linked by `kc:boundedBy` and collected by `kc:hasElement`. SHACL verification enforces topological and ontological constraints on every write. The complex is serializable to Turtle, JSON-LD, or N-Triples and can be versioned via Flexo MMS or committed to a git repository as `.ttl` files.
+
+### Layer 3: Microservice
+
+A Python-hosted HTTP service wraps the `KnowledgeComplex` API in a REST interface. Typical endpoints: element CRUD, named SPARQL queries, topological operations (boundary, star, closure), algebraic topology analysis (Betti numbers, Hodge decomposition, edge PageRank), SHACL verification and audit, and schema introspection. The service loads a schema at startup and manages one or more complex instances.
+
+### Layer 4: MCP Server
+
+A [Model Context Protocol](https://modelcontextprotocol.io/) server exposes KC operations as tools that AI assistants can call. Each KC method becomes an MCP tool: `add_vertex`, `boundary`, `find_cliques`, `betti_numbers`, `audit`, etc. The MCP server is a thin adapter over the microservice or the library directly, translating between MCP tool calls and KC Python API calls.
+
+### Layer 5: LLM Tool Integration
+
+The knowledge complex is registered as a set of callable tools for a language model. The LLM uses the complex as a **deterministic expert system** — it navigates the simplicial structure, retrieves typed elements and their attributes, runs topological queries, and performs algebraic topology analysis via tool calls. The KC guarantees that every result is topologically valid and SHACL-verified. The LLM provides natural language understanding and reasoning; the KC provides structured, auditable, mathematically rigorous retrieval.
+
+This separation is key: the LLM handles ambiguity, intent, and synthesis; the KC handles structure, correctness, and computation. Neither replaces the other.
+
+---
+
+## Namespace Conventions
+
+```turtle
+@prefix kc:   <https://example.org/kc#> .       # core framework
+@prefix kcs:  <https://example.org/kc/shape#> . # core shapes
+@prefix aaa:  <https://example.org/aaa#> .      # user namespace (example)
+@prefix aaas: <https://example.org/aaa/shape#> .# user shapes (example)
+```
+
+User namespaces are set via `SchemaBuilder(namespace="aaa")`. The URI base `https://example.org/` is a placeholder for local development; a real deployment would use a dereferenceable IRI.
+
+---
+
+## File Inventory
+
+| File | Layer | Purpose |
+|---|---|---|
+| `knowledgecomplex/resources/kc_core.ttl` | Abstract OWL | Topological backbone: classes, properties, cardinality axioms, `kc:uri` |
+| `knowledgecomplex/resources/kc_core_shapes.ttl` | Abstract SHACL | Topological constraints: distinctness, closed-triangle, boundary-closure, `kc:uri` at-most-one |
+| `knowledgecomplex/schema.py` | Python API — schema authoring | `SchemaBuilder` DSL: `add_*_type`, `dump_owl`, `dump_shacl`, `export`, `load` |
+| `knowledgecomplex/graph.py` | Python API — instance I/O | `KnowledgeComplex`: `add_vertex`, `add_edge`, `add_face`, `query`, `dump_graph`, `export`, `load` |
+| `knowledgecomplex/exceptions.py` | Public exceptions | `ValidationError`, `SchemaError`, `UnknownQueryError` |
+| `knowledgecomplex/io.py` | Python API — serialization | `save_graph`, `load_graph`, `dump_graph` — multi-format file I/O (Turtle, JSON-LD, N-Triples) |
+| `knowledgecomplex/viz.py` | Python API — visualization | Hasse diagrams (`plot_hasse`), geometric realization (`plot_geometric`), `to_networkx`, `verify_networkx` |
+| `knowledgecomplex/analysis.py` | Python API — algebraic topology | `betti_numbers`, `euler_characteristic`, `hodge_laplacian`, `edge_pagerank` (optional: numpy, scipy) |
+| `knowledgecomplex/clique.py` | Python API — clique inference | `find_cliques`, `infer_faces`, `fill_cliques` — flagification and typed face inference |
+| `knowledgecomplex/filtration.py` | Python API — filtrations | `Filtration` — nested subcomplex sequences, birth tracking, `from_function` |
+| `knowledgecomplex/diff.py` | Python API — diffs and sequences | `ComplexDiff`, `ComplexSequence` — time-varying complexes with SPARQL UPDATE export/import |
+| `knowledgecomplex/codecs/markdown.py` | Codec — markdown files | `MarkdownCodec` — YAML frontmatter + section-based round-trip; `verify_documents` |
+| `knowledgecomplex/queries/*.sparql` | Framework SPARQL | 7 templates: vertices, coboundary, boundary, star, closure, skeleton, degree |

knowledgecomplex-0.1.0/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.