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:
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