search

OpenIotOrg / openiot

The Open Source Project for the Internet of Things
461 stars 189 forks source link

SecurityIntegration: LSM-XGSN: can't push data #80

Closed hylkevds closed 10 years ago

hylkevds commented 10 years ago

After registering a sensor through LSM I can't push data, because LSM doesn't recognise the sensor metadata that is in virtuoso.

GSN log:

09:13:02.371 [     qtp2117676256-22] INFO  o.openiot.lsm.server.LSMTripleStore - Your request processed successfully
09:13:02.372 [     qtp2117676256-22] INFO  o.openiot.lsm.server.LSMTripleStore - sensor id returns:http://openiot.eu/resource/60856461521576
09:13:02.372 [     qtp2117676256-22] INFO  o.o.g.http.restapi.VSManagerService - SensorId has changed from null to http://openiot.eu/resource/60856461521576.
09:13:03.104 [VSensorLoader-Thread0] INFO  o.o.g.w.t.SingletonTcpListenWrapper - Initialising wrapper SingletonTcpListenWrapper-Thread-1.
09:13:03.112 [VSensorLoader-Thread0] DEBUG c.u.c.network.message.FactoryMessage - Registering message with key ID from class: org.openiot.gsn.wrappers.tcplistener.MessageIdData
09:13:03.423 [VSensorLoader-Thread0] WARN  org.openiot.gsn.VSensorLoader - adding : testsensor1 virtual sensor[/home/scf/NetBeansProjects/OpenIoT/OpenIotSecurity/OpenIotOrg/modules/x-gsn/virtual-sensors/testsensor1.xml]
09:13:03.425 [VSensorLoader-Thread0] DEBUG o.o.g.metadata.LSM.LSMSensorMetaData - Read file /home/scf/NetBeansProjects/OpenIoT/OpenIotSecurity/OpenIotOrg/modules/x-gsn/virtual-sensors/testsensor1.metadata
09:13:03.428 [VSensorLoader-Thread0] INFO  o.o.g.metadata.LSM.LSMSensorMetaData - 0 : field1
09:13:03.428 [VSensorLoader-Thread0] INFO  org.openiot.gsn.vsensor.LSMExporter - Sensor has 1 outputfields.
09:13:03.428 [VSensorLoader-Thread0] INFO  org.openiot.gsn.vsensor.LSMExporter - Property:field1--null
09:13:03.428 [VSensorLoader-Thread0] INFO  org.openiot.gsn.vsensor.LSMExporter - Allow nulls => false
09:13:03.428 [VSensorLoader-Thread0] INFO  org.openiot.gsn.vsensor.LSMExporter - field1
09:13:03.429 [VSensorLoader-Thread0] DEBUG org.openiot.gsn.VirtualSensor - Created a new instance for VS testsensor1
09:13:11.897 [SingletonTcpListenWrapper-Thread-1] DEBUG org.openiot.gsn.vsensor.LSMExporter - FIELD1 : t=Tue Aug 19 09:13:11 CEST 2014 v=2809.0
09:13:11.898 [SingletonTcpListenWrapper-Thread-1] DEBUG o.o.gsn.metadata.LSM.SensorAnnotator - Update sensor data: http://openiot.eu/resource/60856461521576,http://openiot.eu/OpenIoT/Random1,http://openiot.eu/OpenIoT/sensormeta#,http://openiot.eu/OpenIoT/sensordata#,http://lsm.deri.ie/OpenIoT/opensensefeature,2809.0
09:13:11.898 [SingletonTcpListenWrapper-Thread-1] DEBUG o.o.commons.util.PropertyManagement - jbosServerConfigDir:null/openiot.properties
09:13:11.898 [SingletonTcpListenWrapper-Thread-1] WARN  o.o.commons.util.PropertyManagement - Unable to find file: null/openiot.properties
09:13:12.020 [SingletonTcpListenWrapper-Thread-1] INFO  o.openiot.lsm.server.LSMTripleStore - Sensor http://openiot.eu/resource/60856461521576 has not been registered yet. Please register your sensor!
09:13:12.020 [SingletonTcpListenWrapper-Thread-1] INFO  o.openiot.lsm.server.LSMTripleStore - Sensor data is updated successfully
09:13:12.020 [SingletonTcpListenWrapper-Thread-1] INFO  o.openiot.lsm.server.LSMTripleStore - Please use OpenIoT LSM Sparql Endpoint to check it

LSM log:

