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

Yes, sosa-core, sosa, core, ssn-core, that is all the same for me as we
have not agreed on one official name.

On Fri, Nov 11, 2016 at 3:34 PM, Kerry Taylor <kerry.taylor@anu.edu.au>
wrote:

> To clarify my concern, I quote a longer extract:
>
> > We use (as others suggested) local/guarded restrictions on the
> class-level instead. We can discuss the pros and cons of that but it does
> not matter for SOSA-core anyway as this would not be part of the core. For
> the core
>
> In this expression here there  seems to be a deliberate distinction
> between "SOSA-core" and "core" .   Maybe I am just  misunderstanding what
> the second  "this" refers to. So we all agree there is only one core.
>
> When I refer to SOSA-core, and also simply   "core" , I refer to
> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl
>
> I hope that we are all on the same page!
> -Kerry
> -----Original Message-----
> From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> Sent: Friday, 11 November 2016 3:52 AM
> To: Kerry Taylor <kerry.taylor@anu.edu.au>; Antoine Zimmermann <
> antoine.zimmermann@emse.fr>; Armin Haller <armin.haller@anu.edu.au>;
> Krzysztof Janowicz <jano@geog.ucsb.edu>; Joshua Lieberman <
> jlieberman@tumblingwalls.com>; Simon Cox <Simon.Cox@csiro.au>
> Cc: SDW WG Public List <public-sdw-wg@w3.org>
> Subject: Re: rdfs:class versus owl:class in SOSA-Core
>
> Hi Kerry,
>
> > " SOSA-core anyway as this would not be part of the core"
> > This is a typo, right?
> >
> > It makes zero sense to me. How many cores can there be, What are they?
>  I am very worried that we are all on very different pages here.
>
> Not sure what you mean. I wrote that concepts such as
> 'MeasurementCapability' are not in SOSA-core and I believe this is accurate.
>
> > How many cores can there be
>
> I am aware of one core.
>
> > I am very worried that we are all on very different pages here.
>
> Hmm, I feel like we are all converging rapidly given that we talk about
> tiny details like rdfs:class versus olw:class or whether to declare inverse
> properties.
>
>
> Best,
> Krzysztof
>
>
> On 11/09/2016 10:33 PM, Kerry Taylor wrote:
> > " SOSA-core anyway as this would not be part of the core"
> > This is a typo, right?
> >
> > It makes zero sense to me. How many cores can there be, What are they?
>  I am very worried that we are all on very different pages here.
> > --Kerry
> > -----Original Message-----
> > From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> > Sent: Thursday, 10 November 2016 3:29 PM
> > To: Antoine Zimmermann <antoine.zimmermann@emse.fr>; Armin Haller
> > <armin.haller@anu.edu.au>; Krzysztof Janowicz <jano@geog.ucsb.edu>;
> > Joshua Lieberman <jlieberman@tumblingwalls.com>; Simon Cox
> > <Simon.Cox@csiro.au>; Kerry Taylor <kerry.taylor@anu.edu.au>
> > Cc: SDW WG Public List <public-sdw-wg@w3.org>
> > Subject: Re: rdfs:class versus owl:class in SOSA-Core
> >
> >> 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.
> > I think is great that there is wide agreement about this issue.
> >> 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.
> > This is were things become tricky and where we also have to consider
> that all this work is based on finding a consensus. Essentially, this is a
> modeling choice so there is no right or wrong here anyway. The question is
> what kind of ontological commitments you would like to introduce, how they
> are going to impact future use and (accidental) misuse, and what cost you
> are willing to pay for extra inferencing noting that domain and range do
> not restrict the interpretation of neither the property nor the class.
> >
> > We use (as others suggested) local/guarded restrictions on the
> class-level instead. We can discuss the pros and cons of that but it does
> not matter for SOSA-core anyway as this would not be part of the core. For
> the core we opted to use the schema.org version namely domainIncludes and
> rangeincludes and those to not carry any formal semantics as they are
> annotation properties. Experience shows, that many end users use domains
> and ranges as guides for how to use a certain predicate and the schema.org
> version captures exactly that without doing any harm (well, aside of the
> harm of possibly causing confusion, adding a meta level, and so forth).
> >
> > Thanks again for all the details you provided and your help in sorting
> out the class issue.
> >
> > Best,
> > Krzysztof
> >
> >
> >
> >
> > On 11/09/2016 03:06 PM, Antoine Zimmermann wrote:
> >> 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: 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>
> >>>>> *Date: *Wednesday, 9 November 2016 at 10:01 am
> >>>>> *To: *Joshua Lieberman <jlieberman@tumblingwalls.com>, Simon Cox
> >>>>> <Simon.Cox@csiro.au>, Kerry Taylor <kerry.taylor@anu.edu.au>,
> >>>>> Armin Haller <armin.haller@anu.edu.au>
> >>>>> *Cc: *SDW WG Public List <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
> > Webpage: http://geog.ucsb.edu/~jano/
> > 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
>
>