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] 
Sent: Thursday, 10 November 2016 10:06 AM
To: janowicz@ucsb.edu; Armin Haller <armin.haller@anu.edu.au>; Krzysztof Janowicz <jano@geog.ucsb.edu>; Joshua Lieberman <jlieberman@tumblingwalls.com>; Cox, Simon (L&W, Clayton) <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 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
>>>
>>
>
>

Received on Thursday, 10 November 2016 01:19:32 UTC