[RDF] SDS - the basic idea

Stefan Andersson stefan@c64.org
Tue, 15 Aug 2000 22:58:34 +0200


Yo!

I'll try to get the whole SDS thing started softly by explaining the
main concepts. There is another document, in swedish, with a slightly
different angle, but not that much juicier. This will suffice. For now.

Abstract:
Serialization Description Schemas are meant to be a generalized way of
describing serializations of primarily text, but also binary data.

Justification:
By describing serialization in a RDF-based way, a party can serialize
it's output suitable for another party without any development efforts.
A schema approach featuring inheritance also makes it possible to
construct an object representation 'on-the-fly', without development
efforts. Added benefits also comes from the possibility of a third party
synthesizing serialization schemas contructing compromises between
different serialisation demands - as for example a combination of
personalization, target medias (HTML/WAP, Slow connection, Browser
version et.c.) and multiple sources.

Other efforts:
I have not looked deeply into what have been done in terms of for
example XPointers, and although it's text-oriented, not DLG-oriented,
there surely must be some concepts worth considering.
The same goes for XSL and CSS.

Requirements:
* The SDS should consist of as few operators as possible.
  This is because implementation should be easy.

* The SDS should consist of 'levels of complexity'
  This is to accomplish the Perl mantra 'easy things...'

* The SDS should embrace RDF Schema as base schema.
  Because the definition should be as inference-friendly as RDF Schema
itself.

* The SDS should be property-centric.

* The SDS should work in a many-to-many context - a resource could use
any SDS, and a SDS could apply to any resource. This implies some sort
of selection mechanism based on 'context'.

* The SDS should support inheritance, substitution and overloading.
  Schemas should be able to override underlying schema definitions. This
also implies some sort of model prioritizing. This prioritizing could be
the base for content negotiation.

* An SDS should be able to work both as 'master' and 'slave'
  That is, be both accessible as an object in itself, deducing necessary
data  resources, and be able to serialize a given object.

* The SDS should, as far as possible, be modeled upon existing Schema
extensions.
  Careful inventory and re-examination underways is key.

* The SDS should be modelled as a one-way hierarchy.
  Unbreaking loops should not be possible to construct.

* Your requirement here

Notes:

* Caching is crucial. Hence WRAF.

* As far as I know, there is no way in RDF Schema to describe parallell
class hierarchy 'leaps', that is, to describe that if a serialization
definition of a 'person' includes a 'name', it should be that resources
'name'. Wheter this should mean the _attribute_ 'name' of the resource
or the attributes of _type_ 'name' is an unresolved issue. Most probably
this is up to exactly what the resource pointer points to, a Class or an
attribute...
Actually, this 

Basic koncepts:
* A 'Serialization model', the definitions that implements a certain
serialization context. F.ex. 'XHTML' would be a serialization model
describing how to present base objects in XHTML. 'Stefans web
preferences' would be a serialization model describing how I want my
webpages to look.

* 'Context' a node definiting a certain selection critera.

* 'Ennullment' - if no child attribute exists, it should not be
rendered. This solves the most basic logic operation: Exclusion.

A extremely simple draft:
One of the simplest examples I can come up with, is describing a
serialization as a collection of collections:

Stefan -- type --> Person
SerDef -- subClassOf --> Class
asHTML -- type --> SerDef

Stefan -- serializedAs --> PersonAsHTML

PersonAsHTML -- subClassOf --> asHTML
PersonAsHTML -- appliesTo --> Person
PersonAsHTML -- context --> HTML

PersonAsHTML -- type --> #Seq
PersonAsHTML -- _1 --> { photo } // This is the 'leap' i talk about.
PersonAsHTML -- _2 --> { name  } // This too.

Something like that.
/Stefan