Re: New proposal for SOSA

Hi Krzysztof,

Thanks for your effort, I will look into the details asap. Note however,
> that you seem to be reinventing the wheel and probably missed many of our
> discussions over the past year.
>

Sure I did miss many discussions, but I'm working hard to find traces of
the discussions and resolutions.


> For instance, we agreed not to use domain and range restrictions.
>

I am aware of this, but I can't find any trace of an Issue, vote, or
Resolution, that relates to this. Neither in the mails, nor in the minutes.

Just a couple of mails around early Nov 2016:
 - some precise and detailed arguments in favor of these axioms,
 - on the other hand, arguments against were mainly pointing to previous
collegial decisions ("we already decided to..") that I could not find


Same problem for rdfs:subClassOf or rdfs:subPropertyOf. I cannot find any trace
of an Issue, vote, or Resolution, that relates to this.


Nevermind. sosa-proposal.ttl is what I would love to use.
I can live with rdfs:domain and rdfs:range axioms being moved to SSN, or
being replaced by local restrictions, ...

But please don't just focus on this, there is much more in this proposal.

Best,
Max





>
> Best,
> Krzysztof
>
>
>
> On 02/06/2017 06:09 PM, Maxime Lefrançois wrote:
>
> 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>
> 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>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>http://www.w3.org/ns/ssn/ssnx
>  - SSN:  <http://www.w3.org/ns/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# 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
>
>
>
> --
> 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
>
>