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

Re: rdfs:class versus owl:class in SOSA-Core

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Thu, 10 Nov 2016 08:46:40 -0800
To: Rob Atkinson <rob@metalinkage.com.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "antoine.zimmermann@emse.fr" <antoine.zimmermann@emse.fr>, Armin Haller <armin.haller@anu.edu.au>, "jano@geog.ucsb.edu" <jano@geog.ucsb.edu>, "jlieberman@tumblingwalls.com" <jlieberman@tumblingwalls.com>
Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <d99040f9-5db2-f67d-41fa-ada30a76d63f@ucsb.edu>
Very true Rob. As you said, there is no simple solution here but there 
is still something like the Pareto principle to guide us. I believe that 
we can get something like the current SOSA-core to be useful to 80% of 
the users while only having to deal with 20% of the modeling and 
engineering complexity (that would be required to address those 
remaining 20% of users/use cases). Lets also not forget that SOSA is 
backed up by SSN and it is SSN that is supposed to do all the heavy lifting.

Jano

On 11/09/2016 10:11 PM, Rob Atkinson wrote:
> I think much of the challenge is one of perspective.  I've seen the 
> concept of Spatial Data Infrastructures go down the route of "keeping 
> things simple" - but from the perspective of software developers and 
> data publishers, not users - and we end up not having any agreed means 
> to find what content is behind what services or what services are 
> available for specific content,  and having lots of metadata that only 
> makes sense to the particular portal design it was aimed at, and only 
> for the same sorts of collection sizes - with semantics stuffed into 
> naming conventions.  Making things simple for one stakeholder usually 
> means making it harder for another - so we need to decide who is going 
> to pay.
>
> Rob
>
>
>
>
>
> On Thu, 10 Nov 2016 at 15:34 Krzysztof Janowicz <janowicz@ucsb.edu 
> <mailto:janowicz@ucsb.edu>> wrote:
>
>     Hi Rob,
>
>     I think this goes back to the issue I raised here:
>     https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0065.html
>     . Lets discuss our modeling choices first and then decide about
>     representational choices. The solution we have now is just fine
>     and so far nobody was able to bring up any other argument that
>     would point to any problem (assuming we add both owl:class and
>     rdfs:class as extra level of safety).
>
>     SOSA -core is supposed to be a conceptually simple, not based on a
>     'simple' representation language.
>
>     Best,
>     Krzysztof
>
>
>
>
>     On 11/09/2016 08:03 PM, Rob Atkinson wrote:
>>
>>     my opinion is that I'm happy to have owl constructs as long as
>>     the rdfs that would be entailed by OWL reasoning, but not RDFS
>>     reasoning, is materialised, and hence the user is not expected to
>>     use an OWL reasoner.  There seems to be a consensus (or at least
>>     no counter-arguments to this specific policy ACAICT)
>>
>>     I am therefore agnostic as whether all OWL is in a extension
>>     model which supports OWL-DL (?) reasoning - and is part of the
>>     normative semantics. I guess the question is whether there is a
>>     need for a subset of OWL semantics which imposes a low burden an
>>     OWL reasoner (a simple core). Others with more experience need to
>>     weigh in and document the subset and we can then vote if we are
>>     happy to include it in the core.
>>
>>     Kerry has made the useful point that expectations are raised when
>>     a user finds OWL constructs. Perhaps that can be managed by clear
>>     enough documentation that all RDFS semantics implied by such OWL
>>     is materialised.
>>
>>     There is a possible lower level of commitment - in that in the
>>     core terms are just defined using SKOS, without any form of class
>>     model - but I think we all feel that the world is used to simple
>>     RDFS models and we could use that as a moderately expressive
>>     baseline.
>>
>>     So I see the choice is between:
>>     1) something like SKOS Concepts to "reserve" resource names and
>>     attach documentation
>>     2) RDFS only + OWL module that imports it
>>     3) RDFS inc. "cheap to process OWL"  + OWL-DL module that imports it
>>     4) OWL-DL only
>>     5) OWL-DL with entailed RDFS
>>     6) something I've missed :-)
>>
>>     Note also that if we publish two modules:
>>     sosa.OWL-DL and sosa.RDFS,   and the RDFS is generated from the
>>     OWL, then the fact that RDFS does not have an import makes option
>>     that nearly equivalent to option #2 (the OWL does not need to
>>     import the RDFS, although it could do so)
>>
>>     I propose we get this list of options nailed down so we can
>>     identify which flavour we are talking about in future, and then
>>     if we cant get a consensus quickly document pros and cons, and
>>     specifically anything we might break for users. (As an example I
>>     personally think #4) (OWL-DL only) breaks it for RDFS-only based
>>     reasoning)
>>
>>     Rob Atkinson
>>
>>     On Thu, 10 Nov 2016 at 12:55 Kerry Taylor
>>     <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> wrote:
>>
>>         And therein lies another dragon -- or   an elephant?
>>
>>         In ssn  a ssn:MeasurementCapability   is not defined with
>>         domain/range. Instead it is defined via a local allvaluesfrom
>>         restriction on Sensor.  So certainly this following  holds:
>>
>>         >   ?x :hasMeasurementCapability  ?y .
>>         >  I cannot conclude that ?y is a :MeasurementCapability
>>
>>         One of the many promises of the "simple"  core is that it is
>>         simpler than full  ssn in the sense that   it makes weaker 
>>         ontological commitments (see the notion of "vertical
>>         modularisation" in the FPWD).
>>
>>         So this automatically forbids rdfs:domain and rdfs:range in
>>         this case and similarly most others. Or otherwise it forbids
>>         one of many other broadly agreed goals.
>>
>>
>>         Having said that, which remains true in general,
>>         hasMeasurementCapability  in particular is not currently 
>>         proposed to exist at all in sosa-core
>>         https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl. So
>>         there may be no issue there.
>>
>>         However the same principle should indeed apply to
>>         observedProperty, for example, which does occur in the core.
>>
>>         -----Original Message-----
>>         From: Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>
>>         [mailto:Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>]
>>         Sent: Thursday, 10 November 2016 12:19 PM
>>         To: antoine.zimmermann@emse.fr
>>         <mailto:antoine.zimmermann@emse.fr>; janowicz@ucsb.edu
>>         <mailto:janowicz@ucsb.edu>; Armin Haller
>>         <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>>;
>>         jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>;
>>         jlieberman@tumblingwalls.com
>>         <mailto:jlieberman@tumblingwalls.com>; Kerry Taylor
>>         <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>
>>         Cc: public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
>>         Subject: RE: rdfs:class versus owl:class in SOSA-Core
>>
>>         > something really wrong in the name of the property!  Or,
>>         alternatively there ought to be a rdfs:range axiom.
>>
>>         An owl:ObjectProperty without a rdfs:range axiom is usually
>>         be missing the most significant part of the semantics. I
>>         generally add these as a matter of course (not so for
>>         rdfs:domain). As Jano pointed out, semantics shouldn't depend
>>         on labels.
>>
>>         Simon
>>
>>         -----Original Message-----
>>         From: Antoine Zimmermann [mailto:antoine.zimmermann@emse.fr
>>         <mailto:antoine.zimmermann@emse.fr>]
>>         Sent: Thursday, 10 November 2016 10:06 AM
>>         To: janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Armin
>>         Haller <armin.haller@anu.edu.au
>>         <mailto:armin.haller@anu.edu.au>>; Krzysztof Janowicz
>>         <jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>>; Joshua
>>         Lieberman <jlieberman@tumblingwalls.com
>>         <mailto:jlieberman@tumblingwalls.com>>; Cox, Simon (L&W,
>>         Clayton) <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>;
>>         Kerry Taylor <kerry.taylor@anu.edu.au
>>         <mailto:kerry.taylor@anu.edu.au>>
>>         Cc: SDW WG Public List <public-sdw-wg@w3.org
>>         <mailto:public-sdw-wg@w3.org>>
>>         Subject: Re: rdfs:class versus owl:class in SOSA-Core
>>
>>         On 09/11/2016 23:46, Krzysztof Janowicz wrote:
>>         >>
>>
>>         [...]
>>
>>         >> -rdfs:domain and rdfs:range
>>         >>
>>         >> Please use these whenever relevant. [...]. You can't go
>>         wrong with them.
>>         >
>>         > This is the only part of your email where I would strongly
>>         disagree
>>         > (well, depending on what you mean by 'whenever relevant'
>>         :-)) for the
>>         > reasons we discussed here before and that others made when
>>         developing
>>         > other ontologies. This is not to say that using them is
>>         'wrong' in
>>         > some sense but that they have to be handled with great care.
>>
>>         On this, I know what you mean. I've read the arguments that
>>         were written at some point in the SSN draft. I know that it
>>         is wise to avoid systematic domains and ranges that could be
>>         too restrictive.
>>
>>         But I think that this went too far with things like:
>>
>>         :hasMeasurementCapability  a  owl:ObjectProperty .
>>         :MeasurementCapability  a  owl:Class .
>>
>>         and no range for :hasMeasurementCapability. If, whenever I find:
>>
>>           ?x :hasMeasurementCapability  ?y .
>>
>>           I cannot conclude that ?y is a :MeasurementCapability, then
>>         there is something really wrong in the name of the property! 
>>         Or, alternatively there ought to be a rdfs:range axiom.
>>
>>
>>         --AZ
>>
>>
>>
>>         >
>>         > Best,
>>         > Krzysztof
>>         >
>>         >
>>         >
>>         > On 11/09/2016 01:15 PM, Antoine Zimmermann wrote:
>>         >> On 09/11/2016 00:20, Armin Haller wrote:
>>         >>> Hi Krzysztof,
>>         >>>
>>         >>> Thanks for your detailed explanations below!
>>         >>>
>>         >>> Just to clarify, the intention in the meeting to go
>>         through a list
>>         >>> of what constructs should be in SOSA (as thankfully
>>         proposed by
>>         >>> Josh) was to be incremental. I was planning to
>>         incrementally go
>>         >>> through the list of constructs that are either already in our
>>         >>> current SOSA proposal or could be imagined to be in it
>>         and vote on
>>         >>> them. Some, of course have implications, if we decide on
>>         >>> owl:inverseOf in our next meeting, we will not be in RDFS
>>         entailment.
>>         >>
>>         >> I was not at the meeting, so I may have missed something,
>>         but what is
>>         >> the rationale for forbidding certain constructs?  If there
>>         is an
>>         >> owl:inverseOf in the ontology, the RDFS reasoners won't
>>         care. Nobody
>>         >> who's not using/interested in owl:inverseOf will care.
>>         >>
>>         >> However, in the case of owl:inverseOf, I don't think it is
>>         a question
>>         >> of whether we want to use the construct or not. It is a
>>         question of
>>         >> deciding whether we allow ourselves to define both a
>>         property and its
>>         >> inverse. If we have properties like ex:hasChild and
>>         ex:hasParent, it
>>         >> would be silly not to make explicit the inverse
>>         relationship. If the
>>         >> decision is about not having both a property and its
>>         inverse, then
>>         >> the need to use or not owl:inverseOf is only an inevitable
>>         >> consequence of the other decision.
>>         >>
>>         >>
>>         >>> If we are already in OWL, then of course it would make
>>         sense to use
>>         >>> owl:Class, although we do not have to. Therefore, again a
>>         vote on
>>         >>> owl:Class thereafter.
>>         >>
>>         >> I don't see a reason not to. Not having owl:Class
>>         declaration has
>>         >> noticeable consequences. For instance, it always troubles
>>         me that
>>         >> Protégé cannot display the Dublin Core properties and
>>         classes. It
>>         >> also troubles me that the DC terms cannot be imported with
>>         standard
>>         >> owl:imports, because of the lack of owl class, owl properties
>>         >> declarations.
>>         >>
>>         >>
>>         >>> I can think of the following list to vote on in our next
>>         meeting,
>>         >>> incrementally. And we stopped at owl:inverseOf this
>>         meeting I just
>>         >>> saw in the minutes.
>>         >>>
>>         >>> -rdfs:class
>>         >>
>>         >> see above and related emails.
>>         >>>
>>         >>> -owl:inverseOf
>>         >>
>>         >> see above.
>>         >>>
>>         >>> -owl:AnnotationProperty
>>         >>>
>>         >>> -           owl:ObjectProperty
>>         >>
>>         >> owl:AnnotationProperty, owl:ObjectProperty and
>>         owl:DatatypeProperty,
>>         >> like owl:Class, do not add expressiveness to the language.
>>         However,
>>         >> they help OWL tools figuring out what the terms are.
>>         >>
>>         >> FWIW, in OWL 2 RDF-based semantics, owl:ObjectProperty is
>>         equivalent
>>         >> to rdf:Property. owl:AnnotationProperty and
>>         owl:DatatypeProperty are
>>         >> both subClassOf rdf:Property.
>>         >>
>>         >>>
>>         >>> -owl:Class
>>         >>
>>         >> see above.
>>         >>
>>         >>>
>>         >>> -rdfs:domain and rdfs:range
>>         >>
>>         >> Please use these whenever relevant. When used with an
>>         atomic class,
>>         >> they are fully supported by RDFS, OWL 2 EL, OWL 2 QL, OWL
>>         2 RL, OWL 2
>>         >> DL, OWL 2 Full, ter Horst semantics, RDFS++. You can't go
>>         wrong with
>>         >> them.
>>         >>
>>         >>>
>>         >>> -rdfs:subClassOf
>>         >>
>>         >> Come on! Do we need to vote on this one?
>>         >>
>>         >>>
>>         >>> -           owl:Restriction
>>         >>
>>         >> There are many forms of restrictions, each one should be
>>         considered
>>         >> individually. I don't see much reason to forbid ourselves
>>         to use any
>>         >> of them because anyone can just ignore those they don't like.
>>         >> However, they should be used sensibly because we should
>>         not prevent
>>         >> use cases that we have not foreseen. I'd prefer an
>>         ontology that has
>>         >> very little restrictions with precise documentation to prevent
>>         >> misusing the terms, rather than an overly restrictive one.
>>         Look at
>>         >> schema.org <http://schema.org>: painfully non-restrictive,
>>         delightfully useful.
>>         >>
>>         >>
>>         >> --AZ
>>         >>
>>         >>>
>>         >>> Please do think about these and if you think they should
>>         or should
>>         >>> not be in the core or if there is anything else we
>>         desperately would need.
>>         >>>
>>         >>> Kind regards,
>>         >>> Armin
>>         >>>
>>         >>> *From: *Krzysztof Janowicz <jano@geog.ucsb.edu
>>         <mailto:jano@geog.ucsb.edu>>
>>         >>> *Date: *Wednesday, 9 November 2016 at 10:01 am
>>         >>> *To: *Joshua Lieberman <jlieberman@tumblingwalls.com
>>         <mailto:jlieberman@tumblingwalls.com>>, Simon Cox
>>         >>> <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>, Kerry
>>         Taylor <kerry.taylor@anu.edu.au
>>         <mailto:kerry.taylor@anu.edu.au>>, Armin
>>         >>> Haller <armin.haller@anu.edu.au
>>         <mailto:armin.haller@anu.edu.au>>
>>         >>> *Cc: *SDW WG Public List <public-sdw-wg@w3.org
>>         <mailto:public-sdw-wg@w3.org>>
>>         >>> *Subject: *rdfs:class versus owl:class in SOSA-Core
>>         >>>
>>         >>> Hi,
>>         >>>
>>         >>> Sorry for being so picky about this during our meeting
>>         but I do not
>>         >>> want us to take decisions that have consequences that we
>>         can not yet foresee.
>>         >>>
>>         >>> To the best of my knowledge (and please correct me if I
>>         am wrong):
>>         >>>
>>         >>> Under the semantics of OWL1, rdfs:class and owl:class are
>>         only
>>         >>> equivalent for OWL-Full. For OWL-DL (and OWL-Lite)
>>         owl:class is a
>>         >>> subclass of rdfs:class.
>>         >>>
>>         >>> This means that every valid document in OWL will be a
>>         valid document
>>         >>> in RDFS, however *not* every rdfs:class is an owl:class.
>>         I do not
>>         >>> want us to end up in OWL-Full because of this.
>>         >>>
>>         >>> For OWL2, I found this: 'owl:Class rdfs:subClassOf
>>         rdfs:Class . "
>>         >>> (https://www.w3.org/TR/owl2-rdf-based-semantics/). Things
>>         may be
>>         >>> more complicated here due to OWL2 punning and they may
>>         well turn out
>>         >>> to be equivalent, I will check this later.
>>         >>>
>>         >>> If we decide to restrict ourself to only using RDFS for
>>         SOSA-core,
>>         >>> and I am not in favor of this, then we may have to go
>>         with rdfs:class.
>>         >>> However, we have not yet taken this decision and have
>>         also not
>>         >>> discussed which axioms and language to use for SSN. As
>>         Sosa-core and
>>         >>> SSN will be aligned, this may have more consequences that
>>         we should
>>         >>> consider. It also seems like many of us are in favor of using
>>         >>> inverseOf, so we would be using OWL (and its formal
>>         semantics)
>>         >>> anyway. Note that this does not do any harm to an RDFS-only
>>         >>> tool/user as for those the inverseOf axiom will simply
>>         have no
>>         >>> formal semantics. Still all other triples that use both
>>         relations will still be just fine.
>>         >>>
>>         >>> Given the subclasssing, I do not see any problems using
>>         owl:class,
>>         >>> but we may accidentally end up in OWL-full or with being
>>         >>> incompatible to the standards if we opt for rdfs:class.
>>         Again, I am happy to be corrected.
>>         >>> At least, I do not see harm in simply using owl:class.
>>         >>>
>>         >>> Finally, and from very pragmatic point of view:
>>         ontologies that are
>>         >>> under very heavy use such as the DBpedia ontology simply use
>>         >>> owl:class and I have not yet seen any issues or
>>         complaints about that. See, for
>>         >>> example, http://dbpedia.org/ontology/City "dbo:City   
>>         rdf:type
>>         >>> owl:Class ." The same is true for the goodrelations
>>         ontology and so
>>         >>> forth (but I admit that this is due to the more complex
>>         >>> axiomatization they use).
>>         >>>
>>         >>> I hope this will start a productive discussion.
>>         >>>
>>         >>> Thanks for reading,
>>         >>>
>>         >>> Krzysztof
>>         >>>
>>         >>
>>         >
>>         >
>>
>>
>>
>
>
>     -- 
>     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 Thursday, 10 November 2016 16:47:17 UTC

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