search

mariapoveda / saref-ext

This repository contains the code and documentation generated for the SAREF extensions developed by OEG.
2 stars 10 forks source link

Don't create restrictions in reused terms #37

Closed rgcmme closed 5 years ago

rgcmme commented 5 years ago

Review the restrictions on reused terms. If we are restricting them with our properties, we have to specialize them.

mariapoveda commented 5 years ago

Does it applies to SAREF reuse?

rgcmme commented 5 years ago

Yes, if we specialize, it should be in our terms/namespace. Therefore, we have to see whether is is worth specializing some terms just for adding one or two properties.

mariapoveda commented 5 years ago

But if we need the properties it has to be specialized by need, if we follow this rule. There is no way of getting rid of the needed properties.

jonimoreira commented 5 years ago

Hi @mariapoveda and @rgcmme , I have a similar issue in SAREF4health [1]. In summary, I needed to represent the concept of Time Series for ECG data and I specialized it as a Measurement with two new restrictions:

:TimeSeriesMeasurements rdf:type owl:Class ; rdfs:comment "A sequence of data in a successive equally spaced points in time. The O&M ontology (ISO 19156) defines Time Series Observation as an “observation whose result is a time-series”, while both Hl7 aECG and DICOM standards define the Series element as a sequence of data sharing a common frame of reference. In SAREF4health we termed this concept as Time Series Measurements since this sequence of data refers to time series measured by a device. Notice that in this term we avoided prefixing with ECG because this concept can be applied to other types of data." ; rdfs:label "Time series measurements" ; rdfs:subClassOf saref:Measurement ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:allValuesFrom xsd:float ; owl:onProperty :hasValues ; ] ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:allValuesFrom saref4envi:FrequencyMeasurement ; owl:onProperty saref4envi:hasFrequencyMeasurement ; ] ; .

I'd like to exchange the restriction of saref:Measurement, eliminating the restriction of saref:hasValue and add the saref:hasValues - the basic idea is to allow this property to instantiate an array of floats.

However, removing this restriction in the subclass is not possible and we shouldn't change the saref:Measurement. So, I still have this open issue, requiring an instance of saref:TimeSeriesMeasurements to instantiate a saref:hasValue with something.

A possible solution, which I think is not the best, is to create saref:TimeSeriesMeasurements as a top level element (subclass of owl:Thing) and replicate all restrictions of saref:Measurement. But, conceptually, this looks wrong...

The best solution would be to remove the restriction saref:hasValue exactly 1 xsd:float from saref:Measurement in SAREF, but I know this would have a great impact, requiring a new version of SAREF...

What would you suggest?

Cheers,

Joao

[1] http://www.ebooks.iospress.com/volumearticle/50262 https://github.com/jonimoreira/INTER-IoT-EWS/blob/master/WP1-Ontology%20translations%20and%20rules/src/Ontologies/SAREF/saref4health.ttl

mariapoveda commented 5 years ago

@jonimoreira In line with your solution of removing the restriction "saref:hasValue exactly 1 xsd:float from saref:Measurement" in SAREF I would propose to relax it, instead of removing, to "saref:hasValue max 1 xsd:float from saref:Measurement"