Re: ActiveRDF 0.1 released: object-oriented RDF in Ruby

On 04/01/06/04/06 20:42 +0200, Gunnar Aastrand Grimnes wrote:
>
>There is also RDFReactor [1], rdf2java [2] for java - Sparta [3] for  
>python and RDFWorld [4] for php (i've also hacked a php solution, but  
>it's so bad I wont mention it here unless someone asks)

Hi,

I did not intend to portray our approach as unique and my apologies if it 
sounded that way. 

But my point was, that scripting languages (such as Ruby) have important
advantages over compiled languages such as Java when it comes to correctly 
capturing RDF and its relation to RDF Schema (I will therefore take a good 
look at Giovanni's pointer to AutoSemantix).  

Let me summarise my point from our recently submitted paper [1]:

(1) Type system: the semantics of classes and instances in 
(description-logic based) RDF Schema and the semantics of 
(constraint-based) object-oriented type systems differ fundamentally.

(2) Semi-structured data: RDF data are semi-structured, may appear without 
any schema information and may be untyped. In object-oriented type sys- 
tems, all objects must have a type and the type defines their properties.  

(3) Inheritance: RDF Schema allows instances to inherit from multiple 
classes (multi-inheritance), but many object-oriented type systems only 
allow single inheritance.

(4) Flexibility: RDF is designed for integration of heterogeneous data with 
varying structure. Even if RDF schemas (or richer ontologies) are used to 
describe the data, these schemas may well evolve and should not be expected 
to be stable. An application that uses RDF data should be flexible and not 
depend on a static RDF Schema.

How to solve this with a scripting language [2]:

(1) Type system: Scripting languages have a dynamic type system in which 
objects can have no type or multiple types (although not necessarily at 
one-time).  Types are not defined prior but determined at runtime by the 
capabilities of an object.

(2) Semi-structured: the dynamic type system in scripting languages does 
not require objects to have exactly one type during their lifetime and does 
not limit object functionality to their defined type. For example, the Ruby 
“mixin” mechanism allows us to extend or override objects and classes with 
specific functionality and data at runtime.  

(3) Inheritance: most scripting languages only allow single inheritance, 
but their meta-programming capabilities allow us to either i) override 
their internal type system, or ii) generate a compatible single-inheritance 
class hierarchy on-the-fly during runtime.

(4) Flexibility: Scripting languages are interpreted and thus do not 
require compilation. This allows us to generate a virtual API on the fly, 
during runtime. Changes in the data schema do not require regeneration and 
recompilation of the API, but are immediately accounted for. To use such a 
flexible virtual API the application needs to employ reflection (or 
introspection) at runtime to discover the currently available classes and 
their functionality.

Please see the paper [1] for more information.

 -eyal

[1] http://www.eyaloren.org/pubs/sfsw2006.pdf
[2] we use a weakly defined notion of "scripting language" here, e.g.  Lisp 
possesses all these characteristics as well but would normally not be 
called a scripting language. See Ousterhout's paper in IEEE Computer for 
more information.

Received on Monday, 3 April 2006 11:04:31 UTC