- From: Catherine Roussey <catherine.roussey@irstea.fr>
- Date: Mon, 15 May 2017 12:10:44 +0200
- To: Maxime Lefrançois <maxime.lefrancois@emse.fr>, Armin Haller <armin.haller@anu.edu.au>, "public-sdw-comments@w3.org" <public-sdw-comments@w3.org>
- Message-ID: <e7899936-9ea5-347a-b57e-d523fc4b9a45@irstea.fr>
Dear Maxime thank for the comment I understand now what you want in sosa. But if we modelize like that, what is the purpose of the Sample class and individual? all instance of sample will be instance of featureOfInterest. So why two classes for the same individuals? Your modelization will impact the fact that for each new farm we will have to create some individuals of feature of interest and property Moreover this modelization will not work for weather data. you can not create as many individuals as many weather station location. I like the fact in ssn that we resued some existing individuals of featureOfInterest and property. These individuals were generated by some weather standards. So it is more easy to find all the measurement associated to pre defined weather featureofinterest and property. So maybe you need to create two design pattern one generic with generic individuals of feature of interest and property like in weather data. and a more precise design pattern with individuals of sample and property. the object property should be the same but the individuals and classes are differents. You will have to define the link between the generic design pattern and the specific one because we need to query the data at the different level of details. Best Regards Catherine Le 15/05/2017 à 11:00, Maxime Lefrançois a écrit : > Dear Catherine, > > Thank you for your comments. > > In a nutshell, according to the original SSN, a feature of interest > would be "plot X", and a property would not be generic but would be > specific to "plot X", like: "temperature of soil at 3 meter depth in > plot X". > > see also section 5.3.1.3.4 in > https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/#Observed_Properties_2 > > > /Observed Properties:/ObservedProperty is defined as a subclass of > DUL:Quality. Types of properties, such as temperature or pressure > should be added as subclasses of ObservedProperty instead of > individuals. A new relation called SSO:isPropertyOf is defined as a > subrelation of DUL:isQualityOf to relate a property to a feature of > interest. > > > Hence generic Feature of Interest and Properties are modeled as > classes: "the class of plot", or "the class of temperatures of soil at > 3 meter depth". A repository in the agriculture domain would define > *classes* of feature of interest and *classes* of properties that may > apply to them, and you would instantiate these classes in datasets. > > > On the other hand, in existing SSN datasets, instances of > oldssn:Property are often generic and can apply to more than one > feature of interest. > Although it contradicts the original specification, this way of > modeling the domain seems to have become the post-facto standard. > > > This has been extensively discussedin the group lately, see also: > - > https://www.w3.org/2015/spatial/wiki/Link_between_FeatureOfInterest_and_xxxProperty#What_is_an_instances_of_ssn:Property_.3F > -https://lists.w3.org/Archives/Public/public-sdw-wg/2017May/0129.html > - https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0336.html > - https://lists.w3.org/Archives/Public/public-sdw-wg/2017May/0098.html > <https://lists.w3.org/Archives/Public/public-sdw-wg/2017Apr/0336.html> > > > We will hopefully be able to decide on this late issue during our > meeting tomorrow. Anyways, soon after the decision is made we will > enhance the examples to better illustrate how features of interest, > properties, and samples, can play together. > > Kind regards, > Maxime Lefrançois > > > > Le lun. 15 mai 2017 à 10:18, Catherine Roussey > <catherine.roussey@irstea.fr <mailto:catherine.roussey@irstea.fr>> a > écrit : > > Thanks for the information > > I have found how to define the unit thanks to your QUDT example. > > I still find strange the way you use feature of interets and property. > > It seems as far as I understand that the property belong to the > instance of the feature of interest and are not generic. > > in the appartement example electrical consumption may be apply to > different type of feature of interest so I found the URI of the > property quite strange. > > Why in the URI of property there is an indication of the instance > appartment/134/ electricalconsumption or tree/124#height > > I was expecting that at the end there will exist some repositoryof > instance per domain that list all the possible feature of interest > and property. The sample will help to identify exactly how the > property of the feature of interest is measured. > > for example in the agriculture domain, I would expect that we > define a repository per agriculture domain : > > soil temperature and humidity at 3 meter or 6 meter depth > (whatever the plot is): feature of interest (soil at 3 meter > depth) property (temperature) > > air temperature and humidity at 2 meter height (wherever we are): > featureof interest (outdoor air around 2 meter height) property > (temperature) > > air temperature and humidity of a breeding building...(for any > breeding building): feature of interest (indoor air) property > (temperature) > > The repository is generic so the sample will help to identify > where the sensor are located and what is measured exactly. > > But as far as I understand your example > > you will imagine that we will change the repository of instances > to be more precise. A repository per specific farm. > > . The property is linked to the instance of feature of interest. > > temperature and humidity at 3 meter or 6 meter depth of the plot > soil located at .... (how can we access the measure with a query > about soil temperature at 3 meter depth?) > > So at the moment I do not see how feature of interest, property > and sample can play together. > > I miss something. > > > > <https://www.w3.org/2015/spatial/track/actions/349%29> > > Best Regards <https://www.w3.org/2015/spatial/track/actions/349%29> > > Catherine > <https://www.w3.org/2015/spatial/track/actions/349%29> > > > Le 15/05/2017 à 08:44, Armin Haller a écrit : >> >> Hi Catherine, >> >> Thanks for your additional comments. The examples on Github is a >> bit outdated and we are currently working on a new example. It is >> currently undergoing review: https://github.com/w3c/sdw/pull/891. >> The issue you raise regarding what is a FeatureOfInterest and >> what is the Property is currently being discussed in the group >> (see also https://www.w3.org/2015/spatial/track/actions/349) >> <https://www.w3.org/2015/spatial/track/actions/349%29>. The >> hasProperty and isPropertyOf relations that relate a Property to >> a FeatureOfInterest are currently only defined in SSN, but we are >> considering their inclusion in the SOSA core. >> >> The hasValue property has actually been replaced by the >> hasSimpleResult property which can be used to attach a value to >> an Observation/Actuation. If units of measurement are attached, >> the use of the sosa:Result class is required. For units of >> measurement SOSA as well as SSN are relying on external >> ontologies such as the QUDT. However, we will include an example >> how to attach a unit of measure to a sosa:Result using an >> external ontology such as QUDT. >> >> Kind regards, >> Armin >> >> *From: *Catherine Roussey <catherine.roussey@irstea.fr> >> <mailto:catherine.roussey@irstea.fr> >> *Date: *Wednesday, 10 May 2017 at 8:25 pm >> *To: *"public-sdw-comments@w3.org" >> <mailto:public-sdw-comments@w3.org> <public-sdw-comments@w3.org> >> <mailto:public-sdw-comments@w3.org> >> *Subject: *Re: Comment on the SOSA ontology >> *Resent-From: *<public-sdw-comments@w3.org> >> <mailto:public-sdw-comments@w3.org> >> *Resent-Date: *Wednesday, 10 May 2017 at 8:26 pm >> >> Dear all >> >> I am some remark about the sosa example >> >> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/documentation_examples/sosa-core_examples.ttl >> >> >> In the ssn ontology it was clear what is a FeatureOfInterest >> (wind) and a Property of a FeatureOfInterest ( wind direction). >> This distinction is no so easy to understand at the first >> reading. That why the design patern SSO is so important. >> But I like very much this distinction. A temperature sensor may >> measure different think depending of its location (the soil, the >> outdoor air, the indoor air) >> >> About the sosa example of room temperature >> for me the FeatureOfInterest is a room (or buiding or indoor >> air), identified by one sample (a specific room 4830EH_UCSB) >> and the property is the temperature (room temperature ). >> In the example I think it is not so clear because I can not see >> where is defined the property (temperature) . >> >> the result of observation has no unit. >> sosa-core:hasValue "23.8"^^xsd:double; >> there exist different unit about temperature celsius or degree. >> Where can we find the unit of the temperature value? >> >> >> Best regards >> Catherine >> >> -- >> Catherine ROUSSEY >> Irstea Clermont Ferrand >> Campus des Cézeaux >> 9 avenue Blaise Pascal >> CS 200 85 >> 63178 Aubière >> tel:33 (0)4 73 44 06 88 <tel:04%2073%2044%2006%2088> >> "Imprefection si beauty, madness is genious and it's better to be absolutely ridiculous than aboslutely boring" Maryline Monroe > > -- > Catherine ROUSSEY > Irstea Clermont Ferrand > Campus des Cézeaux > 9 avenue Blaise Pascal > CS 200 85 > 63178 Aubière > tel:33 (0)4 73 44 06 88 <tel:04%2073%2044%2006%2088> > "Imprefection si beauty, madness is genious and it's better to be absolutely ridiculous than aboslutely boring" Maryline Monroe > -- Catherine ROUSSEY Irstea Clermont Ferrand Campus des Cézeaux 9 avenue Blaise Pascal CS 200 85 63178 Aubière tel: 33 (0)4 73 44 06 88 "Imprefection si beauty, madness is genious and it's better to be absolutely ridiculous than aboslutely boring" Maryline Monroe
Received on Monday, 15 May 2017 10:11:25 UTC