19 Oct
2021
19 Oct
'21
12:54 a.m.
Sorry to _low_show - this was meant for the list.
On Mon, Oct 11, 2021 at 03:19:45PM +0200, _low_show wrote:
Looks great, will make some time to try it out! Thanks
for making this!
I somehow deleted the original post, but refer to
I never got to grips with turtle. In particular not with
things like:
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix units: <http://lv2plug.in/ns/extensions/units#> .
All docs and tutorials I found mention that the URLs do NOT
mean that an application reading a file that contains them
would actually need to read them from the web (which would
be a unacceptable security risk anyway).
But that means that whatever is defined by those URLs
must actually be hard-coded in any LV2 host that reads
the 'manifest.ttl' or 'my-plugin.ttl' files.
Which raises the question why those @prefix lines are
required at all. They could be used in theory to check
that what is hard-coded corresponds to what is defined
in those URLs. But to do that the application would
need to access them.
So all that these lines seem to provide is some illusion
of conformity which isn't enforced or checked at all.
So the conclusion is that this isn't any better than any
ad-hoc way of encoding the plugin metadata.
Or am I missing something essential ?
TIA for any reply that would enlighten me...
--
FA