09:14:40,560 INFO  [stdout] (http--127.0.0.1-8080-5) 09:14:40.560 [http--127.0.0.1-8080-5] INFO  o.openiot.lsm.manager.SensorManager - executing query:
09:14:40,560 INFO  [stdout] (http--127.0.0.1-8080-5) sparql select ?name ?sensorType ?author  ?place   from <http://openiot.eu/OpenIoT/sensormeta#> 
09:14:40,561 INFO  [stdout] (http--127.0.0.1-8080-5) where{ <http://openiot.eu/resource/60856461521576> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.oclc.org/NET/ssnx/ssn#Sensor>.<http://openiot.eu/resource/60856461521576> <http://www.w3.org/ns/prov#wasGeneratedBy> ?author.<http://openiot.eu/resource/60856461521576> <http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation> ?place.<http://openiot.eu/resource/60856461521576> <http://www.w3.org/2000/01/rdf-schema#label> ?name.<http://openiot.eu/resource/60856461521576> rdf:type ?sensorType.}
09:14:40,564 INFO  [stdout] (http--127.0.0.1-8080-5) 09:14:40.564 [http--127.0.0.1-8080-5] INFO  org.openiot.lsm.http.ObjectServlet - Sensor http://openiot.eu/resource/60856461521576 has not been registered yet. Please register your sensor!

What is in virtuoso regarding this sensor:

SELECT ?s ?p ?o
WHERE {<http://openiot.eu/resource/60856461521576> ?p ?o}

p   o
http://www.w3.org/1999/02/22-rdf-syntax-ns#type testType
http://www.w3.org/2000/01/rdf-schema#label  "SomeNameHere"
http://www.w3.org/2000/01/rdf-schema#subClassOf http://purl.oclc.org/NET/ssnx/ssn#Sensor
http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation    http://openiot.eu/resource/60856463386769
http://purl.org/net/provenance/ns#PerformedAt   2014-08-19T09:13:02+02:00
http://purl.oclc.org/NET/ssnx/ssn#observes  http://openiot.eu/resource/60857970453893
http://www.w3.org/ns/prov#wasGeneratedBy    FraunhoferIOSB

I'm guessing it is because testType is not actually a sensor type. If that is indeed the case, then how do I register a sensor type?

jpcik commented 10 years ago

How was the sensor registered? via lsm_register, using a metadata file?

jpcik commented 10 years ago

In any case, LSM looks for the following sensor metadata (Actually this is not related to gsn, this is what LSM server looks for in virtuoso)

sparql select ?name ?sensorType ?author ?place "+ " from <"+ metaGraph +"> \n" + "where{ "+ "<"+id+"> http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://purl.oclc.org/NET/ssnx/ssn#Sensor."+ "<"+id+"> http://www.w3.org/ns/prov#wasGeneratedBy ?author."+ "<"+id+"> http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation ?place."+ "<"+id+"> http://www.w3.org/2000/01/rdf-schema#label ?name."+ "<"+id+"> rdf:type ?sensorType."+

hylkevds commented 10 years ago

Yes, it was registered using a metadata file, over the rest interface. I also suspect it's that first restriction in the where that is the problem. That seems to look for something that is an SSN#Sensor. So I guess we need the schema editor for that?

jpcik commented 10 years ago

Ok I confirm the issue. I registered sensors with RDF directly that's why it worked in my previous tests. LSM registers using 'subclassOf ssn:Sensor' but it looks for 'typeOf' ssn:Sensor

nmqhoan commented 10 years ago

Thanks, I will test the code and update it.

On 19 Aug 2014, at 10:23, Hylke van der Schaaf notifications@github.com wrote:

Reopened #80.

— Reply to this email directly or view it on GitHub.

premjayaraman commented 10 years ago

Confirm the issue...!!! The only place that uses the subclassOf is the sensorMeta.xsl

Rest of LSM only uses #type to represent sensor type.

This could be a time consuming fix with a likelihood of affecting the functioning of the request definition and presentation interfaces as I am not sure what SPARQL it uses to get list of sensors and so on.!!!!

jpcik commented 10 years ago

Using rdf:type ssn:Sensor should be fine IMO, I don't see why it should be subclassOf.

nmqhoan commented 10 years ago

The reason is to identify the sensorType. The previous version uses sensorType as a label and it will make the data seems to be not correct (i.e.: becoming messy if the user register a new sensor type with typos…). As we already discussed in Malta, the sensorType can be a subclass of ssn:Sensor. It also means that if the user want to add a new sensor with a new type, he has to extend the ontology. In this case, he has to use the schema editor. I’m still finding another way around to solve this issue but I haven’t figured out yet.

Any suggestion?

On 19 Aug 2014, at 17:22, Jean-Paul Calbimonte notifications@github.com wrote:

Using rdf:type ssn:Sensor should be fine IMO, I don't see why it should be subclassOf.

— Reply to this email directly or view it on GitHub.

premjayaraman commented 10 years ago

If I am correct, xGSN only registers the sensor instance and not the sensor Type.

Hence, the sensorType will not be a subclass of ssn:Sensor.

The sensorType will be a subclass of another resouce id which will inturn be the subclass of ssn:Sensor.

See below as how In the schema editor, I have currently taken this apporach based on our previous discussions and comments from Myriam.

For Sensor Type, I define a class Demo which is a subclass of ssn:Sensor When I store this in LSM after converting it using Apache Jena.

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://services.openiot.eu/resources#Demo ?o ?p }

o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://www.w3.org/2002/07/owl#Class

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/AirTemperature"

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/Humidity"

http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability

http://services.openiot.eu/resources#mct1408438026556

From here, I use xGSN LSM metadata creator code (not via RDF) to create a sensor instance. As you see I was using the previous version (from develop and not security-integration)

Since it is not RDF, LSM re-inserted the sensorType as ssnSensor and also repeats the observes part.

Further, the sensorType is stored as a label under the resource id connected via the hasSensorType

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/3952855311084705 ?o ?p }

o

P

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://lsm.deri.ie/ont/lsm.owl#SensorType

http://www.w3.org/2000/01/rdf-schema#label

"http://services.openiot.eu/resources#Demo"

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/2532521733448080 ?o ?p } o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://www.w3.org/2000/01/rdf-schema#label

"instancedemo"

http://purl.org/net/provenance/ns#PerformedAt

2014-08-19T09:48:20.648+01:00

http://purl.org/net/provenance/ns#PerformedBy

http://localhost:22001http://localhost:22001/

http://lsm.deri.ie/ont/lsm.owl#hasSourceType

"gsn"

http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation

http://lsm.deri.ie/resource/2532521734238001

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311109434

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311116909

http://lsm.deri.ie/ont/lsm.owl#hasSensorType

http://lsm.deri.ie/resource/3952855311084705

As far as my suggestions, it think we will need to rethink this as changes to the ontology concepts will result in changes to other component.

I tested by changing the subclassOf property to type. I was able to push data into LSM via xGSN as the registered sensor was found (getting rid of the previous error).

But the request definition was not able to discover the sensor since a discover query returned two values

  1.  The type ssn:Sensor
  2.  The actual sensor I was looking for e.g. laussane

I did not dig further, I will investigate it further and report.

In the meantime, I suggest we have a quick webex including Jean-Paul, Hoan, myself, Hylke and Nikos to see how we can work this around without impacting the other components.

In my view, this will need a good discussion to have a proper solution which we don’t have to revisit in the future.

Thanks and Regards prem

From: nmqhoan [mailto:notifications@github.com] Sent: Wednesday, 20 August 2014 2:35 AM To: OpenIotOrg/openiot Cc: Jayaraman, Prem (DP&S, Acton) Subject: Re: [openiot] SecurityIntegration: LSM-XGSN: can't push data (#80)

The reason is to identify the sensorType. The previous version uses sensorType as a label and it will make the data seems to be not correct (i.e.: becoming messy if the user register a new sensor type with typos…). As we already discussed in Malta, the sensorType can be a subclass of ssn:Sensor. It also means that if the user want to add a new sensor with a new type, he has to extend the ontology. In this case, he has to use the schema editor. I’m still finding another way around to solve this issue but I haven’t figured out yet.

Any suggestion?

On 19 Aug 2014, at 17:22, Jean-Paul Calbimonte notifications@github.com<mailto:notifications@github.com> wrote:

Using rdf:type ssn:Sensor should be fine IMO, I don't see why it should be subclassOf.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenIotOrg/openiot/issues/80#issuecomment-52661363.

nmqhoan commented 10 years ago

Thanks Prem for your suggestion. I totally agree with you, we should have a good webex discussion relating to this issue. As tomorrow morning (Irish time), we will have a weekly OpenIoT webex, can you guys join this so we can discuss?

Hoan Nguyen Mau Quoc Sensor Middleware Unit DERI, National University of Ireland, Galway

On 20 Aug 2014, at 02:08, Prem Jayaraman notifications@github.com wrote:

If I am correct, xGSN only registers the sensor instance and not the sensor Type.

Hence, the sensorType will not be a subclass of ssn:Sensor.

The sensorType will be a subclass of another resouce id which will inturn be the subclass of ssn:Sensor.

See below as how In the schema editor, I have currently taken this apporach based on our previous discussions and comments from Myriam.

For Sensor Type, I define a class Demo which is a subclass of ssn:Sensor When I store this in LSM after converting it using Apache Jena.

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://services.openiot.eu/resources#Demo ?o ?p }

o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://www.w3.org/2002/07/owl#Class

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/AirTemperature"

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/Humidity"

http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability

http://services.openiot.eu/resources#mct1408438026556

From here, I use xGSN LSM metadata creator code (not via RDF) to create a sensor instance. As you see I was using the previous version (from develop and not security-integration)

Since it is not RDF, LSM re-inserted the sensorType as ssnSensor and also repeats the observes part.

Further, the sensorType is stored as a label under the resource id connected via the hasSensorType

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/3952855311084705 ?o ?p }

