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 Wednesday, 9 November 2016 23:07:06 UTC