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

Kerry,


On 09/11/2016 15:01, Kerry Taylor wrote:
> *From:*Kerry Taylor
> *Sent:* Wednesday, 9 November 2016 11:19 PM
> *To:* 'Joshua Lieberman' <jlieberman@tumblingwalls.com>
> *Subject:* RE: rdfs:class versus owl:class in SOSA-Core
>
> ØSince owl:Class rdfs:subClassOf rdfs:Class, then any owl class is also
> an rdfs class. However, not every rdfs class is an owl class.
>
> True – but it takes an owl reasoner to know that --- an rdfs reasoner is
> blissfully ignorant of what an owl:Class is, hence the need for
>   :myClass a rdfs:Class (or some other way of having the same effect).
>
> I think we need to be very, very clear that an owl reasoner is not
> needed for working with the ssn core. By far the easiest way of making
> that clear is to avoid owl terms entirely in the core.

Can I know the reason why it is important to avoid any reference to OWL 
in SSN core?


> Sure—you can assert owlish things like “:myClass a owl:Class”   in the
> core that an rdfs reasoner can ignore and you just get the rdfs
> entailments – but if you only want rdfs entailments then  what could be
> the possible utility in asserting such owlish things? Why go to so much
> trouble to only  confuse the consumers? Schema.org tackles  this by
> making up owl: lookalikes – things that are claimed **informally** to
> have the semantics of owl  or something very close but are not owl.

Yeah, and this is bad. One has to be very careful in comparing any 
ontology initiative to schema.org. Schema.org is very successful and 
it's tempting to reproduce the same approach. But schema.org is not 
design to have applications exchange schema.org-compliant messages. Each 
search engine have their own interpretation of how to consume schema.org 
data and there are visible differences in what Google and what Bing 
displays for the same results. They don't care about conformance. For a 
company that can influence millions of webmaster to adopt the proposal 
(even if used badly), it's super efficient and super useful. It's useful 
to me. But it's semantic web made dirty. It's not helpful to sensor 
networks.

> I
> tend to think that is the worst of all worlds, but others would disagree
> I am sure.
>
> And if we **do** want owl reasoning to be needed for working with the
> core --- then what part? And why? Here we are struggling with the
> problem  “ssn is too complex because you need an owl reasoner” and we
> are suggesting that an answer like “Hey look at our simple core --- it
> has significant owl: terms in it  but you don’t have to use a reasoner
> if you don’t want to and you can’t really tell in your queries whether
> it has been used or not,  nor can you tell whether you should, for your
> publishing,  be using  a real reasoner or some other extra non-owl thing
> that implements  just the little bit of owl we chose to stick in the
> ontology – but hey look it is **really** simple “.

I do not buy these arguments. What you are telling is that people who 
may consider using the ontology would look into the RDF file, find what 
constructs are there and if they see owl: they start flipping, believing 
they can only use this with an OWL reasoner?  People don't do that. 
They look at the documentation, read the description of what the terms 
are used for (in English!) and adapt examples that are given in figures 
with nodes and arrows, or in code in, e.g., JSON-LD.  We don't have to 
show them ostensibly owl: terms, highlighted and blinking everywhere. 
Most people who are users of an ontology simply want to author data that 
make use of the terms in appropriate ways.  This, in almost all cases, 
does not require reasoning of any kind (not even RDFS).

My experience wrt how OWL ontologies are used is that people do not care 
in what expressiveness the ontologies are. They use (or don't use) the 
reasoners *they* want, not anything that has to do with what's in the 
ontology.  A good example is GoodRelations.  Very expressive, 
aggressively using complex OWL constructs, yet no one really cares about 
the axioms, as far as I can see. It's just a vocabulary for telling 
search engines what the price of a product is.


I'm sorry, I'm writing overly long emails while I'm trying to catch up 
with the work on SSN, and I do not even know all the context of this 
discussion. Please don't get offended.


--AZ

> Yes, I am wandering all over issue-72 here. And I am convincing myself
> that we should stick purely to rdf(s) in the core. If we can’t do that,
> then we should be very, very clear about what part of owl we are using.
> And to do that it had better be a named owl sublanguage.
>
> --Kerry
>
> *From:*Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
> *Sent:* Wednesday, 9 November 2016 4:58 PM
> *To:* Rob Atkinson <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>
> *Cc:* Krzysztof Janowicz <jano@geog.ucsb.edu
> <mailto:jano@geog.ucsb.edu>>; Simon Cox <Simon.Cox@csiro.au
> <mailto:Simon.Cox@csiro.au>>; Kerry Taylor <kerry.taylor@anu.edu.au
> <mailto:kerry.taylor@anu.edu.au>>; Armin Haller <armin.haller@anu.edu.au
> <mailto:armin.haller@anu.edu.au>>; SDW WG Public List
> <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>
> *Subject:* Re: rdfs:class versus owl:class in SOSA-Core
>
> Since owl:Class rdfs:subClassOf rdfs:Class, then any owl class is also
> an rdfs class. However, not every rdfs class is an owl class.
>
>     On Nov 8, 2016, at 6:47 PM, Rob Atkinson <rob@metalinkage.com.au
>     <mailto:rob@metalinkage.com.au>> wrote:
>
>     Correct me if I'm wrong here:
>
>     :myClass a owl:Class, rdfs:Class
>
>     is the same as
>
>     :myClass a owl:Class
>
>     if you are using OWL reasoning.
>
>     If you are using RDFS reasoning (and tools like RDF4J support this)
>     - then these statements are not the same - and only the first one
>     helps you with any RDFS reasoning.
>
>     So why cant we just use the first form?
>
>     The principle would be that the "core" would not _require_ OWL
>     reasoning to provide a RDFS model. It doenst mean we don't model in
>     OWL, just that we take on the responsibility of materialising OWL
>     entailments sufficient to allow any RDFS entailments. (Thats what I
>     mean about a "contract" with the user - being explicit about what
>     entailments are theer responsibility
>
>     Note that is we state:
>
>     :myClass a rdfs:Class
>
>     and say:
>
>     :myClass owl:equivalentClass eg:yourClass
>
>     then if you use OWL reasoning you get
>
>     :myClass a owl:Class, rdfs:Class
>
>     because
>
>     owl:equivalentClass rdfs:domain owl:Class
>
>     owl:equivalentClass rdfs:range owl:Class
>
>     Therefore, if you don't explicitly state its an owl:Class you can
>     still do OWL reasoning and you have lost nothing - but if you don't
>     explicity state its and RDFS class then you wont get the full RDFS
>     expressible semantics  without OWL reasoning.
>
>     statements such as owl:inverseOf are just documentation for RDFS
>     interpretations, and perhaps "do no harm"?
>
>     am I missing something here?
>
>     note that we can then have sosa-owl-dl  and other OWL flavours as
>     vertical modules that require OWL reasoning to be fully understood.
>
>     Rob Atkinson
>
>     On Wed, 9 Nov 2016 at 10:01 Krzysztof Janowicz <jano@geog.ucsb.edu
>     <mailto:jano@geog.ucsb.edu>> wrote:
>
>         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 22:25:10 UTC