diff options
Diffstat (limited to 'lv2/patch')
| -rw-r--r-- | lv2/patch/patch.meta.ttl | 298 | ||||
| -rw-r--r-- | lv2/patch/patch.ttl | 242 |
2 files changed, 335 insertions, 205 deletions
diff --git a/lv2/patch/patch.meta.ttl b/lv2/patch/patch.meta.ttl index 6b623f7..bdc2568 100644 --- a/lv2/patch/patch.meta.ttl +++ b/lv2/patch/patch.meta.ttl @@ -1,6 +1,8 @@ @prefix dcs: <http://ontologi.es/doap-changeset#> . @prefix doap: <http://usefulinc.com/ns/doap#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . +@prefix lv2: <http://lv2plug.in/ns/lv2core#> . +@prefix patch: <http://lv2plug.in/ns/ext/patch#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . <http://lv2plug.in/ns/ext/patch> @@ -9,7 +11,7 @@ doap:license <http://opensource.org/licenses/isc> ; doap:developer <http://drobilla.net/drobilla#me> ; doap:name "LV2 Patch" ; - doap:shortdesc "Messages for accessing and manipulating properties." ; + doap:shortdesc "A protocol for accessing and manipulating properties." ; doap:release [ doap:revision "2.6" ; doap:created "2019-02-03" ; @@ -66,5 +68,297 @@ rdfs:label "Initial release." ] ] - ] . + ] ; + lv2:documentation """ + +This is a vocabulary for messages that access and manipulate properties. +It can be used as a dynamic control interface for plugins, +or anything else with a property-based model. + +The key underlying concept here is to control things by manipulating arbitrary properties, +rather than by calling application-specific methods. +This allows implementations to understand what messages do +(at least in a mechanical sense), +which makes things like caching, proxying, or undo relatively straightforward to implement. +Note, however, that this is only conceptual: +there is no requirement to implement a general property store. +Typically, a plugin will understand a fixed set of properties that represent its parameters or other internal state, and ignore everything else. + +This protocol is syntax-agnostic, +and [homoiconic](https://en.wikipedia.org/wiki/Homoiconicity) +in the sense that the messages use the same format as the data they manipulate. +In particular, messages can be serialised as a binary [Object](atom.html#Object) for realtime plugin control, +or as Turtle for saving to a file, +sending over a network, +printing for debugging purposes, +and so on. + +This specification only defines a semantic protocol, +there is no corresponding API. +It can be used with the [Atom](atom.html) extension to control plugins which support message-based parameters as defined by the [Parameters](parameters.html) extension. + +For example, if a plugin defines a `eg:volume` parameter, it can be controlled by the host by sending a patch:Set message to the plugin instance: + + :::turtle + [ + a patch:Set ; + patch:property eg:volume ; + patch:value 11.0 ; + ] + +Similarly, the host could get the current value for this parameter by sending a patch:Get message: + + :::turtle + [ + a patch:Get ; + patch:property eg:volume ; + ] + +The plugin would then respond with the same patch:Set message as above. +In this case, the plugin instance is implicitly the patch:subject, +but a specific subject can also be given for deeper control. + +"""^^lv2:Markdown . + +patch:Copy + lv2:documentation """ + +After this, the destination has the same description as the subject, +and the subject is unchanged. + +It is an error if the subject does not exist, +or if the destination already exists. + +Multiple subjects may be given if the destination is a container, +but the semantics of this case are application-defined. + +"""^^lv2:Markdown . + +patch:Get + lv2:documentation """ + +If a patch:property is given, +then the receiver should respond with a patch:Set message that gives only that property. + +Otherwise, it should respond with a [concise bounded description](http://www.w3.org/Submission/CBD/) in a patch:Put message, +that is, a description that recursively includes any blank node values. + +If a patch:subject is given, then the response should have the same subject. +If no subject is given, then the receiver is implicitly the subject. + +If a patch:request node or a patch:sequenceNumber is given, +then the response should be a patch:Response and have the same property. +If neither is given, then the receiver can respond with a simple patch:Put message. +For example: + + :::turtle + [] + a patch:Get ; + patch:subject eg:something . + +Could result in: + + :::turtle + [] + a patch:Put ; + patch:subject eg:something ; + patch:body [ + eg:name "Something" ; + eg:ratio 1.6180339887 ; + ] . + +"""^^lv2:Markdown . + +patch:Insert + lv2:documentation """ + +If the subject does not exist, it is created. If the subject does already +exist, it is added to. + +This request only adds properties, it never removes them. The user must take +care that multiple values are not set for properties which should only have +one. + +"""^^lv2:Markdown . + +patch:Message + lv2:documentation """ + +This is an abstract base class for all patch messages. Concrete messages are +either a patch:Request or a patch:Response. + +"""^^lv2:Markdown . + +patch:Move + lv2:documentation """ + +After this, the destination has the description that the subject had, and the +subject no longer exists. + +It is an error if the subject does not exist, or if the destination already +exists. + +"""^^lv2:Markdown . + +patch:Patch + lv2:documentation """ + +This method always has at least one subject, and exactly one patch:add and +patch:remove property. The value of patch:add and patch:remove are nodes which +have the properties to add or remove from the subject(s), respectively. The +special value patch:wildcard may be used as the value of a remove property to +remove all properties with the given predicate. For example: + + :::turtle + [] + a patch:Patch ; + patch:subject <something> ; + patch:add [ + eg:name "New name" ; + eg:age 42 ; + ] ; + patch:remove [ + eg:name "Old name" ; + eg:age patch:wildcard ; # Remove all old eg:age properties + ] . + +"""^^lv2:Markdown . + +patch:Put + lv2:documentation """ + +If the subject does not already exist, it is created. If the subject does +already exist, the patch:body is considered an updated version of it, and the +previous version is replaced. + + :::turtle + [] + a patch:Put ; + patch:subject <something> ; + patch:body [ + eg:name "New name" ; + eg:age 42 ; + ] . + +"""^^lv2:Markdown . + +patch:Request + a rdfs:Class ; + rdfs:label "Request" ; + rdfs:subClassOf patch:Message ; + lv2:documentation """ + +A request may have a patch:subject property, which specifies the resource that +the request applies to. The subject may be omitted in contexts where it is +implicit, for example if the recipient is the subject. + +"""^^lv2:Markdown . + +patch:Set + lv2:documentation """ + +This is equivalent to a patch:Patch which removes _all_ pre-existing values for +the property before setting the new value. For example: + + :::turtle + [] + a patch:Set ; + patch:subject <something> ; + patch:property eg:name ; + patch:value "New name" . + +Which is equivalent to: + + :::turtle + [] + a patch:Patch ; + patch:subject <something> ; + patch:add [ + eg:name "New name" ; + ] ; + patch:remove [ + eg:name patch:wildcard ; + ] . + +"""^^lv2:Markdown . + +patch:body + lv2:documentation """ + +The details of this property's value depend on the type of message it is a part +of. + +"""^^lv2:Markdown . + +patch:context + lv2:documentation """ + +For example, a plugin may have a special context for ephemeral properties which +are only relevant during the lifetime of the instance and should not be saved +in state. + +The specific uses for contexts are application specific. However, the context +MUST be a URI, and can be interpreted as the ID of a data model where +properties should be stored. Implementations MAY have special support for +contexts, for example by storing in a quad store or serializing to a format +that supports multiple RDF graphs such as TriG. + +"""^^lv2:Markdown . + +patch:readable + lv2:documentation """ + +See the similar patch:writable property for details. + +"""^^lv2:Markdown . + +patch:request + lv2:documentation """ + +This can be used if referring directly to the URI or blank node ID of the +request is possible. Otherwise, use patch:sequenceNumber. + +"""^^lv2:Markdown . + +patch:sequenceNumber + lv2:documentation """ + +This property is used to associate replies with requests when it is not +feasible to refer to request URIs with patch:request. A patch:Response with a +given sequence number is the reply to the previously send patch:Request with +the same sequence number. + +The special sequence number 0 means that no reply is desired. + +"""^^lv2:Markdown . + +patch:wildcard + lv2:documentation """ + +This makes it possible to describe the removal of all values for a given +property. + +"""^^lv2:Markdown . + +patch:writable + lv2:documentation """ + +This is used to list properties that can be changed, for example to allow user +interfaces to present appropriate controls. For example: + + :::turtle + @prefix eg: <http://example.org/> . + @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . + @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . + @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . + + eg:title + a rdf:Property ; + rdfs:label "title" ; + rdfs:range xsd:string . + + eg:plugin + patch:writable eg:title . + +"""^^lv2:Markdown . diff --git a/lv2/patch/patch.ttl b/lv2/patch/patch.ttl index 58bee12..305a3e7 100644 --- a/lv2/patch/patch.ttl +++ b/lv2/patch/patch.ttl @@ -11,43 +11,14 @@ lv2:Specification ; rdfs:seeAlso <patch.h> , <patch.meta.ttl> ; - lv2:documentation """ -<p>This vocabulary defines messages which can be used to access and manipulate -properties. It is designed to provide a dynamic control interface for LV2 -plugins, but is useful in many contexts.</p> - -<p>The main feature of this design is that the messages themselves are -described in the same format as the data they work with. In particular, -messages can be serialised as a binary <a -href="atom.html#Object">Object</a> or in Turtle (or any other RDF -serialisation).</p> - -<p>The idea behind using a property-based interface for control is to prevent -an an explosion of message types. Instead of a custom message for each action, -control is achieved via manipulating properties (which are likely already -defined for other reasons). Note, however, that this is purely conceptual; -there is no requirement that the receiver actually implement a store of -resources with properties.</p> - -<p>For example, consider an object that can blink. Rather than define a -specific interface to control this (e.g. <code>obj.start_blinking(); -obj.stop_blinking()</code>), set a <q>blinking</q> property to true or false -(e.g. <code>obj.set(blinking, true)</code>) to achieve the desired behaviour. -One benefit of this approach is that a persistent state model is available -<q>for free</q>: simply serialise the <q>blinking</q> property.</p> - -<p>This specification is strictly metadata and does not define any binary -mechanism, though it can be completely expressed by standard types in the <a -href="atom.html">LV2 Atom</a> extension. Thus, hosts can be expected -to be capable of transmitting it between plugins, or between a plugin and its -UI, making it a good choice for advanced plugin control.</p> -""" . + rdfs:label "LV2 Patch" ; + rdfs:comment "A protocol for accessing and manipulating properties." . patch:Ack a rdfs:Class ; rdfs:subClassOf patch:Response ; rdfs:label "Ack" ; - rdfs:comment "An acknowledgement that a request has been successfully processed. This is returned as a reply when a specific reply type is not necessary or appropriate. " . + rdfs:comment "An acknowledgement that a request was successful." . patch:Copy a rdfs:Class ; @@ -62,15 +33,13 @@ patch:Copy owl:cardinality 1 ; owl:onProperty patch:destination ] ; - rdfs:comment """Copy the patch:subject to patch:destination. After this, patch:destination has the description patch:subject had prior to this request's execution, and patch:subject is unchanged. It is an error if the subject does not exist or the destination already exists. - -Multiple patch:subject properties may be given if the patch:destination is a container, the semantics of this use case are application defined.""" . + rdfs:comment "A request to copy the patch:subject to the patch:destination." . patch:Delete a rdfs:Class ; rdfs:subClassOf patch:Request ; rdfs:label "Delete" ; - rdfs:comment "Request the subject(s) be deleted." . + rdfs:comment "Request that the patch:subject or subjects be deleted." . patch:Error a rdfs:Class ; @@ -82,56 +51,7 @@ patch:Get a rdfs:Class ; rdfs:subClassOf patch:Request ; rdfs:label "Get" ; - rdfs:comment "Request a description of the subject." ; - lv2:documentation """ -<p>Request a description of the subject.</p> - -<p>The detail of the response is not specified, it may be a flat description of -all the properties of the subject, or a more expressive description with -several subjects. A good choice is a <q><a -href="http://www.w3.org/Submission/CBD/">concise bounded description</a></q>, -i.e. a description which recursively includes all properties with blank node -values.</p> - -<p>The response should have the same patch:subject property as the request, and -a patch:body that is a description of that subject. For example:</p> -<pre class="turtle-code"> -<get-request> - a patch:Get ; - patch:subject <something> . -</pre> - -<p>Could result in:</p> -<pre class="turtle-code"> -[] - a patch:Response ; - patch:request <get-request> ; - patch:subject <something> ; - patch:body [ - eg:name "Something" ; - eg:ratio 1.6180339887 ; - ] . -</pre> - -<p>Note the use of blank nodes is not required; the value of patch:body may be -the actual resource node. Depending on the transport and syntax used this may -be preferable. For example, the same response could be written:</p> - -<pre class="turtle-code"> -<something> - eg:name "Something" ; - eg:ratio 1.6180339887 . - -[] - a patch:Response ; - patch:request <get-request> ; - patch:subject <something> ; - patch:body <something> . -</pre> - -<p>If the patch:subject property is absent, then the Get implicitly applies to -the receiver.</p> -""" . + rdfs:comment "A request for a description of the patch:subject." . patch:Insert a rdfs:Class ; @@ -142,11 +62,12 @@ patch:Insert owl:cardinality 1 ; owl:onProperty patch:subject ] ; - rdfs:comment "Insert the patch:body at patch:subject. If the subject does not exist, it is created. If the subject does already exist, it is added to. This request only adds properties, it never removes them. The user must take care that multiple values are not set for properties which should only have one value." . + rdfs:comment "A request to insert a patch:body into the patch:subject." . patch:Message a rdfs:Class ; - rdfs:label "Patch Message" . + rdfs:label "Patch Message" ; + rdfs:comment "A patch message." . patch:Move a rdfs:Class ; @@ -161,7 +82,7 @@ patch:Move owl:cardinality 1 ; owl:onProperty patch:destination ] ; - rdfs:comment """Move the patch:subject to patch:destination. After this, patch:destination has the description patch:subject had prior to this request's execution, and patch:subject no longer exists. It is an error if the subject does not exist or the destination already exists.""" . + rdfs:comment "A request to move the patch:subject to the patch:destination." . patch:Patch a rdfs:Class ; @@ -170,32 +91,17 @@ patch:Patch a owl:Restriction ; owl:minCardinality 1 ; owl:onProperty patch:subject + ] , [ + a owl:Restriction ; + owl:cardinality 1 ; + owl:onProperty patch:add + ] , [ + a owl:Restriction ; + owl:cardinality 1 ; + owl:onProperty patch:remove ] ; rdfs:label "Patch" ; - rdfs:comment "Add and/or remove properties of the subject." ; - lv2:documentation """ -<p>Add and/or remove properties of the subject.</p> - -<p>This method always has at least one patch:subject, and exactly one patch:add -and patch:remove property. The value of patch:add and patch:remove are nodes -which have the properties to add or remove from the subject(s), respectively. -The special value patch:wildcard may be used as the value of a remove property -to remove all properties with the given predicate. For example:</p> - -<pre class="turtle-code"> -[] - a patch:Patch ; - patch:subject <something> ; - patch:add [ - eg:name "New name" ; - eg:age 42 ; - ] ; - patch:remove [ - eg:name "Old name" ; - eg:age patch:wildcard ; # Remove all old eg:age properties - ] . -</pre> -""" . + rdfs:comment "A request to add and/or remove properties of the patch:subject." . patch:Put a rdfs:Class ; @@ -206,30 +112,19 @@ patch:Put owl:cardinality 1 ; owl:onProperty patch:subject ] ; - lv2:documentation """<p>Put the patch:body as the patch:subject. If the subject does not already exist, it is created. If the subject does already exist, the patch:body is considered an updated version of it, and the previous version is replaced.</p> - -<pre class="turtle-code"> -[] - a patch:Put ; - patch:subject <something> ; - patch:body [ - eg:name "New name" ; - eg:age 42 ; - ] . -</pre> -""" . + rdfs:comment "A request to put the patch:body as the patch:subject." . patch:Request a rdfs:Class ; rdfs:label "Request" ; rdfs:subClassOf patch:Message ; - rdfs:comment "A request. A request may have a patch:subject property, which indicates which resource the request applies to. The subject may be omitted in contexts where it is implicit (e.g. the recipient is the subject)." . + rdfs:comment "A patch request message." . patch:Response a rdfs:Class ; rdfs:subClassOf patch:Message ; rdfs:label "Response" ; - rdfs:comment "A response to a message." . + rdfs:comment "A response to a patch:Request." . patch:Set a rdfs:Class ; @@ -244,34 +139,7 @@ patch:Set owl:cardinality 1 ; owl:onProperty patch:value ] ; - rdfs:comment "Set one property to a specific value." ; - lv2:documentation """ -<p>A compact message for setting one property to a specific value.</p> - -<p>This is equivalent to a patch:Patch which removes <em>all</em> pre-existing -values for the property before setting the new value. For example:</p> - -<pre class="turtle-code"> -[] - a patch:Set ; - patch:subject <something> ; - patch:property eg:name ; - patch:value "New name" . -</pre> - -<p>Which is equivalent to:</p> -<pre class="turtle-code"> -[] - a patch:Patch ; - patch:subject <something> ; - patch:add [ - eg:name "New name" ; - ] ; - patch:remove [ - eg:name patch:wildcard ; - ] . -</pre> -""" . + rdfs:comment "A compact request to set a property to a value." . patch:accept a rdf:Property ; @@ -284,7 +152,8 @@ patch:add a rdf:Property , owl:ObjectProperty , owl:FunctionalProperty ; - rdfs:domain patch:Message ; + rdfs:domain patch:Patch ; + rdfs:range rdfs:Resource ; rdfs:label "add" ; rdfs:comment "The properties to add to the subject." . @@ -294,56 +163,43 @@ patch:body owl:FunctionalProperty ; rdfs:domain patch:Message ; rdfs:label "body" ; - rdfs:comment """The body of a message. - -The details of this property's value depend on the type of message it is a -part of.""" . + rdfs:comment "The body of a message." . patch:context a rdf:Property , owl:ObjectProperty ; rdfs:domain patch:Message ; rdfs:label "context" ; - rdfs:comment """The context of properties in this message. - -For example, a plugin may have a special context for ephemeral properties which -are only relevant during the lifetime of the instance and should not be saved -in state. - -The specific uses for contexts are application specific. However, the context -MUST be a URI, and can be interpreted as the ID of a data model where -properties should be stored. Implementations MAY have special support for -contexts, for example by storing in a quad store or serializing to a format -that supports multiple RDF graphs such as TriG. -""" . + rdfs:comment "The context of properties in this message." . patch:destination a rdf:Property , owl:ObjectProperty , owl:FunctionalProperty ; rdfs:domain patch:Message ; - rdfs:label "destination" . + rdfs:label "destination" ; + rdfs:comment "The destination to move the patch:subject to." . patch:property a rdf:Property ; rdfs:label "property" ; - rdfs:domain patch:Set ; + rdfs:domain patch:Message ; rdfs:range rdf:Property ; - rdfs:comment "The property for a Set message." . + rdfs:comment "The property for a patch:Set or patch:Get message." . patch:readable a rdf:Property ; rdfs:label "readable" ; rdfs:range rdf:Property ; - rdfs:comment """Indicates that the subject may have a property that can be read via a -patch:Get message. See the similar property patch:writable for details.""" . + rdfs:comment "A property that can be read with a patch:Get message." . patch:remove a rdf:Property , owl:ObjectProperty , owl:FunctionalProperty ; rdfs:label "remove" ; - rdfs:domain patch:Message ; + rdfs:domain patch:Patch ; + rdfs:range rdfs:Resource ; rdfs:comment "The properties to remove from the subject." . patch:request @@ -353,7 +209,7 @@ patch:request rdfs:label "request" ; rdfs:domain patch:Response ; rdfs:range patch:Request ; - rdfs:comment "The request this is a response to. This can be used if referring directly to the URI or blank node ID of the request is possible. Otherwise, use patch:sequenceNumber." . + rdfs:comment "The request this is a response to." . patch:sequenceNumber a rdf:Property , @@ -362,9 +218,7 @@ patch:sequenceNumber rdfs:label "sequence number" ; rdfs:domain patch:Message ; rdfs:range xsd:int ; - rdfs:comment """The sequence number of a request or response. This property is used to associate replies with requests when it is not feasible to refer to request URIs with patch:request. A patch:Response with a given sequence number is the reply to the previously send patch:Request with the same sequence number. - -The special sequence number 0 means no reply is desired. """ . + rdfs:comment "The sequence number of a request or response." . patch:subject a rdf:Property , @@ -383,30 +237,12 @@ patch:value patch:wildcard a rdfs:Resource ; - rdfs:comment "A wildcard which matches any resource. This makes it possible to describe the removal of all values for a given property." . + rdfs:label "wildcard" ; + rdfs:comment "A wildcard that matches any resource." . patch:writable a rdf:Property ; rdfs:label "writable" ; rdfs:range rdf:Property ; - lv2:documentation """ -<p>Indicates that subject may have a property that can be written via a patch -message. This is used to list supported properties, e.g. so user interfaces -can present appropriate controls. For example:</p> - -<pre class="turtle-code"> -@prefix eg: <http://example.org/> . -@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . -@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . -@prefix xsd: <http://www.w3.org/2001/XMLSchema#> . - -eg:title - a rdf:Property ; - rdfs:label "title" ; - rdfs:range xsd:string . - -eg:plugin - patch:writable eg:title . -</pre> -""" . + rdfs:comment "A property that can be set with a patch:Set or patch:Patch message." . |