This is an unnecessary intermediate class between the device and its characteristics, and should be deleted.
Proposed change: delete class DeviceCharacteristic.
DP deviceCharacteristicName "The commercial name of a device."@en
Proposed change: delete and use existing DPs saref:hasModel and saref:hasManufacturer
DP dimension: "The dimension of the device i.e. heightweightlength string."@en
Why weight ? should it be width ?
Proposed change: delete and use SAREF Core pattern for properties : define instances of saref:Property:
Proposed change: delete and use SAREF Core pattern for features, and SAREF Core pattern for properties:
Define instances of saref:Property:
From saref-portal#3
SAREF4ENVI, SAREF4WEAR, SAREF4LIFT, SAREF4WATR, all define some kind of communication protocols and interfaces.
Only SAREF4LIFT uses the patterns from SAREF4SYST for describing communication protocols. See Figure 18 at https://saref.etsi.org/saref4lift/v1.1.1/
SAREF4EHAW defines s4ehaw:CommunicationProtocol
SAREF4ENVI defines s4envi:usesCommunicationInterface and s4envi:usesCommmunicationProtocol, and s4envi:System, which from its definition read more like a CommunicatingSystem
DP s4watr:operatesAtRadioFrequency would best be applied to some ontology of communication protocols. Other extensions SAREF4LIFT, SAREF4EHAW, SAREF4WEAR, do define communication interfaces and protocols. Some harmonization would be required.
Discussion continued for SAREF4EHAW in #18
Related:
The SAREF Core pattern for states can be applied.
Suggested change: Delete the terms above, and define:
ChronicDisease a saref:State
"The situation of a patient that suffers from chronic disease, e.g. diabetes, asthma..."Asthma skos:broader ChronicDisease
"The situation of a patient that suffers from asthma, a chronic disease"Diabetes skos:broader ChronicDisease
"The situation of a patient that suffers from diabetes, a chronic disease"In practice:
<patient> saref:hasState s4ehaw:Asthma .
<sensor> saref:observes s4ehaw:Asthma .
...
BAN application domain is defined as "The BAN application domain, e.g. healthcare, telemedicine, assisted living, sport training, safety and emergency..."@en and it contains instances
SAREF Core pattern for Tasks seems suitable for this, and should be used instead.
It's the range of OP s4ehaw:hasBanApplicationDomain. This OP could be dropped, as the OP saref:accomplishes can be used instead.
We're left with:
s4ehaw:AssistedLiving a saref:Task .
s4ehaw:Emergency a saref:Task .
s4ehaw:Healthcare a saref:Task .
s4ehaw:PervasiveComputing a saref:Task .
s4ehaw:Prevention a saref:Task .
s4ehaw:Safety a saref:Task .
s4ehaw:SportTraining a saref:Task .
s4ehaw:Telemedicine a saref:Task .
Maxime Lefrançois (b759ed7f) at 28 Mar 09:19
AgeCategory is defined as "The age group of a health actor, e.g. old or young."@en The SAREF Core pattern for states can be used to model the AgeCategory.
s4ehaw:AgeCategory a saref:State .
s4ehaw:Old a saref:State ; skos:broader s4ehaw:AgeCategory .
s4ehaw:Young a saref:State ; skos:broader s4ehaw:AgeCategory .
And in practice:
<actor> saref:hasState s4ehaw:Old .
Activities are "The activity of a patient/user, i.e. daily and nocturnal activities."
Activity has an activityKind (datatype property), and two sub-classes: s4ehaw:DailyActivity and s4ehaw:NocturnalActivity These sub-classes sound like kinds of activities actually.
Arguably the SAREF Core pattern for states cannot represent activities, but it may be appropriate that SAREF4EHAW defines a similar pattern for activities.
s4ehaw:CommunicationProtocol is defined as "The communication protocol, e.g. BLE, serial, Ethernet..."@en
This class should be defined as sub-class of s4syst:Connection and saref:FeatureKind.
hasHub is a special case of s4syst:connectsSystem
Ban is a kind of Connection: A connection describes potential interactions between systems. Any two connected systems are connected through a connection. A connection can connect more than two systems at the same time.
This a s4ehaw:BAN could be defined as a sub-class of s4syst:Connection, and it s4syst:connectsSystem
some HealthDevice (but not only)
The naming "Type" should be avoided.
Related:
The term function lets me believe these could be defined as kinds of functions (of communication functions)
The part the type of communication carried out between BAN devices and BAN Hub lets me think it would best qualify the devices themselves, instead of the BAN (the network)
I suggest the following changes:
Modes aren't needed as they are subsumed by States from SAREF Core
Observation is used instead.
This implies the modification of the following entities:
Furthermore, s4envi:FrequencyMeasurement will be deleted.
SAREF4EHAW attempts to model time series as s4ehaw:TimeSeriesMeasurement, a subclass of saref:Measurement, which has exactly one xsd:decimal as a value. The modelling is partial. Time series may be of interest to other extensions. Some more discussion is needed to model time series in SAREF, and this part could be deleted from SAREF4EHAW in the meantime.
InterConnect has a different proposal.
I can agree it's relevant to annotate timeseries. But is it relevant to model all the datapoints of a timeseries in RDF ?
SAREF4EHAW attempts to model time series as s4ehaw:TimeSeriesMeasurement, a subclass of saref:Measurement, which has exactly one xsd:decimal as a value. The modelling is partial. Time series may be of interest to other extensions. Some more discussion is needed to model time series in SAREF, and this part could be deleted from SAREF4EHAW in the meantime.
InterConnect has a different proposal.
I can agree it's relevant to annotate timeseries. But is it relevant to model all the datapoints of a timeseries in RDF ?
In SAREF4EHAW it is unclear what the class s4ehaw:Data represents for functions, and how it is intended to be used. The definition states: “A function has one or many data”. It may indicate for the need to link a saref:Function to some instances of saref:Property (currently with OP s4ehaw:hasData), however a class is not needed for that.
Some classes are unnecessary named after the property they are the range of. For example s4ehaw:Contact is the range of s4ehaw:hasContact, and asserted to be equivalent to s4ehaw:HealthActor. Only the latest could suffice.
In SAREF4EHAW it is unclear what the class s4ehaw:Data represents for functions, and how it is intended to be used. The definition states: “A function has one or many data”. It may indicate for the need to link a saref:Function to some instances of saref:Property (currently with OP s4ehaw:hasData), however a class is not needed for that.
Some classes are unnecessary named after the property they are the range of. For example s4ehaw:Contact is the range of s4ehaw:hasContact, and asserted to be equivalent to s4ehaw:HealthActor. Only the latest could suffice.
Postures now best modeled as States from SAREF Core
From saref-portal#76
SAREF4BLDG links a feature of interest to a measurement first, which is then linked to the value and the property kind. It could be simpler to link features of interest directly to a property value.
The class s4auto:Movement contains five instances such as s4auto:crossingLeft and s4auto:crossingRight. These may be considered different possible values for the property s4auto:Movement. Their modelling could be updated in harmonization with the modelling of postures in SAREF4EHAW.
SAREF4EHAW defines one sub-class of saref:Property, s4ehaw:Posture, which has five instances such as s4ehaw:Walking. These may be considered different possible values for the property s4auto:Posture, which should be modelled as an instance of saref:Property. Their modelling could be updated in harmonization with the modelling of postures in s4auto:Movement.