Review of previous posts

In this post, I'm going to be reviewing my old posts with what I've learned over the past few years. The purpose behind this analysis is to consolidate my ideas into fewer ideas and hopefully come up with some new insights along the way.

This was my first post about XML entity references. The goal was to restrict the DTD grammar to only entities so facilitate usage in other applications that have no concern about elements and attribute lists. Now I would recommend using only DTD since its usage is widespread. I was considering folding this into a macro system I was planning to write, so that one could replace © with © just as easily as it could replace sqrt(4) with 2. I've come to the conclusion that this post was premature, and needs to be included in a more detailed discussion about macro systems, and templating systems such as M4, Genshi, Mustache, and many others.

This was an example of binary parsing, which is still not possible in many languages, but a topic more suited to C structs. GCC has a large number of attributes and packing parameters that accomplish some of the goals of binary parsing, but I still haven't found a good binary parsing framework to date.

This was a bunch of things trying to make Go something that it wasn't. I have since found the Rust programming language, which has all the features I was looking for in this post and more. So, now I would recommend using Rust.

These posts were just crazy comments.

The following posts were all about RDF:

This was a comment primarily intended to allow for arbitrary Common Lisp lists to be represented in RDF.

This was a comment as well, and I still haven't found a datatype URI for this, perhaps something for a future article.

This is interesting because there isn't an XSD datatype associated with large finite-size integers, although you could define it as xsd:integer, then restrict the domain until it matches int128_t. I have since defined a URI for this on my other website.

This was fun. I have since written about these algorithms on my other website.

This is a type of post I'd like to write more of. You know, explaining the pros and cons of certain implementation techniques and why one is better or worse than the other.

This was attempting to illustrate the inconsistencies that I found between different XML standards.

This and this were comments about The Web. I would like to add that I've started to use unqualified identifiers to refer to RDF and OWL core concepts in my private notes:

• Type = rdfs:Class
• ObjectType = owl:Class
• DataType = rdfs:Datatype
• Property = rdf:Property
• ObjectProperty = owl:ObjectProperty
• DataProperty = owl:DataProperty

The following posts were unintentionally about Data URIs:

This was attempting to solve a problem that Data URIs already solve. Now I recommend using Data URIs instead.

This was a good comment, but I don't recommend these namespaces anymore. Now I recommend using Data URIs instead, for example:

<data:text/x-scheme;version=R5RS,vector-length>

This mentions a problem regarding xsd:hexBinary and xsd:base64Binary, which can be solved in several ways:

1. Candle assigned the type identifier "binary" to the combined value space.
2. The MediaType "application/octet-stream" is naturally isomorphic to the binary datatype.
3. The Data URI <data:application/octet-stream,DATA> may be used to represent data of type binary.
4. The URI

   <http://www.iana.org/assignments/media-types/application/octet-stream>

   may also be used to represent the binary datatype itself.

Semantic MathML

I don't know what they were thinking, but there is a much better way to encode MathML in RDF. One can be tempted to assign an RDF property to every element in MathML, but that wouldn't be the OpenMath way. Since MathML3 is getting more and more dependent on OpenMath, it seems appropriate to encode as much as possible using this combined system. MathML3 is split up into several sections: Presentation, Pragmatic Content, and Strict Content. The last one requires only 10 XML Elements to be understood by MathML3 processors, namely: m:apply, m:bind, m:bvar, m:csymbol, m:ci, m:cn, m:cs, m:share, m:semantics, m:cerror, and m:cbytes. This provides for a great economy of thought, and a chance to easily define a total mapping from MathML to RDF. MathML3 already defines a mapping from MathML2 to Strict Content MathML3, so this is the only set of Elements we need to consider. These are the prefixes we will use:

@prefix ari: <http://www.openmath.org/cd/arith1#> .
@prefix fns: <http://www.openmath.org/cd/fns1#> .
@prefix sts: <http://www.openmath.org/cd/sts#> .
@prefix sm: <http://example.com/SemanticMath/> .
@prefix m: <http://www.w3.org/1998/Math/MathML> .

These are the rdfs:Class's we will define:

• sm:Content (all MathML Content)
• sm:Number (for <cn/>, subclass of sts:NumericalValue)
• sm:String (for <cs/>, subclass of xs:string)

and these are the rdf:Property's we will define:

• sm:apply :: Property * sm:Content
• sm:applyTo :: Property * (List sm:Content)
• sm:bind :: Property * (List sm:Content)
• sm:bindOp :: Property * sm:Content
• sm:bindIn :: Property * sm:Content
• sm:error :: Property sm:Error sm:Content
• sm:errorWas :: Property sm:Error (List sm:Content)

Strict Content MathML3 can be translated with the following algorithm:

• <m:cn> NUM </m:cn>
"NUM"^^sm:Number
• <m:cs> TEXT </m:cs>
" TEXT "^^sm:String
• <m:ci> Name </m:ci>
Use blank node identifier (like _:Name)
• <m:csymbol> Symbol </m:csymbol>
Use URIs (http://www.openmath.org/cd/arith1#plus for <m:csymbol cd="arith1">plus</m:csymbol>, or the value of the definitionURL for MathML2)
• <m:share/>
Use URIs
• <m:cbytes> DATA </m:cbytes>
" DATA "^^xs:base64Binary
• <m:cerror> Symbol Content* </m:cerror>

[] rdf:type sm:Error ;
   sm:error Symbol ;
   sm:errorWas LIST(Content) .

• <m:apply> Symbol Content* </m:apply>

[] sm:apply Symbol ;
   sm:applyTo LIST(Content) .

• <m:bind> Symbol Vars* Content* </m:bind>

[] sm:bindOp Symbol ;
   sm:bind LIST(Vars) ;
        sm:bindIn LIST(Content) .

This allows all of Strict Content MathML to be encoded in a set of RDF triples. In order to have the full semantics of MathML and OpenMath there would have to be an OM-interpretation, OM-entailment, and so on, just as there is with every other application of RDF. Although I have not worked out the details of this, an OM-interpretation of an RDF graph that contains these properties would have to treat sts:mapsTo special, and maybe map it to an appropriate rdfs:Class. As an example of how this might be used, this is how the Haskell code (\x -> x + 2) would be translated into RDF using the properties listed above as follows:

_:f sm:bindOp fns:lambda ;
    sm:bind LIST(_:x) ;
    sm:bindIn LIST(
    [ sm:apply ari:plus ; 
      sm:applyTo LIST(_:x "2"^^sm:Number) ]).

Now that RDF has lambdas, the possibilities are endless!