Data Properties

Overview

A data property is an ontology-typed node attribute with a typed value. It has an optional DOMAIN (the class that may carry the attribute) and an optional RANGE that is an XSD datatype (xsd:string, xsd:integer, etc.).

Data properties attach to nodes only. Edge attributes (e.g., weight: 0.7 on a :Knows edge) are stored as plain LPG properties. This matches OWL DL semantics, where owl:DatatypeProperty has rdfs:domain ranging over owl:Class, which is instantiated by node-equivalent individuals.

Creating Data Properties

Syntax
<create data property statement> ::=
  "CREATE DATA PROPERTY" <data property name> 
  [ "DOMAIN" <class> ] [ "RANGE" <xsd type> ] [ "FUNCTIONAL" | <cardinality> ]

<xsd type> ::= "xsd:" <type name>

<cardinality> ::= "CARDINALITY" <cardinality range>

<cardinality range> ::=
    "{" <min> "," <max> "}"    -- both bounds explicit
  | "{" <min> "," "*"   "}"    -- min only, unbounded max
  | "{" <min> ","       "}"    -- min only, unbounded max
  | "{"       "," <max> "}"    -- max only, min defaults to 0
  | <n>                        -- exact, equivalent to {n,n}

Details

• Data properties do not have an inline DDL form for SUBPROPERTY OF like object properties. Hierarchies between data properties can still be expressed by importing an OWL / Turtle file that declares rdfs:subPropertyOf axioms via LOAD ONTOLOGY; the engine stores and respects those rollups when queries hit a super-property.

Basic Form

GQL
-- String property @ex:name on @ex:Agent nodes
CREATE DATA PROPERTY @ex:name DOMAIN @ex:Agent RANGE xsd:string

-- When DOMAIN is omitted, the property doesn't have a class to anchor to
-- Any node can carry tag, still validated as xsd:string
CREATE DATA PROPERTY @ex:tag RANGE xsd:string

-- When RANGE is omitted, the validator skips XSD type-checking of the value.
-- The attribute is restricted to @ex:Document, but the value can be any type
CREATE DATA PROPERTY @ex:metadata DOMAIN @ex:Document

Supported XSD Types

CARDINALITY

Data properties accept the same CARDINALITY clause as object properties:

GQL
-- Required, single-valued: every Person must have exactly one name
CREATE DATA PROPERTY @ex:fullName
  DOMAIN @ex:Person RANGE xsd:string
  CARDINALITY 1

-- Multi-valued: a Person may carry up to 3 email addresses
CREATE DATA PROPERTY @ex:email
  DOMAIN @ex:Person RANGE xsd:string
  CARDINALITY {,3}

-- Unbounded: zero or more tags
CREATE DATA PROPERTY @ex:tag
  DOMAIN @ex:Document RANGE xsd:string
  CARDINALITY {0,}

FUNCTIONAL

FUNCTIONAL is the only OWL characteristic that applies to data properties. It's the shorthand for CARDINALITY {0,1} (at most one value):

GQL
-- A person has at most one primary email
CREATE DATA PROPERTY @ex:primaryEmail
  DOMAIN @ex:Person RANGE xsd:string
  FUNCTIONAL

Using Data Properties

A data property is written by its local name, with the prefix omitted. So the data property @ex:age becomes the plain attribute key age, the same on INSERT and in MATCH (RETURN n.age). The value is validated against the property's RANGE.

GQL
-- Every Person must have exactly one integer-valued age
CREATE DATA PROPERTY @ex:age 
  DOMAIN @ex:Person RANGE xsd:integer 
  CARDINALITY {1,1}

-- Insert Person with integer-valued age
INSERT (@ex:Person {name: 'Alice', age: 30})

-- Insert Person with string-valued age
-- Type validation error (or warning, depending on enforcement mode)
INSERT (@ex:Person {name: 'Bob', age: 'thirty'})

-- Insert Person without age
-- Cardinality validation error (or warning, depending on enforcement mode)
INSERT (@ex:Person {name: 'Sam'})

A multivalued data property (CARDINALITY {,3}, {0,}, etc.) is written as a list literal. All values are assigned at once, not one at a time:

GQL
-- Up to 3 emails (CARDINALITY {,3}): assign them as a list
INSERT (@ex:Person {name: 'Alice', email: ['[email protected]', '[email protected]']})

-- A 4th value exceeds CARDINALITY {,3}
-- Cardinality validation error (or warning, depending on enforcement mode)
INSERT (@ex:Person {name: 'Eve', email: ['[email protected]', '[email protected]', '[email protected]', '[email protected]']})

The stored shape follows the data, not the declaration: assign several values and the property holds a list; assign a single value and it stays a scalar (a {,3} bound permits a list, it doesn't force one). So email may be a string on one Person and a list on another; query the scalar case with n.email = 'x' and the list case with 'x' IN n.email. SET n.email = [...] replaces the whole value rather than appending, so to add to an existing list, re-assign the full list.

Attributes whose local name doesn't match any declared data property are stored as plain LPG properties without ontology validation.

Showing Data Properties

GQL
SHOW DATA PROPERTIES

-- Filter by ontology prefix
SHOW DATA PROPERTIES FROM foaf

Example output:

Dropping Data Properties

GQL
DROP DATA PROPERTY @ex:tempField

DROP DATA PROPERTY does not touch any existing node attributes that use the property's local name, they remain in the graph as plain LPG properties, no longer subject to ontology validation. The attribute remains queryable via MATCH (n) RETURN n.tempField.

What stops applying after the drop:

• XSD type-checking against the property's RANGE: new inserts may carry any value type for that attribute.
• DOMAIN enforcement: the attribute can now be attached to nodes of any class.
• CARDINALITY and FUNCTIONAL constraints: multi-value bounds stop firing.

If you want a clean teardown, strip the attribute from existing nodes first, then drop the schema:

GQL
-- Remove the attribute from every node that carries it
MATCH (n) WHERE n.tempField IS NOT NULL REMOVE n.tempField

-- Then drop the ontology definition
DROP DATA PROPERTY @ex:tempField