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

Received on Thursday, 10 November 2016 16:52:21 UTC