Hi I think that the intention was just to be able to use whatever short name suits you. You could use: @prefix prj: <http://usefulinc.com/ns/doap#> @prefix l2: <http://lv2plug.in/ns/lv2core#> @prefix lv2: <http://myownsite.org/LowVoltageVariation#> ... I am not judging. Regards Bruno

On Tue, 2021-10-19 at 09:46 +0200, Fons Adriaensen wrote: 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

On Tue, 2021-10-19 at 21:12 +0200, Fons Adriaensen wrote: 'lo! Indeed. I'm trying to get back into cleaning up various messes, this one included, but... life is hard. They inherently have to be somehow? If the key was just, say, "value", then that could mean anything. A spec/extension/whatever needs to define what that means and how to use it, etc. Anyone can define such a thing (and many do, including implementation- private ones), so there needs to be a way to claim a namespace for your extensions. There isn't really a context of meaning here, some property, say https://lv2plug.in/ns/lv2core#enabled just means what it means. You can use LV2-defined stuff wherever if you like, and LV2 stuff can use elsewhere-defined stuff if it's handy. Both of these are common things to do. Any system that defines anything does that. That's what it means to define things. That said, there is a lot of bullshit surrounding LV2 and semantic web technologies, and the actual world of ontologies and such out there is a horrific mess. The logic people have made an even worse mess on top of it. None of that really matters though, LV2 just uses the basic idea of a triple-based data model and standard syntaxes for it. I'll be the first to recommend ignoring absolutely everything the W3C and especially the OWL types say about any of this. Though a hilarious thing to say in this context: this just sounds like semantics to me? :) The only reason you can understand a C header that defines a struct with filter coefficients or whatever is the same. What's the difference? If there's an impression here that somehow there is a machine-readable description of everything down to first principles that could be used to construct an implementation or whatever, that is /not at all/ the idea or intent. LV2 is using this stuff just as a very flexible data format, which allows anyone to define and use new things without stepping on anyone's toes, allowing data to be easily parsed/processed/transformed/loaded/etc by generic tools, and so on. This is mainly useful in practice for two reasons: 1) Developers can define new things if they want, and describe their plugin better, if there is information that is useful for a host to know. This "definition" can simply be a comment that explains, in plain english, what it means, and that's totally fine. Usually there's a bit of machine readable stuff in there as well to describe, say, what data types are appropriate for the value or whatever, because this is handy (and at the very least enables validation tools and such), but generally we only define things that are useful. 2) The "mechanical" flexibility of the data itself is handy in many ways. For example, some hosts load a single plugin's data into their own internal data structures, some host load a single plugin's data into a general model in memory and work from that, and some hosts load every single plugin/ontology/preset/whatever in the system into the same big model and work from that. All of these are fine, you can literally cat files together, or do things that are conceptually equivalent to doing that, and it doesn't matter. So, concretely, mostly we're just using the idea of a data representation that is simply a set of triples, with identifiers that can't clash (because of the URI thing). We use a bit of vocabulary for describing classes/properties/etc where it's useful to have that information in a machine-readable form, but that's because... well, it's useful. It's just the RDFey way of saying things like "the plugin's label must be a string" or "a control can have only one default value". So, essentially you're right: LV2 does not describe plugins in a machine-readable way all the way down to (some arbitrary set) of first principles. It's not trying to, that would obviously be a total wank. It's describing audio plugins for audio developers and audio software. Things only mean what we say they mean, based on some base set of common understanding. That would be true regardless of how it's written down: RDF, JSON, C, C++, plain text, spoken conversation. Here we just tend towards machine-readable where it makes sense, because machine-readable is more useful than not. That's all. -- dr

