[LAD] minimal LV2

Jeremy jeremybubs at gmail.com
Mon Jun 14 00:23:06 UTC 2010


On Sun, Jun 13, 2010 at 5:08 PM, Paul Davis <paul at linuxaudiosystems.com>wrote:

> On Sun, Jun 13, 2010 at 4:17 PM,  <fons at kokkinizita.net> wrote:
> > On Sun, Jun 13, 2010 at 12:58:11PM -0400, Jeremy wrote:
> >
> >> I would like to add that as a beginner to LV2 plugins, I found the use
> of
> >> urls to be *extremely* confusing.
> >
> > Glad to know I'm not the only one.
>
> i think that the problem here is not an unusual one. there is a
> disconnect between people who have thought a little bit about
> something, and people who have thought a lot about the same thing.
> this doesn't mean that the latter group is right and the former group
> is wrong. but look, issues of how to add metadata to online/software
> entities have been a focus of various parts of academia and industrial
> R&D-ish types for many, many years. the design of LV2's metadata
> reflects some part of the general conclusions that this sort of work
> (nowadays "the semantic web") have come up with.
>
> if you want to argue that this design is wrong in general, i think you
> have an uphill battle (although you will find allies in parts of the
> semantic web world). if you want to argue that its overblown in this
> particular case, then i think its fairly important to show why the
> considerations that lead to this RDF/turtle-ish kind of thing don't
> apply to the case of describing plugins.
>
> you know, as a beginner to quite a lot of things, i found them
> confusing. as i got more experienced with them, in many (most?) cases
> i ended up understanding why the design was the way it was.
> confusing-for-beginners is not really a particularly compelling
> argument against something that really isn't supposed to be the focus
> of a beginner's experience anyway. but people being people, they find
> the one or two things that seem confusing and then zoom in on that,
> ignoring its real significance and purpose in the general scheme of
> things.
>
> the fact that a generation or more of programmers have grown up not
> really grasping the difference between a URL and a URI is a problem,
> and its not one that LV2 is here to solve.
>
> > I'm more and more convinced that people creating these sort of
> > thing entertain the illusion that they somehow create meaning
> > while there is none. It looks more like an extreme form of
> > illiteracy, a complete failure to convey meaning in a form that
> > makes sense to a human.
>
> people who don't understand any field of formal jargon say the same
> thing about that jargon. these descriptions are formal jargon. you're
> not meant to "just get them" by just looking at them. they are also
> not there to convey meaning to a human, although an interested human
> could discover something from them.
>
> --p
>

I'd just like to clarify that I don't find the whole rdf syntax to be
confusing.  Although at first it took a little bit to understand, everything
I understood was logical and intuitive.  It makes sense that you would have
to have some system for naming and identifying plugins, features, etc in a
human readable way.  Obviously a string makes sense.  Where I was thrown off
is that  a URL was chosen to be the identifier.  Now, I'm not claiming to be
an expert on URIs, but from what I just looked up, it seems that URLs are
supposed to be used to tell you *how* to get an item, while URNs are
supposed to uniquely identify an object.  URNs would especially be an
improvement because they are clearly distinguishable from dereference URLs.
 And if I'm wrong about URNs or they don't fit the requirements, I think
there are plenty of great systems for creating unique human readable
identifiers.  Something like Java packages, or even a custom format, such as
"Feature:Paul.Davis:Control.Port" would all be great, simply because they
don't cause you to look at at and think "I can type that into Firefox".  I
think you'd be hard pressed to find a programmer who looks at a URL and
doesn't immediately think "Somewhere, somehow, you can wget that".  And
that's the problem with URLs:  They already have a well established and
universally recognized use, and this use doesn't fall under that category.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100613/7397f879/attachment.html>


More information about the Linux-audio-dev mailing list