From e0c4fb1bc1c66e5655a41ddcbfaafb07e32b93a2 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Fri, 26 Nov 2010 20:25:02 +0000 Subject: Mark up documentation with lv2:documentation as per discussion on lv2-dev. Use unified lv2plug.in style for ontology documentation. --- ext/message.lv2/message.ttl | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'ext/message.lv2') diff --git a/ext/message.lv2/message.ttl b/ext/message.lv2/message.ttl index ae7d438..b47ae56 100644 --- a/ext/message.lv2/message.ttl +++ b/ext/message.lv2/message.ttl @@ -37,65 +37,65 @@ foaf:homepage ; rdfs:seeAlso ] ; - rdfs:comment """ -This extension defines a standard for LV2 "messages" which allow dynamic + lv2:documentation """ +

This extension defines a standard for LV2 "messages" which allow dynamic control and investigation of plugin instances, by both hosts and other -plugins. +plugins.

-This extension requires the host to support the This extension requires the host to support the LV2 URI Map extension, and the -LV2 Atom extension. +LV2 Atom extension.

""" . msg:MessageType a rdfs:Class ; rdfs:label "LV2 Message Type" ; - rdfs:comment """ -Base class for all types of LV2 Message. + lv2:documentation """ +

Base class for all types of LV2 Message.

-A type of message, which must be a resource (i.e. have a URI). This URI +

A type of message, which must be a resource (i.e. have a URI). This URI is used as the selector component of a Message and is used by receivers to -interpret the meaning of messages (e.g. which components are present). +interpret the meaning of messages (e.g. which components are present).

-A message in memory is simply an A message in memory is simply an atom:Dict with at least one rdf:type that is a rdfs:subClassOf msg:MessageType. The definitions of various message types define what -other key/value pairs can be expected in the message. +other key/value pairs can be expected in the message.

""" . msg:ControlPort a rdfs:Class ; rdfs:label "Control Port" ; rdfs:subClassOf lv2:Port ; - rdfs:comment """ -An input port used to control a plugin instance. A plugin has + lv2:documentation """ +

An input port used to control a plugin instance. A plugin has at most 1 msg:ControlPort. A ControlPort is always an lv2:InputPort. Hosts can send messages to the control port in order to investigate or manipulate -a plugin instance (possibly on behalf of a UI or another plugin instance). +a plugin instance (possibly on behalf of a UI or another plugin instance).

-This is an abstract port class, the actual format and semantics +

This is an abstract port class, the actual format and semantics of the port buffer (and messages) are defined by some other port type, i.e. a cmdControlPort MUST have another type which defines the format and semantics of the port buffer contents (likely candidates are atom:MessagePort -or ev:EventPort). +or ev:EventPort).

""" . msg:ResponsePort a rdfs:Class ; rdfs:label "Response Port" ; rdfs:subClassOf lv2:Port ; - rdfs:comment """ -An output port used to notify the host about changes to a plugin instance + lv2:documentation """ +

An output port used to notify the host about changes to a plugin instance or respond to messages send to its msg:ControlPort. A plugin has at most 1 StatusPort. A StatusPort is always an lv2:OutputPort. Any response to a command sent to the CommandPort of the plugin will appear in the StatusPort output. The plugin may also emit other messages (i.e. the contents of a -StatusPort are not necessarily responses to commands). +StatusPort are not necessarily responses to commands).

-This is an abstract port class, the actual format and semantics +

This is an abstract port class, the actual format and semantics of the port buffer (and messages) are defined by some other port type, i.e. a cmdControlPort MUST have another type which defines the format and semantics of the port buffer contents (likely candidates are atom:MessagePort -or ev:EventPort). +or ev:EventPort).

""" . -- cgit v1.2.1