The service name is D-Bus application identifier, i.e. either the unique name handed out to the peer application by the bus on connect (see QDBusConnection::uniqueName()) or, more likely, a well known name the peer application has requested, see QDBusConnection::requestName()
Such well known names have the form of word separated by dots, like Internet domain names but in reverse order.
For example the name for the bus itself (the D-Bus daemon) would be
"org.freedesktop.DBus"
The object path is like an address within the peer host application. The path format looks like a Unix file path, i.e. words separated by slash '/'
characters.
For example the path for the bus itself (the D-Bus daemon's main object) would be
"/org/freedesktop/DBus"
The interface name specifies which group of methods and signals implemented by the peer service object is used in proxy operations.
Interface names have the form of word separated by dots, like Internet domain names but in reverse order or like a fully qualified Java class name.
For example the interface for the bus itself (the D-Bus daemon's main interface) would be
"org.freedesktop.DBus"
A D-Bus error name is a sequence of words separated by dots, similar to D-Bus service names or interface names, or like a fully qualified Java class name.
For example if a D-Bus service does not handle a method invocation sent to it because it doesn't know about the method it will return a D-Bus error named
"org.freedesktop.DBus.Error.UnknownMethod"
QDBusError can create some of the more common errors based on a type value and decode their names into the type respectively. See QDBusError::ErrorType
There is no mandatory convention for member names, neither for methods nor for signals.
However, using the standard interfaces of D-Bus as a hint, it is recommended to use "camel case" names starting with an uppercase letter, for example
"GetConnectionUnixUser"