On Tue, 2021-10-19 at 09:46 +0200, Fons Adriaensen wrote: > On Tue, Oct 19, 2021 at 12:13:17AM +0200, Robin Gareus wrote: > > > https://www.w3.org/TR/turtle/ to the rescue :) > > Been there of course... > > > Instead of e.g. http://lv2plug.in/ns/lv2core#ControlPort > > you can just write lv2:ControlPort > > That I understand. But: > > 1. The logic that allows this is hard coded in the LV2 host, > it is not the result of 'including' the @prefix. Checking > that the @prefix is present does not mean that whatever > is hard coded corresponds to what the @prefix is supposed > to imply. This is what I mean when saying that all this > just provides 'an illusion of conformity'. > > 2. If the intention is that people use the short form, why > bother with the long one at all ? The code that reads > the ttl files can simply accept the short one without > even being aware of the equivalence to the long one. > Which then has no reason to exist at all. So to me > this looks like a solution in search for a problem.
It's just a namespacing mechanism for convenience. Just as in C++ where you could write ::foo::bar::baz::quux::SomeClass everywhere, but that would be extremely annoying, there is "using" to make it more convenient. That's all @prefix does in Turtle. It has nothing to do with semantics, or what properties/classes/etc "mean", or anything like that. It is an incredibly dumb mechanism that is (more or less) just primitive string concatenation. The reason you can't "just" use the short one everywhere is that they are not globally unique (being the whole point). It is just a convenient document-local syntax, and the name of the prefix means absolutely nothing (it is not present in the data whatsoever, @prefix is analogous to a preprocessor directive). In order to do that, we would need to make a central authority that hands out blessed prefixes for some purpose. The reason URIs are used here is to not have to do that, by just taking advantage of DNS (and people actually do use this, a lot, both in general and in LV2. Requiring permission to define extensions is a total non-starter here). That said, clearly there are too many prefixes, and it's annoying, but this is a different issue. JSON-LD(*) lets you write vocabularies which contain more magic to avoid this, for example, but that actually does introduce the issue you're suggesting here: you need that vocabulary document to make sense of the document at all. This is not the case with Turtle. You do not need the schema to parse the document. There doesn't even need to be a schema at all. Ideally there is, and often it is useful to take advantage of that (e.g. there are comments and human-readable labels alongside machine-readable information that can be used for validation and such), but as you say, the "understanding" of some property or whatever can also just be built in to the code. In other words, your point 1 reads to me like "this mechanism doesn't guarantee the document is semantically correct"? Indeed, it doesn't. It doesn't have anything to do with that at all. It's not pretending to, either. There is no illusion of conformity here, it's really just a stupid token pasting mechanism and that's it. Put another way, Turtle is a syntax for describing data. It is a syntactically valid document to, say, set the label of a plugin to an integer. It's not semantically valid, but that's a wholly separate issue. (* Which would probably be a good idea to adopt to make all this perceived weirdness and bikeshedding go away. Maybe some day..) -- dr _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev