Re: New proposal for SOSA

Hi Armin,


>
> It would be useful if you can relate back your changes/additions to the
> ontology to issues that have already been raised on the tracker in the
> current version of SOSA. If there are further changes that you would like
> to see, please add them to the tracker.
>

I have the list of issues and steps to solve them,

It might take a lot of time to create each issue individually in the
tracker, is there some way to do that in a batch ?


>  I don’t think anyone has the bandwidth to compare your proposal to the
> one that has evolved over the last seven months on Github:
> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl
>

Well, my proposal uses the current sosa.ttl as a starting point, so the
history of sosa.ttl  is irrelevant.

Kind regards,
Maxime



>
>
> Thanks,
> Armin
>
>
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
> *Date: *Tuesday, 7 February 2017 at 1:09 pm
> *To: *Armin Haller <armin.haller@anu.edu.au>, "janowicz@ucsb.edu" <
> janowicz@ucsb.edu>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Kerry
> Taylor <kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" <
> public-sdw-wg@w3.org>
> *Subject: *New proposal for SOSA
>
>
>
> Dear all,
>
>
>
> Please find attached a proposal for SOSA, and a figure that illustrates
> it.
>
>
>
> 1)
>
>
>
> I have taken the liberty to add some RDFS axioms in SOSA, knowing that
> such axioms will never prevent SOSA to become one day part of schema.org.
> As a matter of fact, goodrelations, the well known ontology that has been
> integrated into schema.org is highly axiomatized:
>
>  - it uses disjoint classes axioms
>
>  - it uses domains and ranges that are union of classes.
>
>
>
> The second point makes it pretty well aligned with schema.org
> domainIncludes and rangeIncludes actually, while using only the RDFS and
> OWL vocabulary.
>
>
>
> See http://purl.org/goodrelations/v1.owl
>
>
>
>
>
> 2)
>
>
>
> I also propose to remove the sosa:hasValue.
>
>
>
> schema.org already has its way of assigning values to elements (see
> http://schema.org/value). Plus, other ways exist to give a value and a
> unit of measure to an observation result (QUDT, OM,..)
>
>
>
>
>
> 3)
>
>
>
> I have renamed some properties,
>
>  - either to be more aligned with SSN
>
>  - or so that there is a clear naming convention
>
>
>
>
>
> There may be other noticeable differences that I did not document yet.
>
>
>
>
>
> Shall I issue a pull request before we discuss these different points in
> separate threads ?
>
>
>
>
>
>
> I'm working on the rest of my proposal:
>
>  - SSNX: http://www.w3.org/ns/ssn/ssnx
>
>  - SSN: http://www.w3.org/ns/ssn/
>
>  - various alignment documents proposed by Simon
>
>  - some specifications for the server to expose documents and terms in
> accordance with best practices.
>
>
>
> The old namespace http://purl.oclc.org/NET/ssnx/ssn#
> <http://purl.oclc.org/NET/ssnx/ssn> would redirect to
> http://www.w3.org/ns/ssn/ssnx
>
>
>
>  - Ontology SSNX deprecates the old terms and aligns them with either a
> sosa term, or a ssn term
>
>  - Ontology SSN imports SOSA, adds axioms, and other SSN terms.
>
>
>
>
>
> To me, the only tricky parts in the integration of SOSA/SSN so far are:
>
>  - property oldssn:isProducedBy
>
>  - SensorOutput and Observation are merged into a single class.
>
>
>
> Best,
>
> Maxime
>