Hello Such a search is possible already today, for instance by using the predefined tag CLASS and introducing a new tag POSITION, for instance. You can introduce any number of tags. With SPARQL however, you can do disitributed searches and use linked data. So, your search can include conditions on data that reside outside of your data set. You can also perform federated queries. You might, for instance only report the metering location (MLOC tag), but have all information about that metering location in a second database on a second machine. You could then make queries using SPARQL that included condition based on the data stored on the second machine. But as I mentioned in the previous mail, such searches are already possible, as long as you define a mapping from tag name to corresponding URI (In SPARQL, data items are identified and linked using URIs). Best regards, Peter Waher From: Joachim Lindborg [mailto:joachim.lindborg@sust.se] Sent: den 13 januari 2015 10:37 To: XMPP in the Internet of Things Subject: Re: [IOT] Semantic searches in registry That is very interesting i would like to find all "outside temperatures" tisdag 13 januari 2015 skrev Cramer, E.R. (Eelco) <Eelco.Cramer@tno.nl<mailto:Eelco.Cramer@tno.nl>>: Hi, I was wondering if anyone has considered of adding semantics to the IoT XMPP specs? I’m particularly interested in ways to add semantics to the IoT discovery XEP. Paragraph 5.2 of the XEP (https://xmpp.org/extensions/xep-0347.html#tags) describes a set of meta tags that can be used to describe things as it does put some limits on the values you can set. But I would like to link the meta-data to some sort of semantic ontologies (RDF). I then want to use that data to enable ’smarter’ queries to the registry (ie. sparql like queries). Is there any known work in this area? If I have any results of myself in this field I will share it on this list. Thanks, Eelco -- Regards Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: Joachim.lindborg@sust.se<mailto:Joachim.lindborg@sust.se> linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2014.0.4794 / Virus Database: 4257/8886 - Release Date: 01/07/15

Thanks Joachim and Peter for your quick replies. My initial thoughts were similar to what Peter is suggesting but I'm currently rethinking this and have the idea that this can be done in a more elegant way. I'm still very much in brain storm mode for this so maybe the ideas seem a bit wild or not well thought through but I would like to share some of my initial thoughts because some of this ideas might have been discussed before.

Would it be sufficient to map tag names to corresponding predefined semantic URLs? So that tags defined in XEP-0347 §5.2 also had a column with predefined semantic URLs, one for each tag (if available)?

That was my initial idea but what I do not like about this solution is that it is a rather arbitrary list and is left open to developers and users of the XEP on what to implement / use. I rather would use a solution were users can 'discover' the semantics that a registry is supporting. For example, add something to the discovery message of the registry that has information about the supported ontology.

Searching using SPARQL should be possible anyhow, if you have a SPARQL endpoint on your server. Tags could be identified by URLs of the following type. ROOM could correspond to URI urn:xmpp:iot:discovery:tags:room, for instance. If you want a HTTP-based URL, you could prefix the tag with the URL pointing to the server, like http://thingk.me/tags/room (and then provide some simple RDF when performing a GET to the corresponding URL).

Would that be sufficient?

Or do you want the sensor to register and update semantic URLs from the beginning? Perhaps as an optional parameter to the <str> and <num> tags? As follows:

<str name=’NAME’ url=’ http://www.w3.org/2000/01/rdf-schema#label’ value=’Ohlsson’/>

I'm thinking about having something like: <property name='man' value='www.ktc.se'/> or <property name='man' resource='http://www.manufacters.com/sweden/ktc'/> In RDF terms the 'Thing' would be the subject of the RDF triple, 'man' would be the property that would either have a property value or would link to another resource. Datatypes would be irrelevant IMO.

(Not to say that the NAME tag should correspond to rdfs:label, it’s just an example.)

As for SPARQL I would really like to have a way to send these queries inline XMPP so as a add-on or replacement for the current 'query language'. Thanks, Eelco This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Hey guys, I've tried to get more grip on the 'semantic registry' idea I've posted on before. I did not finalise my ideas but I am sending this in an early stage to get your feedback. What I did was put together a new proposal (if you like) of the XEP-0347 document that kind of describes which way I would like to see this go. You can check this document on: https://servicelab.github.io/iot-discovery.html About this document I would really like to get some feedback on: - What do you guys think of the concept of using 'semantic searches / linked data' in the registry? - What do you think of the way I've written this down? - Is this something to investigate further? Reading guidelines: Major changes are in 3.6 (registering), 3.15 (searching) and 5.2 (meta-information) but I've tried to make things consistent over the whole document (so also changed the other register chapters, updating and the XML schema). 3.6 - I've tried to make data types less relevant and made it possible to link to object instances that are defined elsewhere. 3.15 - I've tried to make it possible to define more complex queries to take advantage of computing power and indexes that are in the registry's backend. I've also added the possibility to execute functions remotely (just 2 for now but this can be extended). 5.2 - I've made 2 RDF schema's. 1 containing an ontology for basic XMPP things (all optional and mandatory stuff for addressing) and another ontology that holds the common meta-information tags that were already defined in the document. What I do not like yet is: - What is still missing is some way to 'discover' the ontology that is supported by the registry. - That there is a 'default' namespace for properties that cannot be set by the sender of the message. I would probably like to have a way that a 'default' can be provided by the sender. Maybe an attribute 'defaultns' in the parent elements or something like that. I understand that what I am proposing is not backwards compatible with the current state of the document but I believe it is a nice step forwards and opens up some great new possibilities in the future! Thanks, Eelco This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Hi, I've updated the document on https://servicelab.github.io/iot-discovery.html in an attempt to solve issues that I was still having with this proposal.

On 05 Feb 2015, at 14:19, Cramer, E.R. (Eelco) <Eelco.Cramer@tno.nl> wrote:

What I do not like yet is:

- What is still missing is some way to 'discover' the ontology that is supported by the registry.

I've updated the'Determining support' paragraph with a method to discover namespaces. https://servicelab.github.io/iot-discovery.html#support

- That there is a 'default' namespace for properties that cannot be set by the sender of the message. I would probably like to have a way that a 'default' can be provided by the sender. Maybe an attribute 'defaultns' in the parent elements or something like that.

I added a 'defaultns' attribute to the parent element of 'property' elements that must be used to set a default namespace for the properties. What do you guys think? Cheers, Eelco This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Hi Johannes, Thanks for your response! An important design principal I had when I wrote the proposal was that I did not want to force a database technology if someone would implement the spec. This was the major reason for me not to use RDF or SPARQL in the spec. The spec should be implementable on other technologies as well. Of course this principal is up for discussion. Choosing a technology would probably simplify the protocol and extend usage options (allowing more complex queries). What do you think about this? Also I have a more specific question on the example you provided. Is there a way to 'pre-define' namespaces in XMPP? They way I see it is the XML stream is opened upon connection and there is no way to add namespaces on the go hence the usage of the 'xmlns' attribute to switch to a specific context. Best regards, Eelco

On 17 Mar 2015, at 14:03, Hund, Johannes <johannes.hund@siemens.com> wrote:

Hello Eelco,

I discussed this with colleagues that are more active in semweb topics and they had the suggestion to reuse more existing formats for serialization. See attached an example using RDF/XML that also shows how a GeoSPARQL query could be expressed in XML (using SWRL rules).

What do you think?

Best regards, Johannes

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.