HighlightMicrosoft Learn

Fabric lakehouse schemas group tables for access and four-part SQL

Microsoft Fabric docs on lakehouse schemas for domain grouping, schema-level access, cross-workspace queries, and schema shortcuts to external Delta.

Lakehouse schemas in Microsoft Fabric group tables into named collections such as sales or hr. Schema-enabled lakehouses support domain browsing, schema-level access with row- and column-level security, four-part workspace.lakehouse.schema.table queries, schema shortcuts to other lakehouses or ADLS Gen2, and features such as materialized lake views. Schema names allow only letters, numbers, and underscores; dbo is the default under Tables.

Based on: Lakehouse schemas - Microsoft Fabric · Microsoft Learn

HighlightDatabricks

Unity Catalog tags for search, ABAC inheritance, and governed keys

Databricks docs on applying key-value tags to Unity Catalog securable objects, including ABAC inheritance behavior and governed tags.

Tags on Unity Catalog securables are key attributes with optional values used to organize objects and improve workspace search for tables and views. Tag text is stored as plain text and may replicate globally, so sensitive content must not go in tags. For ABAC evaluation, tags on higher objects implicitly apply beneath them but not to columns; governed tags add account-level allowed keys and rules.

Based on: Apply tags to Unity Catalog securable objects | Databricks on AWS · Databricks

HighlightGoogle Cloud

Design BigQuery policy-tag trees around few data classes

Google Cloud best practices for BigQuery policy-tag hierarchies used in column-level access control and dynamic data masking.

Policy tags define access for column-level control and dynamic masking and are presented as an alternative to Resource Manager data governance tags. The guidance is to model a small set of business data classes, map many columns to few tags, and align tags with groups that need different access. Tags can form a tree, often under a root, with an example High/Medium/Low taxonomy and leaf tags such as Credit card and Government ID.

Based on: Best practices for using policy tags in BigQuery | Google Cloud Documentation · Google Cloud

HighlightGoogle Cloud

BigQuery column security via policy and governance tags

Google Cloud intro to BigQuery column-level access control using policy tags or data governance tags, IAM checks at query time, and optional masking.

BigQuery restricts sensitive columns with policy tags from Data Catalog or data governance tags from Resource Manager. Policies are evaluated at query time; optional dynamic masking can replace values with null, default, or hashed content. The workflow is taxonomy and tags, schema annotations on columns, enforce access on the taxonomy, then IAM on each tag, in addition to dataset ACLs.

Based on: Introduction to column-level access control | BigQuery | Google Cloud Documentation · Google Cloud

HighlightSnowflake

Snowflake tags as schema-level key-value labels for governance

Snowflake docs on object tags: schema-level key-value pairs assignable across object types, with inheritance, propagation, and queryable governance use.

A Snowflake tag is a schema-level object stored as a string key-value pair and assigned to other objects. Objects may carry multiple tags; one tag may apply to different object types; values may be shared or unique per assignment. Tags support inheritance down the securable hierarchy, optional automatic propagation, replication of assignments, and centralized or decentralized administration for auditing and reporting.

Based on: Introduction to object tagging | Snowflake Documentation · Snowflake

HighlightSnowflake

Snowflake classifies columns into semantic and privacy categories

Snowflake Enterprise docs on sensitive data classification, native and custom categories, tags, and Trust Center setup.

Sensitive data classification (Enterprise Edition or higher) automatically discovers sensitive columns and supports governance controls such as tags and masking policies. Each identified column gets a semantic category (e.g., name, national identifier, or custom) and a privacy category (IDENTIFIER, QUASI_IDENTIFIER, or SENSITIVE). Setup and results go through Trust Center; Snowsight can recommend databases likely to hold sensitive data.

Based on: Introduction to sensitive data classification | Snowflake Documentation · Snowflake

HighlightNeo4j

Neo4j graph modeling ties domain questions to storage shape

Neo4j getting-started overview of graph data modeling steps from domain use cases through test, Cypher load, and refactor.

Graph data modeling defines query logic and stored structure; a well-designed model improves performance, flexibility, and storage use. The process covers understanding the domain and use-case questions, extracting entities and relationships, testing against an initial model, loading test data with Cypher, measuring performance, and refactoring as use cases change.

Based on: What is graph data modeling? - Getting Started · Neo4j

HighlightNeo4j

Neo4j constraints enforce uniqueness, existence, type, and keys

Neo4j Cypher manual listing property uniqueness, existence, type, and key constraints, and preferring graph types for schema.

Neo4j provides property uniqueness, existence (Enterprise), type (Enterprise), and key (Enterprise) constraints on nodes by label or relationships by type. Older CREATE CONSTRAINT syntax still adds constraints to a database’s graph type, but the docs recommend defining schema via graph types for richer constraint kinds and simpler long-term maintenance.

Based on: Constraints - Cypher Manual · Neo4j

HighlightStanford Center for Biomedical Informatics Research

Protégé is Stanford’s free OWL 2 editor for desktop and collaborative web work

Protégé homepage: open-source OWL ontology editor (Desktop and WebProtégé), used on OBO Foundry, WHO ICD-11, and NCI Thesaurus.

Protégé is a free, open-source OWL ontology editor from Stanford, available as Protégé Desktop and WebProtégé. It supports the OWL 2 lifecycle from modelling through reasoning, querying, and collaboration. Notable uses include OBO Foundry ontologies, WHO ICD-11 development, and the NCI Thesaurus.

Based on: Protégé · Stanford Center for Biomedical Informatics Research

HighlightLinkML / Berkeley Bioinformatics Open Source Projects

LinkML authors YAML schemas that compile and validate across JSON, RDF, and TSV

LinkML documentation: a Linked Data Modeling Language for YAML schemas, multi-format validation, and generators into other frameworks.

LinkML is a flexible modeling language for authoring YAML schemas that describe data structure. It is also a framework for working with and validating data in formats such as JSON, RDF, and TSV, with generators that compile schemas to other frameworks. It is Apache-2.0 licensed and community-driven.

Based on: linkml documentation · LinkML / Berkeley Bioinformatics Open Source Projects

HighlightSchema.org

Schema.org’s model: multi-inheritance types, multi-domain properties, not a world ontology

Schema.org documentation of its RDF Schema–derived data model: types, properties with multiple domains and ranges, and limits on scope.

Schema.org’s data model is generic and derived from RDF Schema. Types form a multiple-inheritance hierarchy; properties may have multiple domains and ranges for pragmatic reasons. The project is not intended as a universal ontology and expects use alongside other vocabularies that share the same basic model and standards such as JSON-LD, Microdata, and RDFa.

Based on: Data model - Schema.org · Schema.org

Highlightdbt Labs

Groups bind DAG nodes to a named owner and private-access boundary

dbt documentation on declaring groups in YAML to organize nodes and restrict access to private models.

A group is a named collection of nodes in a dbt DAG with a required owner. Groups support intentional collaboration by restricting access to private models. Members may include models, tests, seeds, snapshots, analyses, and metrics, but not sources or exposures, and each node belongs to only one group. Groups are declared under a groups key; name and owner are required, with optional description and meta in later versions.

Based on: Add groups to your DAG | dbt Developer Hub · dbt Labs