The Linked Data Object Model (LDOM) and the Web Ontology Language (OWL) are both data modeling languages based on Semantic Web technology. This document attempts to clarify the relationship between those languages, explain the differences and possible mappings between the overlapping features.
LDOM (Linked Data Object Model) is a modeling language for linked data, based on a minimum sub-set of RDF Schema and object-oriented principles. OWL is also based on RDF Schema, and provides similar features such as cardinality and value type restrictions.
...
Explain choice of OWA and !UNA in OWL vs CWA and UNA in LDOM. OWL mostly designed for classification tasks, LDOM for validation. OWL for knowledge representation, LDOM for data models.
OWL inferencing (and general subsumption) is out of scope in LDOM. LDOM only operates on RDF dataset level, and whatever triples are queryable by the SPARQL patterns. This means that LDOM can in principle be applied to any dataset that was OWL inferencing activated.
The semantics of the templates and functions used by LDOM language are well-defined using SPARQL. LDOM is largely written in itself, and no additional "hard-coded" engine such as an OWL inference engine is needed. LDOM is naturally extensible, while OWL has no such extension mechanism.
For the remainder of this document we assume OWL with a closed-world interpretation, no inferences.
Mention that a closed-world interpretation of many of the OWL terms can be implemented via LDOM constraints.
Conventions: OWL snippets are in color for OWL while LDOM code snippets are in color for LDOM.
LDOM and OWL class definitions are very compatible with each other.
LDOM classes are instances of the metaclass rdfs:Class.
owl:Class is a subclass of rdfs:Class, which
means that every OWL class is also an LDOM class.
TODO: is every rdfs:Class also a valid OWL class?
The interpretation of rdfs:subClassOf is equivalent in both
languages: a subclass relationship means that each instance of a subclass
is also an instance of a superclass.
An LDOM engine uses these superclass relationships to determine which
constraints to execute on which instances.
The fact that LDOM shares the same class definitions means that existing OWL classes can be extended with LDOM declarations, and vice versa. Users can chose which constraints to enforce, while the same class declarations, their labels, comments and instances can be shared between both interpretations.
OWL has other class axioms which do not have special meaning in LDOM.
owl:equivalentClass can be converted into mutual rdfs:subClassOf
triples. owl:disjointWith etc are not relevant under UNA.
LDOM and OWL share a similar syntax in which properties are attached to classes. This is illustrated in the following example:
ex:Rectangle a owl:Class ; rdfs:subClassOf owl:Class ; rdfs:label "Rectangle" ; rdfs:comment "A rectangle, based on width and height." ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty ex:width ; owl:allValuesFrom xsd:integer ; ] ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty ex:width ; owl:maxCardinality 1 ; ] ; ldom:property [ ldom:predicate ex:width ; ldom:valueType xsd:integer ; ldom:maxCount 1 ; ] ; .
The example above illustrates the frequently used design pattern based on
owl:Restriction combined with rdfs:subClassOf
to declare characteristics of property values at a given class.
In LDOM this same pattern uses the property ldom:predicate
to point to an ldom:PropertyConstraint (which is implicit and
can therefore be skipped).
A difference is that in LDOM property constraints, multiple characteristics
such as ldom:valueType and ldom:maxCount are typically
combined into the same node, while in OWL such structure sharing is not a good
practice (needs confirmation/reference).
The example also shows that OWL and LDOM declarations can be used alongside with each other - LDOM definitions are ignored by OWL engines, and OWL syntax is ignored by LDOM engines, unless an OWL model for LDOM has been included as a library.
Both languages share the interpretation that subclasses may narrow down restrictions declared at their superclasses. Likewise, any restriction defined in superclasses must also apply to subclasses.
OWL has the concept of rdfs:domain which can be used to infer
class membership from the presence of properties at an instance.
There is no comparable mechanism in LDOM - instead the attachment of
properties to classes is declared via ldom:property.
Constraint scenarios not covered by the built-in templates of LDOM can be expressed either through custom templates or complex constraints, both based on SPARQL queries. SPARQL's rich expressivity means that highly complex graph patterns can be checked.
LDOM follows object-oriented design principles that make it easy and arguably more natural to map LDOM class definitions to models in other mainstream languages.
Leaving aside Open-World Assumption and Unique Name Assumption, LDOM and
OWL have almost identical syntax to represent cardinalities.
If unspecified, both languages assume that a property may have zero to
indefinite values for a given property.
OWL has the global axiom owl:FunctionalProperty that has
no syntactic equivalent in LDOM, but would need to be represented using
ldom:maxCount 1.
OWL has owl:cardinality as short-cut for min and max,
which does not exist (yet) for LDOM. May be added to LDOM, if only
for the common case of min/max = 1.
For any shape property with a stated ldom:minCount, conforming graph nodes have a restriction on that property with an owl:minCardinality of that value.
For any shape property with a stated ldom:maxCount, conforming graph nodes have a restriction on that property with an owl:maxCardinality of that value.
A ldom:minCount of 0 asserts that the property is recognized [[@@section on recognized properties in closed shapes]].
An unspecified ldom:maxCount indicates no upper constraint on cardinality.
In OWL, global rdfs:range axioms narrow down the
value space of a property independently of the class where it is used.
LDOM does not have such global axioms, but rather focuses on an
object-oriented world-view in which properties are attached to classes.
OWL uses owl:allValuesFrom to state that if a property
has values, then they are assumed to be instance of the provided class
or datatype.
LDOM has two mechanisms to express something similar:
ldom:valueType links a property (at a class) to a
single named class or datatype
ldom:all links a property (at a class) to a potentially
complex shape declaration that may include recursive property constraints
ldom:valueType is meant to be a simple declarative
vocabulary that can be used to drive input forms etc while
ldom:all may provide additional constraints that also need
to be verified.
For any shape property with a stated ldom:valueType of some datatype, conforming graph nodes have a restriction on that property: a datatype property restriction of all values from that datatype.
For any shape property with a stated ldom:valueType of some non-datatype, conforming graph nodes have a restriction on that property: an ObjectAllValuesFrom of a class expression with an ObjectHasValue restriction on the predicate rdf:type and a value of the ldom:valueType.
I believe these should be split into two properties. How do I know what is or isn't a datatype property without a schema? - ericP
OWL provides owl:someValuesFrom to specify that at least one
of the values of a property is assumed to be an instance of a given class.
LDOM includes ldom:some with very similar interpretation.
OWL includes owl:hasValue to state that one of the values
of a property must be semantically equivalent to the provided value.
This is not directly covered by LDOM templates, but can be expressed
through a custom template or SPARQL query.
OWL includes owl:oneOf axioms to exhaustively enumerate
the members of a class. This can be used in conjunction with
owl:allValuesFrom to narrow down the value space of
a property at a class.
The comparable structure in LDOM is ldom:allowedValues
which points to a set of enumerated values.
A difference is that the LDOM enumerations are neither sorted nor
closed (owl:oneOf points at rdf:Lists).
For any shape property with some ldom:allowedValues, conforming graph nodes have a restriction on that property: for datatype properties, a DataOneOf with the set of literals in the object of ldom:allowedValues; for object properties, an ObjectOneOf with the set of individuals in the object of ldom:allowedValues
Talk about rdfs:Datatypes etc.
OWL is based around class definitions. Complex conditions can be expressed
by combining owl:Restriction via owl:intersectionOf,
owl:unionOf etc.
These class definitions can be linked as necessary conditions via
rdfs:subClassOf or sufficient conditions via owl:equivalentClass.
LDOM includes two mechanisms to represent such complex constraints:
ldom:ShapeConstraint and ldom:all and ldom:some
may point to (nested) class definitions using the high-level language of
LDOM templates. ldom:OrConstraint can be used to express
union shapes.
ldom:constraint and ldom:sparql may point at an
arbitrary SPARQL query, making use of the advanced expressivity to represent
conditions that cannot be covered by pre-defined patterns.
A reasonable mapping between shape constraints and OWL class expressions may be possible. A mapping from OWL class definitions to SPARQL is often straight-forward, while the inverse direction from SPARQL to OWL is prohibitively difficult to impossible, for example due to the lack of the concept of variables, lack of math and string operations, aggregations and many other features.
For any shape property with some complex constraints, conforming graph nodes have a restriction on that property composed by recursively evaluating the referenced constructs.
Both OWL and LDOM include features to encapsulate shape definitions into named entities.
OWL class definitions may have a URI that is referenced via owl:allValuesFrom,
rdfs:subClassOf etc.
In LDOM, complex conditions can either be referenced via ldom:all or
rdfs:subClassOf, or encapsulated into templates.
LDOM templates can be parameterized with arguments, a feature that does not exist in OWL.
LDOM also includes a feature to encapsulate a piece of logic into SPARQL functions, so that they can be reused and parameterized in multiple places.
OWL has a property owl:imports that links one graph with other graphs that
shall be included for inferencing.
LDOM uses a separate property ldom:include to make sure that developers can
select which graphs to select under which context.
Furthermore, LDOM has a property ldom:library to establish a weaker connection
between a graph and its constraints, templates and functions.
There is no such equivalent in OWL.