On Wed, 2021-10-20 at 10:10 +0200, Fons Adriaensen wrote: This is a glaring straw man. I'm not sure what you're arguing against, but it certainly isn't LV2. The main reason LV2 uses separate data files is so that hosts don't need to load and execute code only to discover what plugins are present. This has pros and cons, like most things. Fair enough. "I just want to write C and only C" is a reasonable and understandable position, no need for any hand-wavey nonsense. As it happens, we could do that, without even really breaking anything in a significant way, *specifically because everything is based on a simple abstract data model*. If someone makes a C API that can describe the same information, then it could be used to access the data instead. This could be used to generate static data files where that makes sense, or it could be used at runtime to dynamically discover plugins, or both. The same API could be used in either case. I would like to actually do this for various reasons, but it's not a high priority. This is the sort of thing you can easily do with a simple abstract data model (a set of triples), and that's the sort of thing that LV2 actually takes advantage of. What's going on here is really much more of a Scheme-like idea than some semantic pipe dream. So, concretely: we really could remove all of that Turtle stuff, and it would not be a very deep change, loosely analogous to just writing a different parser. Everything past that in the implementation would remain absolutely identical, not one character of code changed. That's not an accident, and this sort of thing is why people who *do* grok LV2 are not interested in throwing out all of the babies with the bathwater. The fact that we can change all of these superficialities and still retain everything that we have built so far is also a big reason why nobody cares that much. Work on new features and new/better ways of describing plugins/etc will be useful, even if LV2 evolves to become something that does not look at all like the current LV2 at first glance. We all have our gripes with Turtle, and with the idea of static metadata in separate files - but those can be addressed. As you should. It's very telling that this conversation, and most of the ones like it, are not actually about concrete technological issues. They're about people finding terms like "RDF" and "semantic web", googling them, falling down some rabbit hole or another, and ending up at very bizarre conclusions like some syntax being used makes the whole technology stupid and utopian (or whatever) because it's trying to define the entire world or... something. It's very understandable how people end up at such nonsense, and the W3C and much of the semantic web community deserves a ton of criticism for making that situation, but it's nonsense all the same. You'll certainly get no argument from me that that situation is a nightmare. I've been slowly expunging it from the documentation for years now, gently pushing third-party documentation efforts to do the same, and will continue to do so until absolutely none of it is left. Hopefully then we can spend more time talking about, and addressing, real problems... We can paint the shed whatever color we like, because the shed is built on a foundation of good ideas. The fact that some of those ideas are loosely associated with bad ones is irrelevant (except in PR terms). That's true of all ideas anyway. -- dr

Am 20.10.21 um 16:26 schrieb David Robillard: For that case XUiDesigner may come handy, it will generate a complete working LV2 bundle from just stick a user interface per drag n' drop together. You only need to insert your dsp code to make it a real world plugin. https://github.com/brummer10/XUiDesigner

On Wed, 2021-10-20 at 22:32 +0200, Fons Adriaensen wrote: Fair enough, to be clear I just mean that in the context of LV2. Slightly more generally, also the context of most people/projects actually using some of this tech in the real world. The things you quite righly point out as silly pipe-dreams come from a particular academic niche of quasi-logicians who are completely divorced from real-world software development (and it shows). Even there, the argument that it's important to somehow describe the universe is frankly pretty straw-manney (though I'm sure you can find somebody in an armchair somewhere who thinks that), but regardless, nobody really cares what that camp says at this point anyway. Even in the linked data world. The more data-oriented people had good ideas that are useful in practice and have literally nothing to do with semantics. We need some of that - mainly that whole extensibility thing. I suspect that people imagine this is much more theoretical than it is. This is how development of LV2 things happens in reality. If you need stuff, you can add stuff. If people agree that the added stuff is sane/useful, then perhaps it gets standardized. There is no Steinberg here to tell you what you're allowed to do. This is why little ideas like "IDs must be globally unique and can not clash" are so important. It's why *you* get to invent them if you like, and you don't need approval from me or anyone else to do so. Perhaps it's a bit messy, but that's how worse-is-better works. I'll take a working spec that's a bit messy over GMPI or whatever any day. /That/ tack is the pipe-dream, just a very different sort of one. It's all very addressable, but as always, the real reason for things still being pretty messy is as crass as it is simple: nobody's paying anyone to make a really nice open source audio plugin specification. The freedom to pile in whatever you want, at the cost of things being a bit chaotic and unpolished, is just the best we can do in these circumstances. At least it works. -- dr

On Tue, 2021-10-19 at 11:38 +0200, Sven Jaehnichen wrote: I am (somewhat idly) working towards this still, but it probably won't make the upcoming round of major releases. JSON-LD is much, much more complicated to implement, specifically because it's *not* just a dumb syntactic veneer for triples. It does, however, not look weird, which is probably worth the effort, even though it makes real the (currently imagined) problem of needing access to vocabularies to parse anything at all. -- dr

On Tue, 2021-10-19 at 10:00 +0100, Chris Cannam wrote: I've honestly thought a few times that maybe using a custom scheme would have been better. It's objectively worse in every way, but the instant people see "http" they lose their damned minds for some reason :) C'est la vie... -- dr

On Tue, 19 Oct 2021, 19:18 Will Godfrey, &lt;willgodfrey(a)musically.me.uk&gt; wrote: It's common, eg. XML namespaces. More fun when people start complaining they're not https. :-) Best wishes, Neil

On Tue, 19 Oct 2021 16:58:39 -0400 David Robillard &lt;d(a)drobilla.net&gt; wrote: I must admit I can't find this now. I haven't checked for a long time, so I'll be the first to say I might have originally misinterpreted what I saw. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On 20.10.21 00:39, David Robillard wrote: This may have shown up in a bug report with output from *lv2lint*. The latter can check for existence of license/homepage/plugin URLs. But there's no need to freak out for the average paranoid, it's a double opt-in: The feature *must* manually be enabled at compile- time and *must* manually be enabled at runtime ;-)