Admin message

WARNING! Gitlab maintenance operation scheduled for Thursday, 18 June between 19:00 and 20:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.

Modelling Services, including ServiceProcess, ServiceProfile
SAREF4EHAW extends the definition of saref:Service with ServiceProcess and ServiceProfile - ServiceProcess: "How the service works."@en - OP s4ehaw:isDescribedBy links a Service to the ServiceProcess: "A service is described by a service process (how the service works)."@en - ServiceProfile: "A service presents a service profile (what the service does)."@en - OP s4ehaw:presents "A service presents a service profile (what the service does)."@en General remarks: - Why an intermediate class ? why not attaching these properties directly to the Service ? - the Service actually groups operations. Operations are executed. Not the service Proposed change: Attach whatever is attached to these intermediate classes to the service directly, unless there a service may have more than one process / more than one profile, etc. In details: ## ServiceProcess Related: - hasCalculationMethod rdfs:comment "The service process has a calculation method to get the output or result, e.g. the calculation formula to determine the posture of a patient."@en - hasEffect rdfs:comment "The effect of a service can be an alert, nothing, an activation of another process..."@en - hasInput rdfs:comment "The service process has data input like e.g. the patient ID, the timestamp, the read value from a sensor..."@en - hasOutput rdfs:comment "The output is e.g. the calculated value returned by the process, e.g the posture of a patient."@en - hasResult rdfs:comment "The process can have many results for the same output. Those results may include a message that should be displayed, an alert..."@en - hasPrecondition rdfs:comment "The conditions that are imposed over the inputs of the process and the process must hold to be successufully invoked."@en Notes: - Why just "the posture" ? - SAREF already introduces hasInput, hasOutput, hasResult. hasEffect and hasPrecondition could be re-defined to be applicable along saref:hasInput / saref:hasOutput ## ServiceProfile - DP serviceDescription domain ServiceProfile, range xsd:string - DP serviceName domain ServicePRofile, range xsd:string Proposed change: Reuse standard rdfs:label, rdfs:comment, dct:description
issue