o

P

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://lsm.deri.ie/ont/lsm.owl#SensorType

http://www.w3.org/2000/01/rdf-schema#label

"http://services.openiot.eu/resources#Demo"

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/2532521733448080 ?o ?p } o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://www.w3.org/2000/01/rdf-schema#label

"instancedemo"

http://purl.org/net/provenance/ns#PerformedAt

2014-08-19T09:48:20.648+01:00

http://purl.org/net/provenance/ns#PerformedBy

http://localhost:22001http://localhost:22001/

http://lsm.deri.ie/ont/lsm.owl#hasSourceType

"gsn"

http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation

http://lsm.deri.ie/resource/2532521734238001

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311109434

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311116909

http://lsm.deri.ie/ont/lsm.owl#hasSensorType

http://lsm.deri.ie/resource/3952855311084705

As far as my suggestions, it think we will need to rethink this as changes to the ontology concepts will result in changes to other component.

I tested by changing the subclassOf property to type. I was able to push data into LSM via xGSN as the registered sensor was found (getting rid of the previous error).

But the request definition was not able to discover the sensor since a discover query returned two values

  1. The type ssn:Sensor
  2. The actual sensor I was looking for e.g. laussane

I did not dig further, I will investigate it further and report.

In the meantime, I suggest we have a quick webex including Jean-Paul, Hoan, myself, Hylke and Nikos to see how we can work this around without impacting the other components.

