Re: ssn "not machine readable"

Hi Kerry,

    I am very happy to see these valuable responses. I would like to clearly distinguish two different aspects of the discussion: 1) human readable and elegant ontology design, which is a fair and understandable standpoint; 2) machine interpretable ontologies and linked data, which is about the ability of a device to effectively parse an ontology and extract all the concepts along with their relationships to grasp how to generate a meaningful knowledge without violating the structure of the designed ontology. As long as the relationships between properties and concepts are clear and can be directly extracted from an ontology, I see no problem of having stronger axioms. I have checked the working copy of the SSN ontology, and Krzysztof has indicated to the change in propertyChainAxiom restrictions that have been put on the ssn:observes, ssn:hasProperty, ssn: produces, I suppose. However, there is still no domain and range involved in the ontology, and as far as I know it is still part of owl-2 specifications (https://www.w3.org/TR/2009/WD-owl2-primer-20090421/#Domain_and_Range_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.
Krzysztof: The reason I kindly inquired to have domain and range features on properties is the same reason: to prevent people from providing ill-defined linked data. Regarding your suggestion: it is very difficult to find information about so-called "guarded restrictions".

because if we use rdfs:domain and rdfs:range then it will commonly not have the author’s  intended meaning (due to common misunderstanding).
Kerry: I haven’t really understood what Krzysztof and you meant above. Can you please explain to me how and why having a simply domain and range can cause problems to convey the author’s intended meaning?

Presumably there are some schema.org<http://schema.org/> tools that do implement some kind of interpretation of that domain-includes and range-includes intended behaviour? What is that intended behaviour- is there some operational semantics?  Anyone know?
Kerry: Here is an excerpt from shema.org<http://shema.org>:
<owl:objectproperty rdf:about="http://schema.org/about">
<rdfs:label xml:lang="en">about</rdfs:label>
<rdfs:comment xml:lang="en">The subject matter of the content.</rdfs:comment>
<rdfs:range>
<owl:class>
<owl:unionof rdf:parsetype="Collection">
<rdf:description rdf:about="http://schema.org/Thing">
</rdf:description></owl:unionof>
</owl:class>
</rdfs:range>
<rdfs:domain>
<owl:class>
<owl:unionof rdf:parsetype="Collection">
<rdf:description rdf:about="http://schema.org/CreativeWork">
</rdf:description></owl:unionof>
</owl:class>
</rdfs:domain>
</owl:objectproperty>



Although SKOS offer very simple ontology structure, it is semantically weak and lacks providing an explicit representation of knowledge with the properties of narrower and broader properties. Therefore, I wouldn’t be in favour of proposal involving SKOS or XML.

It seems that the schema.org<http://schema.org/> conceptualization is of additive domains and ranges:

“Relations are polymorphic in the sense that they have one or more domains and one or more ranges.”

Simon: I couldn’t completely understand the point that the authors made about "polymorphic relations” in the article that you have sent (http://queue.acm.org/detail.cfm?id=2857276). The core idea of the Semantic Web is based on the very idea that any property can be linked to any concept (unless there is a very high restriction on the property). Properties are separate entities from concepts. Therefore, although we encode properties and concepts together, they have got two different hierarchical and relational structure and can be linked to any other entity, so I couldn’t understand the point they wanted to make there. I will take another look to understand it better though.

Thanks for your replies!

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 19 May 2016, at 06:44, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:


I'm no expert on this - but my take would be to derive the "simplified views" automatically from the strongest model you can sustain agreement about.  Thus we might define an OWL-DL core, and derive RDFS and SKOS modules. We can then use Linked Data to support discovery of the various views of the model.  I'm happy to prototype an example infrastructure that does just this as part of the COBWEB project.

I think Kerry is right in pointing out that horizontal models will need to be very careful to integrate at the right level  I think this implies that we want to define a BP for ontology modularity that makes these different levels of the vertical extremely easy to understand in function and refer to in practice.

And by implication I think we will need an alignment module where we want to relate an external ontology to multiple levels - i.e. direct integration may not be safe and/or useful

rob

On Thu, 19 May 2016 at 13:50 Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>> wrote:
Thank you for that pointer, Simon.

I read this as an argument for local restrictions for domains and ranges (which are possible in OWL but not RDFS).  Both the need for “many unintuitive classes” and  “makes it much harder to reuse existing relations without significantly changing the class hierarchy” go away with local restrictions.  So I read this as “we really want to stick to rdfs but rdfs is not expressive enough so let’s make up something else our own way with no  semantics at all instead of using OWL “ (my paraphrase) . Or maybe there is some operationally-defined semantics I have not seen. Or maybe the ‘domain-includes’ and ‘range-includes’ can be translated to local restrictions somehow (but this is not obvious to me).

Anyway the takeaway message for me is that, even for our “lightweight” ontology modules we need either no domain-range constraints (and so keeping inside RDFS) or local domain/range constraints (implemented by restrictions) and therefore not keeping inside RDFS.


OTOH I am not convinced about the need for lightweight reasoning… why not enable sensible things to be done with our  “lightweight” applications that involve absolutely no reasoning at all--- and think harder about how to ensure smooth integration into a reasoning environment if required? Why should some simple sensing device that is just marking up measurements with a simple vocabulary be required to have any interest in reasoning at all? Or domain/range constraints that require reasoning for interpretation, for that matter (instead just documentation would do, would it not?)
Surely the reasoning comes in only when those measurements need to be integrated with other information about them (say the sensor accuracy, for example) in a bigger world?

So—I don’t think we should be thinking of the “SSN core” as “low reasoning/low language complexity”. Quite the reverse. The core should be the structure that holds the modules together with its reasoning strength,
and those application-dependent “horizontal” modules should be as  simple as possible  but (formally) aligned with the core. An IoT module would be one of these.



From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> [mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>]
Sent: Thursday, 19 May 2016 12:43 PM

To: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; s.kolozali@surrey.ac.uk<mailto:s.kolozali@surrey.ac.uk>
Cc: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ssn "not machine readable"

It seems that the schema.org<http://schema.org/> conceptualization is of additive domains and ranges:

“Relations are polymorphic in the sense that they have one or more domains and one or more ranges.”

“Many frame-based KR (knowledge representation) systems, including RDF Schema, OWL (Web Ontology Language), etc., have a single domain and range for each relation. This, unfortunately, leads to many unintuitive classes whose only role is to be the domain or range of some relation. This also makes it much harder to reuse existing relations without significantly changing the class hierarchy. The decision to allow multiple domains and ranges seems to have significantly ameliorated the problem. For example, though there are various types (Events, Reservations, Offers) in Schema.org<http://Schema.org> whose instance can take a startDate property, the polymorphism has allowed us to get away with not having a common supertype (such as Temporally Commencable Activity) in which to group these.”

http://queue.acm.org/detail.cfm?id=2857276


From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Thursday, 19 May 2016 12:33 PM
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; s.kolozali@surrey.ac.uk<mailto:s.kolozali@surrey.ac.uk>
Cc: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ssn "not machine readable"

The “more or less equivalent to” expression is of course a tautology, which formally says absolutely nothing at all. Which might be a very good thing. That is, to have no formal semantics around domain and range at all,
because if we use rdfs:domain and rdfs:range then it will commonly not have the author’s  intended meaning (due to common misunderstanding). I think this corresponds well to  Krysztof’s plan. But  the schema.org<http://schema.org/> style “Clayton’s semantics” (my description) might convey something of the intended behaviour without enforcing anything from an ontology perspective. Presumably there are some schema.org<http://schema.org/> tools that do implement some kind of interpretation of that domain-includes and range-includes intended behaviour? What is that intended behaviour- is there some operational semantics?  Anyone know?


--Kerry



From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> [mailto:Simon.Cox@csiro.au]
Sent: Thursday, 19 May 2016 9:35 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; s.kolozali@surrey.ac.uk<mailto:s.kolozali@surrey.ac.uk>
Cc: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ssn "not machine readable"


>  What does schema.org<http://schema.org/> do? I think it uses global domains and ranges.

In schema.org<http://schema.org/> the predicates are ‘domain-includes’ and ‘range-includes’.
Classes specified in the domain or range are not exhaustive, and more can be added later.
In OWL terms,

ex:prop1 schema:domainIncludes ex:Class1 .

is more or less equivalent to

ex:prop1 rdfs:domain [
owl:unionOf (
ex:Class1
owl:Thing
) ;
            ] ;
.

Simon

From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Thursday, 19 May 2016 2:47 AM
To: janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; s.kolozali@surrey.ac.uk<mailto:s.kolozali@surrey.ac.uk>
Cc: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ssn "not machine readable"

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<http://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<mailto:s.kolozali@surrey.ac.uk>
Cc: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; public-sdw-wg@w3.org<mailto: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:ObjectProperty rdf: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:ObjectProperty rdf: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:domain rdf:resource="&ssn;Sensor"/>
        <rdfs:range rdf:resource="&ssn;SensorInput"/>
        <rdfs:range rdf: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/


Semantic Web Journal: http://www.semantic-web-journal.net<http://www.semantic-web-journal.net/>