[Om] Content Dictionary for Linked Data with RDF

Wenzel, Ken Ken.Wenzel at iwu.fraunhofer.de
Mon Mar 5 14:22:32 CET 2012

Hi Andrew,

thank you for your extensive reply.

> (1)
> I've been thinking about this for a long time, but so far I haven't
> done anything about it. In 2009, I made a blog post about it:
> http://straymindcough.blogspot.com/2009/06/semantic-mathml.html in
> which I discuss the opposite direction (OM/SCMML to RDF) than we seem
> to be discussing here (RDF to OM/SCMML). That post was supposed to be
> a discussion, apologies to Christoph for not responding.

I've stumbled upon your post some time ago but missed somehow to join the discussion.
We've also created an ontology for representing mathematical expressions
as RDF. 
For this reason we simply mapped the existing OM constructs to OWL classes and

Ontology: <http://numerateweb.org/vocab/math>

ObjectProperty: attributeValue
ObjectProperty: body
ObjectProperty: variables
ObjectProperty: binder
ObjectProperty: arguments
ObjectProperty: attributeKey
ObjectProperty: target
ObjectProperty: symbol
DataProperty: encoding
DataProperty: value
DataProperty: name
Class: Object
Class: Application
        arguments only ObjectList,
        symbol exactly 1 owl:Thing,
        arguments max 1 owl:Thing,
        symbol only Symbol

Class: Attribution
        arguments only AttributionList,
        target only Object,
        target exactly 1 owl:Thing,
        arguments max 1 owl:Thing

Class: Binding
        body only Object,
        binder only Object,
        variables only VariableList,
        variables max 1 owl:Thing,
        binder exactly 1 owl:Thing,
        body exactly 1 owl:Thing
Class: Compound
Class: Foreign
        encoding exactly 1 rdfs:Literal,
        encoding only xsd:string,
        value only rdf:XMLLiteral,
        value exactly 1 rdfs:Literal

Class: Literal
        value exactly 1 rdfs:Literal
Class: Symbol

Class: Variable
        name exactly 1 rdfs:Literal,
        name only xsd:string,

Class: AttributionPair
        attributeValue exactly 1 owl:Thing,
        attributeKey exactly 1 owl:Thing,
        attributeValue only Object,
        attributeKey only Symbol

This ontology enables us to represent arbitrary OM objects as RDF.
The basic idea is mainly the same as yours despite the fact that
we've introduced classes for Applications, Bindings, Attributions, etc.

Your example

<m:apply> Symbol Content* </m:apply>
[] sm:apply Symbol ; sm:applyTo LIST(Content)

would be represented in our ontology as

@prefix nw: <http://numerateweb.org/vocab/math#>
[] a nw:Application ; nw:symbol Symbol ; nw:arguments LIST(Content)

which is almost identical since we both used a "verbatim" mapping
of SCML/OM to RDF.

This approach has the advantage that it is easy to convert between
SCML/OM and RDF. The drawback is that the specification of 
allowed argument types for applications (comparable to OM STS)
is a bit complicated.

If we have for example

plus a nw:Symbol

we could implement type checking by (with Manchester syntax)

PlusApplication owl:equivalentClass "nw:symbol value plus"
PlusApplication rdfs:subClassOf "
  nw:arguments only (rdf:first some NumericValue and 
    rdf:next some (rdf:first some NumericValue))

Another approach could be to make "plus" a
subclass of Symbol that would allow us to attach the
restrictions directly to "plus" instead of introducing 
the helper class "PlusApplication".

> (2)
> Identifier mappings have been, and always will be, nontrivial. We know
> all OMSymbols have a standard map to URI, and that any QName has at
> least 2 semi-common maps to a URI: {ns}/{local} and {ns}#{local}.
> Mapping from a URI to a QName is much easier, just look for / or # and
> reverse the process. Mapping a URI to an OMSymbols might be as simple
> as Christoph suggests, but this ignores URNs which do not have any /
> characters. I see two possible solutions to this: (3) special-case
> RDF, or (4) extend OM semantics to match SCMML3.

I would prefer treating RDF as a special kind of math
expression which is exactly what the "resource" symbol 
from the RDF CD 


The advantage of this approach is that it does not break
existing OM vocabulary and allows us to stick with
numbers and strings for primitive types 
(without introducing e.g. a special type for IRIs).

Also Tools like text editors (e.g. Popcorn based) or graphical formula editors
(Mathdox formula editor) are immediately enabled to work with RDF.

> (3)
> If we are going to treat RDF as a special case, then we should include
> all URIs traditionally associated with the rdf: and rdfs: prefixes
> with a single CD called 'rdf' (so we could use <OMS cd="rdf"
> name="type"/> without a nonstandard cdbase). 

I don't know if it's a good idea to mirror existing RDF
definitions in OpenMath. Future OpenMath tools that are RDF-aware
should be enabled to interpret external RDF resources (ontologies)
and their definitions.

> [...]
> How would each graph be converted into OM? Do all graphs correspond do
> a set of OMATTRs? In my opinion, blank nodes should be treated
> differently, converting to values rather than references, but this
> cannot be done in the most general case because of repeated predicates
> and repeated objects. I don't have a general solution, but I look
> forward to hearing discussions on this.

Christoph asked a similar question. 
Maybe it is possible to reuse the vocabulary of "set1" and "relation1" for this task:

set1.in("This is a comment.", rdf.valueset("rdfs:comment", rdf.resource("foaf:Person")))
relation1.eq(rdf.value("rdfs:comment", rdf.resource("foaf:Person")), "This is the only comment.")

Blank nodes could be either referenced by their ID as rdf.resource("_:node0815") or
they can be converted into a set of statements using the technique mentioned above.

> [...] 
> Consider if special semantics are attached to the case when the cd
> attribute is specified, but is empty. Consider also modifying the
> section of the OM standard "Canonical URIs for Symbols" to the effect
> that if {cd} is empty, then the canonical URI for the OMSymbol is:
>   URI = cdbase-value + name-value

This seems like a viable solution. 

I think that an even better solution for the OpenMath XML serialization
could be to get rid off the CDBASE definitions and simply use standard
xmlns declarations for this task:

<OMA xmlns:set1="http://www.openmath.org/cd/set1#">
  <OMS name="set1:in" />

This approach is also used by RDFa and works very well.

> Thank you for your time, and forgive any mistakes I might have made.

I also have to thank for your time and your valuable comments on this topic.

Best regards,


More information about the Om mailing list