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

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
>

Received on Wednesday, 9 November 2016 21:15:55 UTC