What is the perfect programming language for semantic web development?

The type system of OWL is different from that of (AFAIK) every current object-oriented programming language in use today. In modern object oriented languages, the concept of an object reference's type is either fixed at compile time (for statically typed languages) or is indeterminate - meaning the reference itself can be redirected to something of a different type, not that the things referred to can change their type (dynamically typed languages). In contrast to OO programming languages, the types and properties of an object instance in OWL are in a sense 'delegated' to the judgement of some reasoning engine. For example, it might be possible to define a class in terms of a restriction. This kind of polymorphism might be easier in OWL because OWL classes don't have to maintain a jump-table of functions to associate with each type.

In working with Object/Semantic bridges like LinqToRdf it would be compulsory to confine yourself to ontologies where an instance will retain its type for ever. In most cases I find that a perfectly acceptable thing to do since that's my normal mode of expression as an OO designer. But add to that all the other constraints from more recent OO languages - such as single inheritance of object implementation, a lack of built in support for reasoning - and it seems to me that we'd be better served by a programming language matching the expressive range of OWL.

My question, then, is twofold:

  1. Is a performant object oriented programming language, that is the linguistic superset of OWL, possible?
  2. How could its type system be designed?

First of all, I would like to understand why... I am afraid that pushing OWL or RDF into an Object Oriented framework may give a false impression to users that can lead to conceptual errors.

Dynamic typing is not the only issue that separate these two worlds. Take, for example, the ':p rdf:range :q' in RDFS. Many people make the error that this means some sort of a 'constraint' on :p, and that is often because they make the connection to traditional programming environments (loosely with the type of a function's return value). But, in RDFS, this statement is a license to infer, which is quite different.

All that being said: there was a time when delegation based languages were in vogue. I would certainly look in this direction rather than OO languages... Though I have never really given thoughts to that, I must admit...

I cannot advise you a programming language. However, I can show you how I overcame the strong typing (.NET) vs multi typing(OWL) problem while developing the ROWLEX Toolkit.

My solution was applying a document-view architecture. The document is the RDF graph itself - or to be more specific - the nodes inside the graph representing the business objects. The views are my .NET instances. These .NET instances stored only 2 things:

  • the URI of the node and
  • the reference to the RDF document

All properties/methods of the instances get/set the graph directly. The user is allowed to create as many views (.NET instances) pointing to the same RDF node as he/she wants, having each instance corresponding to a different (.NET and OWL) type. The result is: one node - many types.

This solution allows the business objects to retain their OWL-style multityped behavior, while I still satisfy the strong typing of .NET.

I don't think we need a language specially designed to do this..We've been dealing with the object-relational mismatch through frameworks for a long time, and it works just fine.

We don't really need to perform late binding on RDF types, because there are no functions or methods, just properties and data. We just need good frameworks that allow us to query the data efficiently and reason over it.

Ruby and Java both have some pretty neat libraries and have all the resources built up over the years for Rapid Web Development. Basically anything that supports meta programming and introspection. The silver bullet for OO developers is an Object to RDF model binding. Basically they don't want to waste time writing queries but do want to spend time developing the domain.

It so happens that I have started a library for such a thing below: