On 10/18/21 10:54 PM, Fons Adriaensen wrote:
I never got to grips with turtle.
https://www.w3.org/TR/turtle/ to the rescue :)
There is currently ongoing work to allow JSON-LD as alternative, but
that's just the encoding.
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).
URIs are just used as unique identifiers. They do not even need to
resolve and one can use urn: as well. However in most cases they point
to online documentation which is helpful to developers.
Which raises the question why those @prefix lines are
required at all.
@prefix just syntactic sugar, so you do not have to spell out the full
URI every time. Instead of e.g.
http://lv2plug.in/ns/lv2core#ControlPort
you can just write
lv2:ControlPort
So all that these lines seem to provide is some
illusion
of conformity which isn't enforced or checked at all.
Those URIs are defined in header files of the LV2 ontology and must
match, otherwise a LV2 plugin does not conform to the spec. There are
tools like lv2lint to check the validity, but other than that, they are
just unique IDs.
So the conclusion is that this isn't any better
than any
ad-hoc way of encoding the plugin metadata.
Except it is not ad-hoc, but a w3c standard. Why invent an new meta-data
schema for unique resource IDs, when there is already a very good one
out there, that is also formalized as RFC?
As side-effect you can also use existing tools from the semantic web to
index and search LV2 plugins. IIRC the MOD website uses that.
I hope that clarifies things,
robin