[linux-audio-dev] LADSPA proposal ...
S.W.Harris at ecs.soton.ac.uk
Wed May 19 11:35:05 EDT 2004
On Wed, May 19, 2004 at 03:38:09 +0200, Alfons Adriaensen wrote:
> As far as I can see, everything that can be expressed by an RDF graph or
> a set of triplets or the eqeuivalent XML can be equally well expressed by
> nested property lists in LISP or even nested structs in C/C++.
Pretty much, yes, however you loose the guarantee of monotinicity, and you
need some language specific constructs to deal with the data structres.
RDF graphs are just graphs.
> The use of URIs in this case seems to me like complete overkill, there is
> no requirement that every identifier is webwide uinique since we have a
> well defined context.
Maybe, but to mee it seems like one of the few problems with LADSPA is the
mess of the label+file+uid, using URIs would do away with that, is very
simple, and doesnt require central administration.
> > To get round this, good metadata languages are defined so that they are
> > monotonic and with a few other interesting properties that logicians care
> > about.
> At some point in your program, metadata will be translated into variable
> values. If at that point you decide that B overrides A, things are no
> longer monotonic, and there's nothing to stop you from doing that even
> if the values of A and B were originally derived from RDF.
Thats an API issue. You and I both agree we shouldn't be tied to a single
API (though thats not a widespread belief).
> When you add a field to a C struct, that does not change the value of any
> other, so I'd say that is monotonic as well, unless you decide to destroy
> that property as described above.
But when you add a field to an array of structs thats no longer true (eg.
adding unints to the port structure). You have to either sacrifice
clenliness or break binary compatibility.
If you use graph structures you can just add additional edges to the port
node (vertex), without changing the representation of the metadata from the
> > If you are interested in the mathematical properties, then read the RDF
> > model theory: http://www.w3.org/TR/rdf-mt/ its a bit dry though :)
> > NB I wouldnt suggest we require RDFS for LADSPA, just RDF. RDFS makes it
> > much more challenging to implement if you dont want to use a standard
> > library, and we really wouldn't gain much.
> Do you mean you would have a dedicated parser that must be updated each
> time a property is added, rather than a general one driven by a schema ?
> In that case nothing is gained at all.
No, the parser is generic. The only thing that changes is what happens in
the API - if you dont update your API then you dont get new stuff, but
also it wont break. This beats trivial XML encodings and fixed structures
in my experience.
An NTriples parser has two rules:
<uri> <uri> <uri> .
<uri> <uri> "literal" .
More information about the linux-audio-dev