- From: Armin Haller <armin.haller@anu.edu.au>
- Date: Sat, 1 Apr 2017 08:00:17 +0000
- To: Raúl García Castro <rgarcia@fi.upm.es>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, Maxime Lefrançois <maxime.lefrancois@emse.fr>, SDW WG Public List <public-sdw-wg@w3.org>
I tend to agree with Raúl. If one of them is already an object property, it does not really make the use of the SOSA core more difficult if we also make sosa:resultTime an object property. That also solves the problem with the sub-property alignment of ssn:observationResultTime. On 29/3/17, 1:57 pm, "Raúl García Castro" <rgarcia@fi.upm.es> wrote: Hi, Yes, my proposal was to reuse the sosa properties in ssn. However, I still see the need for consistently reusing the time ontology (also standardised in this same group) in all the temporal properties and declaring all of them as object properties. I see no significant hurdle in stating :Obs293 sosa:resultTime [time:inXSDDateTime "2002-10-10T12:00:00"] instead of :Obs293 sosa:resultTime "2002-10-10T12:00:00" And allows practitioners (or people reusing their data) to exploit the representational capabilities of the time ontology and further describe the time instant (e.g., stating that it is inside a time interval or defining the instant with a greater granularity with the DateTimeDescription class). In summary, when we take a decision on this, I'd like to see an option that goes along this line. Kind regards, El 29/3/17 a las 0:23, Krzysztof Janowicz escribió: > Hi, > > Yes, but as I tried to describe on the wiki page[1], this is for good > reasons and we discussed them a few times several months ago. > PhenomenonTime needs to be able to deal with more complex inputs. > > The problem that I was trying to explain was that the currently proposed > alignment axiom 'ssn:observationResultTime rdfs:subPropertyOf > sosa:resultTime' is not in OWL2 DL as one is a DataTypeProperty and the > other one is an ObjectTypeProperty. > > The second case 'ssn:observationSamplingTime owl:equivalentProperty > sosa:phenomenonTime. ' is simple because both are object type properties > and equivalent anyway. > > I liked Raul's proposal (if I understood it correctly) to deprecate > observationResultTime and observationSamplingTime and then reuse the > sosa properties resultTime and phenomenonTime in ssn without the need to > do anything in addition. > > Best, > Jano > > [1] https://www.w3.org/2015/spatial/wiki/Time_in_SOSA_and_SSN > On 03/28/2017 03:14 PM, Maxime Lefrançois wrote: >> Dear all, >> >> If I took the minutes correctly today, some of the properties whose >> URI contains string "time" are object properties and other are >> datatype properties, so that's not really consistent. >> >> It has been proposed to declare them as instances of rdf:Property >> instead of having to choose between ObjectProperty and DatatypeProperty. >> >> This could be interesting, these are the side effects I can think of now: >> - we would need to assert these properties are instances of >> AnnotationProperty, else the ontology would not be OWL DL; >> - no ontology that extends SSN can assert it's also a ObjectProperty >> or a DatatypeProperty; >> - one cannot make this property be involved in a OWL logical axiom in >> any possible way, apart from rdfs:domain, rdfs:range, and >> rdfs:subPropertyOf; >> - still, people can create non-OWL rules ()e.g., SPARQL Construct or >> SPIN rules) that can generate new knowledge out of some pattern that >> involves this property. >> >> Best, >> Maxime > > > -- > Krzysztof Janowicz > > Geography Department, University of California, Santa Barbara > 4830 Ellison Hall, Santa Barbara, CA 93106-4060 > > Email: jano@geog.ucsb.edu > Webpage: http://geog.ucsb.edu/~jano/ > Semantic Web Journal: http://www.semantic-web-journal.net > -- Dr. Raúl García Castro http://www.garcia-castro.com/ Ontology Engineering Group Departamento de Inteligencia Artificial Escuela Técnica Superior de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19
Received on Saturday, 1 April 2017 08:01:00 UTC