Re: Using rdf:Property class for properties whose URI contains string "time"

> I see no significant hurdle in stating
       :Obs293 sosa:resultTime [time:inXSDDateTime "2002-10-10T12:00:00"]
   
Actually :inXSDDateTime is deprecated in favour of  :inXSDDateTimeStamp (which makes the timezone mandatory). 

Simon J D Cox
Research Scientist
Land and Water
CSIRO
E simon.cox@csiro.au T +61 3 9545 2365 M +61 403 302 672
   Physical: Reception Central, Bayview Avenue, Clayton, Vic 3168
   Deliveries: Gate 3, Normanby Road, Clayton, Vic 3168
   Postal: Private Bag 10, Clayton South, Vic 3169
people.csiro.au/C/S/Simon-Cox
orcid.org/0000-0002-3884-3420
researchgate.net/profile/Simon_Cox3

________________________________________
From: Armin Haller <armin.haller@anu.edu.au>
Sent: Saturday, 1 April 2017 7:00 PM
To: Raúl García Castro; janowicz@ucsb.edu; Maxime Lefrançois; SDW WG Public List
Subject: Re: Using rdf:Property class for properties whose URI contains string   "time"

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 Monday, 3 April 2017 09:47:44 UTC