- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Mon, 6 Feb 2017 14:58:22 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, "Le Phuoc, Danh" <danh.lephuoc@tu-berlin.de>, Kerry Taylor <kerry.taylor@anu.edu.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>, Phil Archer <phila@w3.org>, Armin Haller <armin.haller@anu.edu.au>, SDW WG Public List <public-sdw-wg@w3.org>, "Cox, Simon (CESRE, Kensington)" <Simon.Cox@csiro.au>
- Message-ID: <7e261e0a-b6cb-967e-a06c-25d06b10b2d8@ucsb.edu>
Yes, but since then we voted an having inverse-properties in SOSA and so
forth. The point is rather that the triple store provider sets the
reasoning-profile. We should not try to somehow anticipate or enforce this.
> 1) SOSA definitions
> 2) OWL axioms for reasoining over SOSA definitions
> 3) SSN definitions refining (new narrower subClass/Property) or adding
> to SOSA defs
> 4) SSN OWL axioms
I see your point but this is really getting to complex and difficult and
we also have to keep usability in mind (and also that we only have weeks
left)
Jano
On 02/06/2017 01:20 PM, Rob Atkinson wrote:
> +1 - this is why I keep niggling away at separating the OWL axioms
> from the definitions. IMHO definitions should not require OWL
> reasoning to discover simple RDF axioms. In fact in the original
> discussion about vertical modularity i would have had horizintal
> (scope) modules SOSA and SSN, and vertical modules (RDFS, OWL)
> leaviing us with four really simple to use ontologies:
> 1) SOSA definitions
> 2) OWL axioms for reasoining over SOSA definitions
> 3) SSN definitions refining (new narrower subClass/Property) or adding
> to SOSA defs
> 4) SSN OWL axioms
>
> I think SSN is likely to be quite small (in extra scope), and meant
> for a more targetted group - and having the OWL in the same ontology
> is practically acceptable - but perhaps its worth keeping them
> separate simply to stop us getting snarled up in interpretation of
> intentions.
>
> I guess we could live with SSN including 2,3,4 and being 100%
> consistent with SOSA, so that if you asked for SOSA using the OWL
> content-type it would be acceptable to get the SSN ontology - and if
> you asked for SSN using RDF, JSON etc you could get either the full
> SSN ontology or the sub-graph of RDFS/SKOS definitions.
>
> (Maybe i'm too focussed on how you would implement applications of
> such a modular ontology - but separation of concerns is just the habit
> of a lifetime :-) )
>
> Rob
>
>
>
> On Tue, 7 Feb 2017 at 06:26 Krzysztof Janowicz <janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>> wrote:
>
> Hi Danh,
>
>
>> The point I would like to make is that the ontology can provide
>> possible semantics (RDFS, OWL..), but, we have to take into
>> consideration all possible interpretations in data consuming/data
>> annotation phases (probably, best practices are needed for each
>> scenarios of use). And don’t underestimate the community (Web
>> developers or IoT developers) that assume simple semantics like
>> RDF or RDFS, that’s why schema.org <http://schema.org> is so
>> success. Moreover, pointing to related Working Group, Web of
>> Things, , there is some discussions around how to build just very
>> small code-foot-print reasoner to interpret only the data types
>> like the one in Q2 for IoT constraint devices.
>>
>
> Agreed. I think this is a very important discussion and we had it
> a few times before in this group. One key issue here is that there
> are certain things, like the selected reasoning capabilities, that
> are outside of our control. I guess the best way to address this
> is by providing as much detail as possible in the documentation
> and the ontology to make clear what our underlying assumptions
> were when we created SOSA/SSN.
>
> Jano
>
>
>
>
> On 02/06/2017 08:57 AM, Le Phuoc, Danh wrote:
>>
>> Hi Kerry and Rob, and probably Phil and Maxime in earlier emails
>> on semantics &entailment regime for data instances ( I reuse
>> Phil’ “data instance term” in previous emails),
>>
>> I would like to highlight that the publisher only can provide the
>> potential semantics of the ontology or the data annotated with
>> the ontologies, then, it’s up to the consumer to choose which
>> semantics they would like to interpret the data. For example,
>>
>> SOSA uses both RDFS vocabularies and OWL vocabularies (e.g,
>> inversedProperty), even it’s very simple but there are some
>> reasoning that can be done with this, for example, if you enable
>> only RDFS++ reasoning capability[1] to your query engine/SPARQL
>> Endpoint such as Virtuoso or AllegroGraph, it can reason over
>> RDFS axioms together “inversed property” in following data
>> instance annotation:
>>
>> :result1 sosa:isResultOf :observation1;
>>
>> sosa:hasValue “true”^^xsd:boolean.
>>
>> The RDFS++ reasoning will infer the implicit triple :
>> :/observation1 sosa:hasResult: :result1/, therefore, the query
>> engine will be able to return 1 result with this query
>>
>> *Q1: SELECT * WHERE { ?obs sosa:hasResult ?res}*
>>
>> However, if you only use a RDFS reasoner,then, the reasoner will
>> ignore all OWL axioms and treat OWL related triples as regular
>> RDFS statements, therefore, the query engine will not return any
>> results with query Q1. Along this line, if we have data instances
>> annotated with both SOSA/&SSN that have other strong axioms e.g,
>> owl:Restriction, owl:equivalentClass, the RDFS++ reasoner will
>> ignore them and treat them as usual RDFS++ statements that it
>> can “understand”, e,g. RDFS vocabulary and owl:inverseOf,
>> owl:TranstivePropery.
>>
>> On the opposite side of the complexity, the most popular
>> entailment is RDF entailment[2] that is default interpretation of
>> data instances annotated with RDF-based vocabularies/ontologies.
>> But bear in mind, RDF interpretation also does some reasoning
>> even quite trivial, for example in bellow Q2 will return 1 result
>> even the data does not explicitly state any /“rdf:type”/ statement:
>>
>> *Q2: SELECT * WHERE { ?obs sosa:hasValue ?value. ?value rdf:type
>> xsd:boolean}*
>>
>> The point I would like to make is that the ontology can provide
>> possible semantics (RDFS, OWL..), but, we have to take into
>> consideration all possible interpretations in data consuming/data
>> annotation phases (probably, best practices are needed for each
>> scenarios of use). And don’t underestimate the community (Web
>> developers or IoT developers) that assume simple semantics like
>> RDF or RDFS, that’s why schema.org <http://schema.org> is so
>> success. Moreover, pointing to related Working Group, Web of
>> Things, , there is some discussions around how to build just very
>> small code-foot-print reasoner to interpret only the data types
>> like the one in Q2 for IoT constraint devices.
>>
>> [1]
>> http://franz.com/agraph/support/documentation/current/agraph-introduction.html#header3-110
>>
>> [2]
>> <https://www.w3.org/TR/rdf11-mt/#rdf-entailment>https://www.w3.org/TR/rdf11-mt/#rdf-entailment
>>
>>
>> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
>> <mailto:kerry.taylor@anu.edu.au>
>> *Date: *Monday 6 February 2017 at 04:55
>> *To: *Rob Atkinson <rob@metalinkage.com.au>
>> <mailto:rob@metalinkage.com.au>, Maxime Lefrançois
>> <maxime.lefrancois@emse.fr> <mailto:maxime.lefrancois@emse.fr>,
>> "janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu>
>> <janowicz@ucsb.edu> <mailto:janowicz@ucsb.edu>, Phil Archer
>> <phila@w3.org> <mailto:phila@w3.org>, 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>, "Cox, Simon (CESRE, Kensington)"
>> <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>
>> *Subject: *RE: State of SSN: arguments in favour of a single name
>> and namespace, proposal, the SEAS example, proposal of action
>> *Resent-From: *<public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org>
>> *Resent-Date: *Monday 6 February 2017 at 04:56
>>
>> Sorry, I meant by “> Possibly – how would you distinguish these
>> options? “ to say that I do not understand what distinguishes them….
>>
>> > OWL has its own content type-
>>
>> Are you sure?– I don’t know where to look but I can only find
>> this from the old Owl 1.0.:
>>
>> *2.3 MIME type*
>>
>> The Web Ontology Working Group has not requested a separate MIME
>> type for OWL documents. Instead, we recommend to use the MIME
>> type requested by the RDF Core Working Group, namely
>> application/rdf+xml[/RDF Concepts
>> <https://www.w3.org/TR/2004/REC-owl-ref-20040210/#ref-rdf-concepts>/],
>> or alternatively the XML MIME type application/xml.
>>
>> As file extension, we recommend to use either .rdfor .owl.
>>
>> And I can find nothing else owl-specific here either:
>> http://www.iana.org/assignments/media-types/media-types.xhtml
>>
>> >Complexity for the provider is preferable to complexity for the
>> consumer IMHO.
>>
>> Always!
>>
>> --Kerry
>>
>> *From:*Rob Atkinson [mailto:rob@metalinkage.com.au]
>> *Sent:* Monday, 6 February 2017 12:55 PM
>> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
>> <mailto:kerry.taylor@anu.edu.au>; Rob Atkinson
>> <rob@metalinkage.com.au> <mailto:rob@metalinkage.com.au>; Maxime
>> Lefrançois <maxime.lefrancois@emse.fr>
>> <mailto:maxime.lefrancois@emse.fr>; janowicz@ucsb.edu
>> <mailto:janowicz@ucsb.edu>; Phil Archer <phila@w3.org>
>> <mailto:phila@w3.org>; 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>; Cox, Simon
>> (CESRE, Kensington) <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>
>> *Subject:*Re: State of SSN: arguments in favour of a single name
>> and namespace, proposal, the SEAS example, proposal of action
>>
>> Its just a suggestion - to make two small steps instead of a big
>> one.Because "core" has no formal accepted meaning and we seem to
>> keep tripping up over the relationship between SSN and SOSA,
>> because there are two distinct things happening. Complexity for
>> the provider is preferable to complexity for the consumer IMHO.
>>
>> OWL has its own content type- so my reading is we dont need to
>> extend Web practices to consider serialisation of the SOSA
>> semantics into OWL axioms as equivalent to the simple RDFS with
>> descriptions, we just get different resources depending on the
>> serialisation we choose. This enforces and clarifies the role of
>> the OWL axioms.
>>
>> I guess this makes "SSN" a much lighter weight profile with its
>> specific extended semantics, but thats really not the end of the
>> world.
>>
>> Rob
>>
>> On Mon, 6 Feb 2017 at 11:40 Kerry Taylor <kerry.taylor@anu.edu.au
>> <mailto:kerry.taylor@anu.edu.au>> wrote:
>>
>> >Are we sometimes confusing "using two namespaces" with
>> "define each object in each namespace" ?
>>
>> Possibly – how would you distinguish these options? Does the
>> latter require an alignment like ssn:Sensor subclassof
>> sosa:Sensor whreas the former does not?
>>
>> >My concern is whether we should modularise into SOSA,
>> SOSA-OWL and SSN extensions to simplify interpretation. SSN
>> can import SOSA-OWL, SOSA-OWL can be accessed using content
>> negotiation on the SOSA namespace. IMHO that takes one piece
>> of magic knowledge away from the user - how to find SSN given
>> SOSA terms, to use OWL reasoning on it.
>>
>> I dunno – sounds needlessly complex to me. It seems really
>> strange that an ontology (SSN) needs an intermediary
>> SOSA-OWL to talk to its own core (SOSA). Not sure how the
>> content negotiation would work either --- are you suggesting
>> that sosa-owl has a different media type to SOSA? Does that
>> really make it easy to find? Or would you use term-by-term
>> redirection like Maxime’s model – but that only works if you
>> have some terms that are actually different in each module.
>> And what would SOSA-OWL look like? Does this do away with
>> ssn:Sensor subclassof sosa:Sensor ?
>>
>> -Kerry
>>
>> *From:*Rob Atkinson [mailto:rob@metalinkage.com.au
>> <mailto:rob@metalinkage.com.au>]
>> *Sent:* Monday, 6 February 2017 9:31 AM
>> *To:* Maxime Lefrançois <maxime.lefrancois@emse.fr
>> <mailto:maxime.lefrancois@emse.fr>>; janowicz@ucsb.edu
>> <mailto:janowicz@ucsb.edu>; Phil Archer <phila@w3.org
>> <mailto:phila@w3.org>>; 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>>; Cox, Simon (CESRE,
>> Kensington) <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>
>>
>>
>> *Subject:* Re: State of SSN: arguments in favour of a single
>> name and namespace, proposal, the SEAS example, proposal of
>> action
>>
>> Are we sometimes confusing "using two namespaces" with
>> "define each object in each namespace" ?
>>
>> I think we are fine to have a namespace for SSN, and still
>> use SOSA namespace in SSN, and add OWL axioms to reinfoirce
>> SOSA descriptions.
>>
>> The distinct SSN namespace allows SSN to introduce addition
>> terms (to handle name equivalence, actual subclass
>> specialisations, terms not covered in SOSA).
>>
>> if we find a sosa: thing in instance data, we should know its
>> consistent with SOSA semantics, and if we are fully aware we
>> can use SSN axioms to validate it.
>>
>> My concern is whether we should modularise into SOSA,
>> SOSA-OWL and SSN extensions to simplify interpretation. SSN
>> can import SOSA-OWL, SOSA-OWL can be accessed using content
>> negotiation on the SOSA namespace. IMHO that takes one piece
>> of magic knowledge away from the user - how to find SSN given
>> SOSA terms, to use OWL reasoning on it.
>>
>> Rob
>>
>> On Sun, 5 Feb 2017 at 21:58 Maxime Lefrançois
>> <maxime.lefrancois@emse.fr
>> <mailto:maxime.lefrancois@emse.fr>> wrote:
>>
>> Dear Jano,
>>
>> +1. And there are other reasons as well, namely the
>> branding for instance. We anticipate a large user
>> base for SOSA (substantially larger than (full) SSN).
>> We want SOSA to be a recognizable product and end
>> users will assume that they can refer to it by its
>> own namespace, look up the namespace at prefix.cc.,
>> and so on (see also Josh's argument).
>>
>> The argument that could convince me is the one from Simon
>> [1]. I'll add: given SSN will import SOSA, then it *will
>> also* talk about actuators and sampling. Furthermore,
>> because SSN adds axioms to e.g., sensors, and for
>> completeness reasons, I would vote for SSN to include
>> axioms for actuators and sampling. Hence I agree that SSN
>> as a name might become too restrictive for an ontology
>> where actuators and sampling became so much important.
>>
>> So to make it clear, I am still in favor of a single name
>> and namespace. I could live with any mention of SSN being
>> renamed "SOSA Full", and:
>>
>> - the new ssn namespace being dropped
>>
>> - the old ssn namespace redirect to an ontology document
>> thatimports SSN full and defines alignment with sosa terms.
>>
>> Lets follow the KISS principle and do what the vast
>> majority of end users would expect. The more we add,
>> the more we have to explain, the more has to be
>> maintained, the more can be misunderstood, and so on.
>> Finally, we would also all need to fully understand
>> the other proposal, discuss it, compare it with
>> current practice, anticipate whether this will be the
>> mainstream approach in the future (as we hope
>> SOSA/SSN will be around for many years to come), and
>> so on.
>>
>> As a user of what will come out of this working group, I
>> must warn you that in its current state, SOSA appears to
>> me as arbitrarily incomplete, uncoherent, and therefore
>> unuseful. To name but a few that are listed at [2]:
>>
>> 1. there is no relation between feature of interest and
>> observable property
>>
>> 2. links exist between observation/sensor and feature of
>> interest/observable property, but there exists no
>> parallel link with actuation/actuator and feature of
>> interest/observable property
>>
>> 3. why is phenomenonTime a object property whereas
>> resultTime is a datatype property ? This is counter
>> confusing because they both end with "time".
>>
>> 4. there is the Result for observation/actuation, but
>> there is nothing to describe the Command of the actuation.
>>
>> 5. there is no link between the actuator/sensor and the
>> procedure it implements
>>
>> 6. result time could be replace with prov:generatedAtTime
>>
>> 7. there is invokedBy/invokes for actuators, but there
>> is only madeObservation for sensors
>>
>> 8. domain of isFeatureOfInterestOf includes only feature
>> of interest, but range of inverse property
>> hasFeatureOfInterest includes both feature of interest
>> and sample.
>>
>> 9. actuation and observation are in some "virtual box"
>> one could give a proper name to, such as "Procedure
>> execution"
>>
>> 10. actuator and sensor are in some "virtual box" one
>> could give a proper name to, such as "Procedure executor"
>>
>> 11. to me one should keep sosa:hasResult but delete
>> sosa:Result, sosa:resultTime and sosa:hasValue.
>>
>> The core modules of the SEAS ontologies are already some
>> kind of generalization of SSN and look very similar to
>> SOSA without the aforementioned uncoherences. I could
>> also try to push my own solution as "the new standard",
>> but I won't. I believe in team work, discussion and
>> consensus.
>>
>>
>> If we accept to solve these problems, then I already
>> agreed to update the SEAS ontologies so that they are
>> built on top of SOSA. This would indirectly make the SEAS
>> implementations become implementations for SOSA
>> [3].Otherwise, I won't be part of the user base.
>>
>>
>> Other proposals for mimicking SSN for actuators exist in
>> the wild, see [4]. I believe we want to attract the users
>> base of this ontology too.
>>
>> Let's not experiment. We already agreed on two URLs
>> and two files, let's go with two clear namespaces as
>> well and move to the pressing problems we need to
>> sort out before we run out of time. These discussions
>> really distract us. There is *no* damage in using two
>> namespaces but there is clear damage from having an
>> incomplete product by the end of the month.
>>
>> I'm not experimenting here. I really hope the work I do
>> can help the group move forward by:
>>
>> - having proper turtle documents that, when you look at
>> them, can trigger the idea that SOSA and SSN were written
>> by the same group;
>>
>> - specifying properly how the w3c server should serve
>> the different documents;
>>
>> - identifying issues in SOSA and help solving them.
>>
>> - being able to do agile modifications to implement
>> right away any suggestion so that we discuss on products
>> that are ready to be delivered (Agile).
>>
>> [1] -
>> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0051.html
>>
>> [2] -
>> https://github.com/maximelefrancois86/sdw/tree/one-namespace/ssn/one-namespace
>>
>>
>> [3] - http://seas.asema.com/
>>
>> [4] -
>> http://www.irit.fr/recherches/MELODI/ontologies/SAN#
>> <http://www.irit.fr/recherches/MELODI/ontologies/SAN>
>>
>> Best,
>>
>> Maxime
>>
>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
> 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 Monday, 6 February 2017 22:59:00 UTC