W3C home > Mailing lists > Public > public-sdw-wg@w3.org > May 2016

Re: ssn "not machine readable"

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Wed, 18 May 2016 09:59:28 -0700
To: Kerry Taylor <kerry.taylor@anu.edu.au>, "s.kolozali@surrey.ac.uk" <s.kolozali@surrey.ac.uk>
Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <573C9F70.9030601@ucsb.edu>
Hi Kerry,

Yes, super interesting and relevant point. The way I would propose to 
approach this is by the (vertical) layering of modules. Domain and range 
restrictions will then be used (together with property chains and so 
forth) for the deeper axiomatization; see also the wiki. For the SSN 
core, I would not use global restrictions for the reasons we discussed. 
In short, horizontal modules add themes (e.g., deployment, sampling 
features, and so forth), while vertical modules add ontological 
commitments (essentially a deeper axiomatization).

> Or do such applications really require such constraints and so we  put 
> them in the core and are thereby forced into  a position of global 
> constraints everywhere?

This is exactly the issue, they are not constrains but inferential 
patterns and thus even more dangerous for the typical Linked Datasets we 
see that take classes and relations from different ontologies and mix 
them together as they see fit/need.


Cheers,
Jano

On 05/18/2016 09:47 AM, Kerry Taylor wrote:
>
> This raises an interesting potential contradiction I have observed in 
> the current SSN-redesign  discussions.
>
> “Thus, the core SSN should ideally be in RDFS or OWL-EL. “
>
> The thing is, RDFS can **only** express **global**  domain/range 
> constraints or else none at all. OWL-EL  can do global and goes some 
> way towards local but cannot do local range constraints in a 
> meaningful way (i.e cannot do universally quantified restrictions).
>
> So… let’s say we do the core in RDFS (and let’s assume by this we mean 
> the intersection of RDFS and OWL-DL so that we do not get into trouble 
> when we build on it further). Then  does this mean we are aiming to 
> make life easier for the low-power –low-tooling –eye-balling 
> applications and also have *no* constraints on object properties? Is 
> that consistent with the intended applications?  This is fine by me 
> –as the extension to locally-defined constraints with more language 
> expressivity will work – but are we actually doing a disservice to the 
> low-power –low-tooling –eye-balling applications by this? Or do such 
> applications really require such constraints and so we  put them in 
> the core and are thereby forced into  a position of global constraints 
> everywhere?
>
> What does schema.org do? I think it uses global domains and ranges.
>
> Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Wednesday, 18 May 2016 12:10 PM
> *To:* s.kolozali@surrey.ac.uk
> *Cc:* Kerry Taylor <kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org
> *Subject:* Re: ssn "not machine readable"
>
> Hi,
>
>
>     I am sure you have very good reasons to use global restrictions.
>
>
> I am not in favor of global domain and range restrictions because 90% 
> of all people get them wrong and due to their inferential semantics 
> this leads to unintended consequences. Most people believe that a 
> global domain or range restriction on a certain property adds 
> something to the definition of said property why this is absolutely 
> not the case. Guarded restrictions, however, seem very helpful.
>
>
>     The core problem with ontologies is once they are developed,
>     people tend to look at the ontology structure with their eyes and
>     use their own codes instead the real ontology structure to
>     annotate their data.
>
>
> Ontology is set out to minimize exactly this, namely that people look 
> at domain vocabulary through their own eyes. This is also why I 
> proposed a stronger axiomatization for some of the modules that makes 
> full use of OWL2 (see e.g., the proposed property chain on the wiki). 
> At the same time most scenarios will not make use of these features. 
> Thus, the core SSN should ideally be in RDFS or OWL-EL.  Of course, 
> ontologies will not and cannot fix meaning but they can restrict the 
> interpretation of terms towards their intended interpretation and 
> thereby substantially improve semantic interoperability.
>
> Best,
> Krzysztof
>
>
> On 05/17/2016 04:41 PM, s.kolozali@surrey.ac.uk 
> <mailto:s.kolozali@surrey.ac.uk> wrote:
>
>     Hi Krzysztof,
>
>     I am sure you have very good reasons to use global restrictions.
>     If you could send me some links, I will be happy to read the good
>     things about global restrictions and how it could be parsed using
>     (python) libraries, such as rdflib. The title of e-mail is a
>     rather strong argument and doesn’t completely reflect what I
>     meant. The core problem with ontologies is once they are
>     developed, people tend to look at the ontology structure with
>     their eyes and use their own codes instead the real ontology
>     structure to annotate their data. Due to human error, we end up
>     having a big messy ill-defined annotated linked data. I have
>     stated this issue with SSN validator
>     (http://iot3.ee.surrey.ac.uk/SSNValidation/) as well as SAOPY
>     library
>     (http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/saopy.html),
>     where a user can either validate its data or prevent having syntax
>     errors during the annotation process. However, during my
>     investigation and development, I faced with lots of difficulty to
>     parse and extract the structure of the SSN ontology including
>     object properties and their links to concepts.
>
>     I hope this e-mail clarifies what are the possible problems if the
>     SSN ontology is being mapped (e.g. annotation libraries) or
>     guarded (e.g. validation tools) by machines.
>
>     Cheers,
>
>     Sefki Kolozali
>     Research Fellow
>     Institute for Communication Systems (ICS), home of the 5G
>     Innovation Centre
>     University of Surrey
>     Guildford, Surrey, GU2 7XH, United Kingdom
>     Tel: +44 (0)1483 689490
>
>     E-mail: s.kolozali@s <mailto:s.kolozali@qmul.ac.uk>urrey.ac.uk
>     <http://urrey.ac.uk>
>
>     http://www.surrey.ac.uk/ics/ <http://www.surrey.ac.uk/ccsr/>
>
>         On 17 May 2016, at 23:53, Krzysztof Janowicz
>         <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> wrote:
>
>         Hi,
>
>         I do not understand how the lack of global domain and range
>         restrictions make SSN not machine readable. Also, there are
>         many good reasons not to include global range and domain
>         restrictions (and for adding guarded restrictions instead).
>
>         Best,
>         Krzysztof
>
>         On 05/17/2016 03:39 PM, s.kolozali@surrey.ac.uk
>         <mailto:s.kolozali@surrey.ac.uk> wrote:
>
>             Hi Kerry,
>
>                 This was a problem that I had faced when I had to
>             parse and map the SSN ontology (along with a many other
>             ontologies) into SAOPY library that I have developed
>             (http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/saopy.html).
>             What I observed back then was the SSN ontology was missing
>             all the domain and range restrictions for object
>             properties. I had stated this problem to you in an e-mail
>             and you had told me that it was simply due to the fact
>             that "SSN ontology is using global restrictions instead of
>             local restrictions". To solve this issue, I had to add all
>             the domain and range restrictions of object properties one
>             by one by going through and reading the comments in the
>             SSN ontology. I am happy to send my local SSN copy to you
>             "if you are interested in", which can save you a lot of time.
>
>             An excerpt the SSN ontology:
>
>             <!-- http://purl.oclc.org/NET/ssnx/ssn#detects -->
>
>             <owl:ObjectPropertyrdf:about="&ssn;detects">
>
>                   <rdfs:label>detects</rdfs:label>
>
>             <rdfs:seeAlso>http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Skeleton#Skeleton</rdfs:seeAlso>
>
>             <rdfs:comment>A relation from a sensor to the Stimulus
>             that the sensor can detect.
>
>             The Stimulus itself will be serving as a proxy for (see
>             isProxyOf) some observable property.</rdfs:comment>
>
>             <rdfs:isDefinedBy>http://purl.oclc.org/NET/ssnx/ssn</rdfs:isDefinedBy>
>
>               </owl:ObjectProperty>
>
>             An excerpt from my local copy of the SSN ontology:
>
>             <!-- http://purl.oclc.org/NET/ssnx/ssn#detects -->
>
>             <owl:ObjectPropertyrdf:about="&ssn;detects">
>
>                   <rdfs:label>detects</rdfs:label>
>
>             <rdfs:seeAlso>http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Skeleton#Skeleton</rdfs:seeAlso>
>
>             <rdfs:comment>A relation from a sensor to the Stimulus
>             that the sensor can detect.
>
>             The Stimulus itself will be serving as a proxy for (see
>             isProxyOf) some observable property.</rdfs:comment>
>
>             <rdfs:isDefinedBy>http://purl.oclc.org/NET/ssnx/ssn</rdfs:isDefinedBy>
>
>             <rdfs:domainrdf:resource="&ssn;Sensor"/>
>
>             <rdfs:rangerdf:resource="&ssn;SensorInput"/>
>
>             <rdfs:rangerdf:resource="&ssn;Stimulus"/>
>
>               </owl:ObjectProperty>
>
>             Although it sounds like a fairly simple and straight
>             forward issue, it causes lots of issues when one attempts
>             to parse and use the SSN ontology in an automated way. The
>             text written in the form of rdfs:comments are helpful for
>             people but local restrictions are more helpful for machine
>             interpretation.
>
>             Cheers,
>
>             Sefki Kolozali
>             Research Fellow
>             Institute for Communication Systems (ICS), home of the 5G
>             Innovation Centre
>             University of Surrey
>             Guildford, Surrey, GU2 7XH, United Kingdom
>             Tel: +44 (0)1483 689490
>
>             E-mail: s.kolozali@s
>             <mailto:s.kolozali@qmul.ac.uk>urrey.ac.uk
>             <http://urrey.ac.uk/>
>
>             http://www.surrey.ac.uk/ics/ <http://www.surrey.ac.uk/ccsr/>
>
>                 On 17 May 2016, at 23:11, Kerry Taylor
>                 <kerry.taylor@anu.edu.au
>                 <mailto:kerry.taylor@anu.edu.au>> wrote:
>
>                 Hi Sefki,
>
>                 Can you please explain further what you meant about
>                 failure of  “machine readability” with ssn as raised
>                 in the meeting today? Before that, can you do your
>                 test with this ssn herehttps://www.w3.org/ns/ssn/ as
>                 it seems likely to me that dul could have been the
>                 source of trouble and this is the new  (FPWD) version
>                 with dul removed.
>
>                 Kerry
>
>
>
>
>         -- 
>
>         Krzysztof Janowicz
>
>         Geography Department, University of California, Santa Barbara
>
>         4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
>         Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
>
>         Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
>
>         Semantic Web Journal:http://www.semantic-web-journal.net
>         <http://www.semantic-web-journal.net/>
>
>
>
>
> -- 
> Krzysztof Janowicz
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
> Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
> Semantic Web Journal:http://www.semantic-web-journal.net


-- 
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
Received on Wednesday, 18 May 2016 17:00:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:21 UTC