[LV2] Simplifying the Atom model

[David Robillard]

On Sat, 2013-02-09 at 23:43 +0100, Stefan Kersten wrote:
> On 09/02/2013, at 22:37, David Robillard <d at drobilla.net> wrote:
> > On Sat, 2013-02-09 at 12:40 +0100, Stefan Kersten wrote:
> > [...]
> >>> In short, I think it would be much more obvious if we simply had one
> >>> "Object" type.
> >>> 
> >>> The solution is to merge the classes, and use a signed int32_t as an ID,
> >>> where positive is a URID, and negative is a blank node ID (essentially
> >>> meaningless outside local context).
> >> 
> >> imho the current scheme is not confusing at all but rather makes the distinction between blanks and resources explicit instead of relying on a convention.
> > 
> > The only difference is the ID, though.  In practice this means you get
> > type == uris->atom_Resource || type == uris->atom_Blank everywhere, when
> > you actually don't care about the type at all.
> 
> maybe just adding an is_object helper would do the trick? that's what i'm using in my code now.

As does the examples, as do a ton of plugins that copy them.

Seems clear this is just generally more of a nuisance, what's the
advantage?  There is the argument that it shouldn't be changed just
because it shouldn't be changed, but in general it seems pretty clear to
me now that this way sucks, the type hierarchy is weird and pointless.

> > Fair enough, but people are very prone to just knee-jerk write this
> > stuff off as "confusing", especially if it smells at all like RDF.  I
> > suspect just "Object" would be much more palatable to these people.
> 
> i like the fact that the atom types have an rdf representation (the rdf turtle primer is a very  helpful resource and should maybe be linked from the docs somewhere).
> 
> i was wondering btw what's the rdf representation of a property's context field?

That is a can of worms like you can not possibly imagine ;)

"Graph", sort of.  In practice you can't rely on it surviving RDF
transit, it is just dropped by sratom and everything built on it, and
would be by any other pretty Turtle serialization implementation.  It
was stuck there to fill the space, and because it might have some uses
in a local scope, or future use by the spec, but you don't want to use
it globally.

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130209/0bc612c8/attachment-0002.pgp>