In my view, this will need a good discussion to have a proper solution which we don’t have to revisit in the future.

Thanks and Regards prem

From: nmqhoan [mailto:notifications@github.com] Sent: Wednesday, 20 August 2014 2:35 AM To: OpenIotOrg/openiot Cc: Jayaraman, Prem (DP&S, Acton) Subject: Re: [openiot] SecurityIntegration: LSM-XGSN: can't push data (#80)

The reason is to identify the sensorType. The previous version uses sensorType as a label and it will make the data seems to be not correct (i.e.: becoming messy if the user register a new sensor type with typos…). As we already discussed in Malta, the sensorType can be a subclass of ssn:Sensor. It also means that if the user want to add a new sensor with a new type, he has to extend the ontology. In this case, he has to use the schema editor. I’m still finding another way around to solve this issue but I haven’t figured out yet.

Any suggestion?

On 19 Aug 2014, at 17:22, Jean-Paul Calbimonte notifications@github.com<mailto:notifications@github.com> wrote:

Using rdf:type ssn:Sensor should be fine IMO, I don't see why it should be subclassOf.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenIotOrg/openiot/issues/80#issuecomment-52661363. — Reply to this email directly or view it on GitHub.

premjayaraman commented 10 years ago

Sure!!

Could you please send us an invite with webex connection details.

Thanks Prem

From: nmqhoan [notifications@github.com] Sent: Wednesday, August 20, 2014 5:35 PM To: OpenIotOrg/openiot Cc: Jayaraman, Prem (DP&S, Acton) Subject: Re: [openiot] SecurityIntegration: LSM-XGSN: can't push data (#80)

Thanks Prem for your suggestion. I totally agree with you, we should have a good webex discussion relating to this issue. As tomorrow morning (Irish time), we will have a weekly OpenIoT webex, can you guys join this so we can discuss?

Hoan Nguyen Mau Quoc Sensor Middleware Unit DERI, National University of Ireland, Galway

On 20 Aug 2014, at 02:08, Prem Jayaraman notifications@github.com wrote:

If I am correct, xGSN only registers the sensor instance and not the sensor Type.

Hence, the sensorType will not be a subclass of ssn:Sensor.

The sensorType will be a subclass of another resouce id which will inturn be the subclass of ssn:Sensor.

See below as how In the schema editor, I have currently taken this apporach based on our previous discussions and comments from Myriam.

For Sensor Type, I define a class Demo which is a subclass of ssn:Sensor When I store this in LSM after converting it using Apache Jena.

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://services.openiot.eu/resources#Demo ?o ?p }

o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://www.w3.org/2002/07/owl#Class

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/AirTemperature"

http://purl.oclc.org/NET/ssnx/ssn#observes

"http://lsm.deri.ie/Humidity"

http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability

http://services.openiot.eu/resources#mct1408438026556

From here, I use xGSN LSM metadata creator code (not via RDF) to create a sensor instance. As you see I was using the previous version (from develop and not security-integration)

Since it is not RDF, LSM re-inserted the sensorType as ssnSensor and also repeats the observes part.

Further, the sensorType is stored as a label under the resource id connected via the hasSensorType

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/3952855311084705 ?o ?p }

o

P

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://lsm.deri.ie/ont/lsm.owl#SensorType

http://www.w3.org/2000/01/rdf-schema#label

"http://services.openiot.eu/resources#Demo"

select * from http://lsm.deri.ie/OpenIoT/guest/sensormeta# where { http://lsm.deri.ie/resource/2532521733448080 ?o ?p } o

p

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

http://purl.oclc.org/NET/ssnx/ssn#Sensor

http://www.w3.org/2000/01/rdf-schema#label

"instancedemo"

http://purl.org/net/provenance/ns#PerformedAt

2014-08-19T09:48:20.648+01:00

http://purl.org/net/provenance/ns#PerformedBy

http://localhost:22001http://localhost:22001/

http://lsm.deri.ie/ont/lsm.owl#hasSourceType

"gsn"

http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation

http://lsm.deri.ie/resource/2532521734238001

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311109434

http://purl.oclc.org/NET/ssnx/ssn#observes

http://lsm.deri.ie/resource/3952855311116909

http://lsm.deri.ie/ont/lsm.owl#hasSensorType

http://lsm.deri.ie/resource/3952855311084705

As far as my suggestions, it think we will need to rethink this as changes to the ontology concepts will result in changes to other component.

I tested by changing the subclassOf property to type. I was able to push data into LSM via xGSN as the registered sensor was found (getting rid of the previous error).

But the request definition was not able to discover the sensor since a discover query returned two values

  1. The type ssn:Sensor
  2. The actual sensor I was looking for e.g. laussane

I did not dig further, I will investigate it further and report.

In the meantime, I suggest we have a quick webex including Jean-Paul, Hoan, myself, Hylke and Nikos to see how we can work this around without impacting the other components.

In my view, this will need a good discussion to have a proper solution which we don’t have to revisit in the future.

Thanks and Regards prem

From: nmqhoan [mailto:notifications@github.com] Sent: Wednesday, 20 August 2014 2:35 AM To: OpenIotOrg/openiot Cc: Jayaraman, Prem (DP&S, Acton) Subject: Re: [openiot] SecurityIntegration: LSM-XGSN: can't push data (#80)

The reason is to identify the sensorType. The previous version uses sensorType as a label and it will make the data seems to be not correct (i.e.: becoming messy if the user register a new sensor type with typos…). As we already discussed in Malta, the sensorType can be a subclass of ssn:Sensor. It also means that if the user want to add a new sensor with a new type, he has to extend the ontology. In this case, he has to use the schema editor. I’m still finding another way around to solve this issue but I haven’t figured out yet.

Any suggestion?

On 19 Aug 2014, at 17:22, Jean-Paul Calbimonte notifications@github.com<mailto:notifications@github.com> wrote:

Using rdf:type ssn:Sensor should be fine IMO, I don't see why it should be subclassOf.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenIotOrg/openiot/issues/80#issuecomment-52661363. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenIotOrg/openiot/issues/80#issuecomment-52743159.

nmqhoan commented 10 years ago

just fixed the bugs. Please recheck.

hylkevds commented 10 years ago

Yep, it works!