- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 1 Feb 2017 16:52:22 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "phila@w3.org" <phila@w3.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "ssimmons@opengeospatial.org" <ssimmons@opengeospatial.org>
- Message-ID: <05fd72a8-10f6-d993-4ba5-76f1446eab7d@ucsb.edu>
> i.e. no action required, just minor clarification on the proposed way > forward > > but kudos for the alignment work done to date :-) > Lets for the moment state that SOSA and SSN are strongly inspired by O&M and that more formal bridges between them are to be developed. If nobody jumps in all of a sudden, we will have made the biggest step today in 6 months and I hope we will not revisit each single point to change or re-discuss it in the near future :-). There is more than enough work left for us anyway. Cheers, Jano On 02/01/2017 04:30 PM, Rob Atkinson wrote: > ok - let me rephrase to make the purpose of "clean" clear, related to > Phil's post suggesting we could use o&m entities in SOSA... > > "I presume > consideration was given to using O&M terms directly in SOSA? Can they > not be used directly? If not, it looks to me as if SOSA terms could be > declared as sub classes and properties of O&M terms. > > I'd say that this can be part of the normative definition of SOSA. > " > > AFAICT there is no suggestion of a canonical version of an O&M > vocabulary that satisifies the requirements for SOSA core ontology as > an import, therefore SOSA already defines terms that can later, in an > informative (as far as this phase of SSN work is concerned) document, > be aligned with the ISO model. > > i.e. no action required, just minor clarification on the proposed way > forward > > but kudos for the alignment work done to date :-) > > Rob > > > > On Thu, 2 Feb 2017 at 09:50 Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>> wrote: > > Thanks Phil for jumping in! > > I thank you, in particular, for recognising that there are, in > fact, rather small issues that have to be solved in the > integration of SOSA/SSN. The issues that you raised below from the > mapping table, namely: > > Actuation *missing* in SSN > (https://www.w3.org/2015/spatial/track/issues/77) > Observation an *Activity* > (https://www.w3.org/2015/spatial/track/issues/67) > ObservableProperty *vs* Property > (https://www.w3.org/2015/spatial/track/issues/87) > Result vs SensorOutput/ObservationValue > (https://www.w3.org/2015/spatial/track/issues/90 > https://www.w3.org/2015/spatial/track/issues/122 > https://www.w3.org/2015/spatial/track/issues/138 > https://www.w3.org/2015/spatial/track/issues/140) > Hosts vs attachedSystem > https://www.w3.org/2015/spatial/track/issues/88 > > have been tabled for a while (outlined in the brackets) and been > put on the agenda many times, but without much success to be able > to discuss them. We do have reached agreement or assigned action > items on some, as below: > > Actuation: https://www.w3.org/2015/spatial/track/actions/215 (a > renewal was meant to be discussed this week in the telco) > Observation: *Closed* with a decision in the Lisbon F2F that an > Observation is an activity > ObservableProperty was introduced in SOSA to give it a more > meaningful name than Property (a very overloaded term on the Web, > and problematic if a tool is used to implement the ontology, e.g. > JQuery). No decision made, but it comes down to a *renaming of > either of the two*. > Result: We need the introduction of classes/properties that model > observation values in SSN, since we cannot rely on DUL anymore for > that. We have not managed to discuss this in detail. > Hosts vs attachedSystem: Kerry made a proposal recently on the > wiki > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017, > again it comes down to a *naming issue* > > Phil, I don’t want to weigh in with my opinion on the three > options you proposed. I can live with all three and I would love > to be able to move on. > > Cheers, > Armin > > On 2/2/17, 9:19 am, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au> wrote: > > Very pleased to see this clarification and convergence. > I would like to support Phil and Jano's proposal. > > Yes there will be some details to work out, but the general > principle is clear: in order to satisfy both rigour and community > expectations, we will need (at least) two files, ontologies, and > namespaces. Everything else is tractable detail within that > framework. So my vote is > > 1. + 2a. > > --- > On SOSA-SSN equivalences, see the commentary with this > pull-request - > https://github.com/w3c/sdw/pull/517 and also the mail sent to the > list > https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0207.html > I had come to essentially the same conclusion as Phil. > > --- > There are already several resources available related to the > O&M alignment, > > A. I dropped this into GitHub a while back > https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/om.ttl > It was an attempt to re-imagine om-lite as a SOSA application. > There was no claim to consensus, or that this should be part > of the spec. It was primarily an exercise to test the modular > architecture proposal. There may be some minor tweaks required now > (and I think I may have used namespaces also used below), but > practically it provides evidence in support. This has been on the > table since July 2016. > > B. And over the weekend, in response to ACTION-255 I crafted > two separate alignment graphs > 1. > https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/rdf/sosa-om-mapping.ttl > which maps from SOSA to O&M using the official ISO 19150-2 URIs to > identify the classes and properties from the UML model > - OGC works closely with ISO, and OGC O&M is also > published as ISO 19156, so **this could be normative** > 2. > https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/rdf/sosa-oml-mapping.ttl > which maps from SOSA to om-lite/sam-lite > - as Phil points out, om-lite does not have any official > organizational endorsement (it is from a paper in Semantic Web > Journal). So if it stays in the spec at all, perhaps in an > informative annex? > > I already drafted a chapter for the spec describing both of > these - see Chapter 8 in > https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/index.html > > > -----Original Message----- > From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>] > Sent: Thursday, 2 February, 2017 07:23 > To: Phil Archer <phila@w3.org <mailto:phila@w3.org>>; SDW WG > Public List <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>; > ssimmons@opengeospatial.org <mailto:ssimmons@opengeospatial.org>; > Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; Armin Haller > <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>> > Subject: Re: Proposals (was Re: Architecture of SOSA/SSN > integration) > > Hi, > > > OK, so then I do think the SSN-only terms should be in the ssn > > namespace, but where a term exists in SOSA, that's the one > we use. > > Yes (but see the note below). > > > I don't think that SSN-only terms should be defined in the > SOSA namespace. > > Yes, I could not agree more. SOSA does not "know" about SSN, > that is the entire point of the lightweight SOSA vocabulary. > > > I hope this slight change does not diminish your support > Krzysztof. > > No, I am still super happy. Can I assume that by "SOSA > namespace" and "ssn namespace" you imply two namespaces? That > would actually make me super happy. Most end users use namespaces > as handles. > > > Proposal 1: That where vocabulary terms are defined in the SOSA > > namespace, no new term should be defined for SSN. > > The tricky part here is how to add more axioms to those > concepts that are in SOSA, e.g., Sensor, but to which we would > like to add further axioms in SSN (e.g., that sensors have > survival ranges). I will write a separate email about this as I > know that these decisions may end up being more difficult to agree > on. My key hope for now is that we can at least agree on your > proposal without ripping it into pieces and then continue with a > positive attitude to work out the remaining details. If we rip > your proposal apart and each of us adds contradicting change > request we will end up in the same nightmare that we are facing > since months. So yes, I still fully support your proposal! > > Thanks again Phil! > > Jano > > > On 02/01/2017 12:12 PM, Phil Archer wrote: > > Thanks for pointing out that there is more to SSN than > what's in the > > mapping table, I should have checked that. > > > > OK, so then I do think the SSN-only terms should be in the ssn > > namespace, but where a term exists in SOSA, that's the one > we use. I > > don't think that SSN-only terms should be defined in the SOSA > > namespace. Therefore, my proposals become: > > > > Proposal 1: That where vocabulary terms are defined in the SOSA > > namespace, no new term should be defined for SSN. > > > > Then: > > > > Proposal 2A: That SSN is characterised as a semantic layer > on top of > > SOSA, with additional terms. > > > > OR > > > > Proposal 2B: That SSN is characterised as a profile of SOSA. > > > > I hope this slight change does not diminish your support > Krzysztof. > > > > Phil > > > > > > > > On 01/02/2017 18:33, Krzysztof Janowicz wrote: > >> Dear Phil, all, > >> > >> Thanks a lot for your thoughts and providing this overview. > I would > >> like to express my *strongest* possible support for your > proposal and > >> hope we can finally move forward and understand that no single > >> solution will make everybody perfectly happy. What you are > proposing > >> is largely in line with what many of us have been > suggesting and > >> working on for months. Please find detailed comments in line. > >> > >>> I believe the currently published document expresses the > consensus > >>> view that SOSA is the semantically light weight core and > that SSN is > >>> the semantically richer and more specific ontology. > >> > >> Yes, exactly. But please let me add a few more important > detail here. > >> SOSA is not only lightweight it also targets a different > audience, > >> namely those that would typically be attracted to > schema.org-style > >> semantic annotations. Hence, SSN can/should "use" (e.g., import > >> subclass, load, profile, etc. [use whatever term makes you > happy > >> here]) SOSA but not the other way around. Consequently, > SOSA has to > >> be designed in a way that it can be used entirely > independently of > >> SSN. On the other hand, SSN really has to use SOSA in some > way and > >> here is why: As we discussed before, SOSA also acts as a > interoperability fallback level. > >> What we do *not* want is that SOSA and SSN users cannot > exchange data. > >> However, and following the current design principles of > SOSA, SOSA > >> also acts as common core of both, and, thus SSN users and > SOSA users > >> can indeed exchange data although they do so on a more abstract > >> level. If you like object-oriented design/programming, then > this idea > >> should sound familiar as it is underlying interfaces, generics, > >> inheritance, and so forth, and it has been immensely > successful. > >> > >>> It defines a class of Actuation that does not appear in > SSN or the > >>> others. Nothing more to say. > >> > >> Yes, and this is not a problem. Same for Sample. We simply > forgot > >> about this in the old-SSN. > >> > >>> > >>> Both SOSA and SSN have an Observation class. In my view, > >>> ssn:Observation should be deleted and SSN users should use > >>> sosa:Observation. Ditto for all classes where any > differences can be > >>> ironed out. > >> > >> Yes, exactly. This is where many of us hope to go and this > is what > >> has been proposed over and over again. Btw, Observation is > really the > >> only critical part here as O&M and old-SSN had a clear > difference > >> here. This is not dramatic, just something that we need to > work on. I > >> have some ideas for this that would also solve our current > hasValue > >> problem (I wrote an email about this some days ago and will > report > >> back on results asap with the hope to receive feedback). > >> > >>> But again, it's the SOSA namespace that wins. If we need > to tweak > >>> the SOSA definitions, do it. > >> > >> Yes! > >> > >>> > >>> Then we get to sosa:ObservableProperty and ssn:Property. > >>> > >>> Looking at the two definitions, there are differences but > they look > >>> very minor to my eyes with sosa:ObservableProperty looking > slightly > >>> more general, so, again, I'd delete ssn:Property. > >> > >> Yes! And keeping in mind that SOSA is more general by > design. This > >> also explains why from a set-theoretic perspective SOSA > categories > >> (due to the lightweight semantics of SOSA classes) are more > inclusive > >> than SSN categories and, in fact, contain them. Please also > note that > >> due to the fact that SOSA has a more lightweight semantics, > we need > >> more detailed human readable class descriptions and this is > why we > >> have a bit more text and examples then we had in the > old-SSN. In the > >> old-SSN we also made some mistakes that we can clean up, > nobody is perfect after all. > >> > >>> > >>> Only when we get to sosa:Result do we see something > different, i.e. > >>> ssn:SensorOutput and ssn:ObservationValue. OK, so here, > for me, are > >>> the only classes in the ssn namespace, both of which are > subclasses > >>> of sosa:Result. > >> > >> We need to change how we handle values as this part got > lost when we > >> removed the direct linkage to DUL. I am working on this > based on the > >> new version of the QUDT ontology (http://qudt.org/). This > will make > >> sure we are compatible with a very important and widely used > >> ontology. I will report back on my results as soon as we > have agreed on your proposal. > >> Otherwise I will have to change everything over and over again. > >> > >>> What's the difference between sosa:hosts and > sosa:attachedSystem ? > >>> Do we need both? > >> > >> SOSA should not have an attachedSystem relation. Do you > mean SSN? > >> > >>> > >>> Hang on, that's *it*. There is no more. > >> > >> Agreed. This is why we have always tried to highlight that > although > >> we have different opinions and different proposals, they > differ by > >> rather small pieces. Almost all of us agree that we can > >> adjust/align/integrate SOSA and SSN without major efforts. > >> > >>> > >>> Question: do we really need ssn:SensorOutput and > >>> ssn:ObservationValue or could we live with just sosa:Result? > >> > >> See above. This problem will go away on its own. > >> > >>> Based on the mapping table, I end up with just *two* > classes and > >>> *no* properties in the SSN namespace. > >> > >> There is more to SSN, namely survival ranges of sensors and > so forth. > >> > >>> So we're talking here about SSN essentially adding further > semantic > >>> constraints on SOSA, not new terms (except possibly two > new classes). > >> > >> SSN contains more, see above. Deployment is another > example. This is > >> not a problem as these classes and relations do not appear > in SOSA. > >> SOSA is simply not the place where one would go into all > the details > >> on how a sensor is constructed and so on, but SSN allows us > to do so. > >> > >>> The SOSA vocabulary (it doesn't have rich enough semantics > to be > >>> called an ontology in my view) is deliberately defined > with loose > >>> semantics - just enough for everyday applications. > >> > >> I am fine with calling it a vocabulary but as it has OWL > axioms I > >> would prefer to call it ontology. Again, I am fine with > whatever the > >> majority wants. Maybe 'vocabulary' is even better for our > envisioned end users. > >> > >>> We've been arguing about the namespace for the SSN terms. > Kerry has > >>> been saying that we don't need another namespace. Reading > through > >>> the mapping table, now I see why: personally, I only see > one vocabulary. > >> > >> This is where I would personally disagree as SSN adds > substantially > >> more content (see above) and end users tend to confuse > namespaces and > >> use them for communication. Also note that SSN is a bit of > an odd > >> name as we ended up not really talking a lot about > (N)etworks. That > >> said, and while I would strongly prefer two namespaces for > clarity, > >> if we all agree to go with your suggestion, I will > certainly not risk > >> a discussion on namespaces if everybody else would prefer > just one namespace. > >> > >>> 6. Alignment to OGC Observations and Measurements > >>> > >>> Looks like a pretty straightforward alignment to me. I presume > >>> consideration was given to using O&M terms directly in > SOSA? Can > >>> they not be used directly? If not, it looks to me as if > SOSA terms > >>> could be declared as sub classes and properties of O&M terms. > >> > >> Yes and we have Simon Cox on the team so this should really > not be a > >> difficult issue. I hope we can give Simon a more active > role here but > >> this is a separate discussion. O&M is really important if > we want > >> SOSA/new-SSN to be a success story. > >> > >>> What about om-lite and sam-lite? > >> > >> IMHO, om-lite is a subset of O&M and is already compatible > with SOSA. > >> In fact, Simon posted an alignment between SOSA and om-lite > in summer > >> of > >> 2016 on our github. > >> > >>> > >>> 8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL) > >>> > >>> For me this is optional but if there's no harm in > including it, go > >>> ahead. > >> > >> This is a problematic point especially with respect to > old-SSN and > >> new-SSN. I can demonstrate why this is problematic in a > separate > >> email but I would strongly suggest we have the DUL > alignment as an > >> optional part. Which should not be confused with me saying > that it > >> does not matter. Also note that the idea of > >> contextualized/scoped/optional axioms does not exist in W3C > OWL. > >> > >>> > >>> Proposal 1: That all vocabulary terms are defined in the SOSA > >>> namespace. > >>> > >>> Proposal 2A: That SSN is characterised as a semantic layer > on top of > >>> SOSA. > >>> > >>> OR > >>> > >>> Proposal 2B: That SSN is characterised as a profile of SOSA. > >>> > >>> Personally, I'd vote in favour of 1 and 2B. > >> > >> I would vote for 1 but this is probably a more difficult > discussion. > >> > >> Dear SSN members, please let us accept Phil's proposal without > >> getting into little infights, very particular details, changes, > >> endless change request, and so forth as we did over the past 6+ > >> months. No proposal will ever make everybody absolutely > happy but > >> Phil's proposal comes from a neutral stance and captures > almost all > >> aspects we discussed so many times and that many of us > supported by > >> their votes over and over and over again. More details > remain to be > >> clarified, but let us do this after we agreed on this > general outline. > >> > >> Jano > >> > >> > >> On 02/01/2017 08:40 AM, Phil Archer wrote: > >>> Dear all, > >>> > >>> I am sorry that I was only able to take part in the first > half of > >>> the meeting yesterday. > >>> > >>> I've been looking at the mapping table [1] and trying to > make some > >>> more sense of what I see and offer how I personally would > choose to > >>> proceed. In doing this I admit that I have been too lax, > allowing > >>> the task force to continue its work without taking the time to > >>> understand the detail of what was being discussed. This is > unhelpful > >>> and I bear some responsibility at least for the current > malaise. I > >>> offer what follows as a possible way forward. In doing so, > please be > >>> sure that I do not have any special powers. This is not a > diktat > >>> from W3C, just a proposal from a WG member. > >>> > >>> I believe the currently published document expresses the > consensus > >>> view that SOSA is the semantically light weight core and > that SSN is > >>> the semantically richer and more specific ontology. > >>> > >>> OK, so we start with SOSA. > >>> > >>> It defines a class of Actuation that does not appear in > SSN or the > >>> others. Nothing more to say. > >>> > >>> Both SOSA and SSN have an Observation class. In my view, > >>> ssn:Observation should be deleted and SSN users should use > >>> sosa:Observation. Ditto for all classes where any > differences can be > >>> ironed out. > >>> > >>> But again, it's the SOSA namespace that wins. If we need > to tweak > >>> the SOSA definitions, do it. > >>> > >>> Then we get to sosa:ObservableProperty and ssn:Property. > >>> > >>> Looking at the two definitions, there are differences but > they look > >>> very minor to my eyes with sosa:ObservableProperty looking > slightly > >>> more general, so, again, I'd delete ssn:Property. > >>> > >>> Only when we get to sosa:Result do we see something > different, i.e. > >>> ssn:SensorOutput and ssn:ObservationValue. OK, so here, > for me, are > >>> the only classes in the ssn namespace, both of which are > subclasses > >>> of sosa:Result. > >>> > >>> On to properties. > >>> > >>> Using the same logic, I would delete: > >>> > >>> ssn:featureOfInterest > >>> ssn:observationResult > >>> ssn:observes > >>> ssn:observedProperty > >>> ssn:sensingMethodUsed > >>> ssn:madeObservation (and move ssn:observedBy to the sosa > namespace > >>> to be consistent with the other inverse properties) > ssn:onPlatform > >>> ssn:observationSamplingTime ssn:observationResultTime > >>> > >>> What's the difference between sosa:hosts and > sosa:attachedSystem ? > >>> Do we need both? > >>> > >>> Hang on, that's *it*. There is no more. > >>> > >>> Based on the mapping table, I end up with just *two* > classes and > >>> *no* properties in the SSN namespace. > >>> > >>> Question: do we really need ssn:SensorOutput and > >>> ssn:ObservationValue or could we live with just sosa:Result? > >>> > >>> So we're talking here about SSN essentially adding further > semantic > >>> constraints on SOSA, not new terms (except possibly two > new classes). > >>> > >>> That's what I call a profile, i.e. a way in which a particular > >>> vocabulary is used, complete with cardinality constraints > and more > >>> finely tuned semantics. We can add textual usage notes and > >>> descriptions as well as semantic axioms but I see no new > terms to add. > >>> > >>> So here's my table of contents for the document: > >>> > >>> 1. Introduction > >>> 2. Developments since the initial 2009 publication of SSN 3. > >>> Modularization 4. The SOSA ontology 5. The SSN Semantic > Layer The > >>> SOSA vocabulary (it doesn't have rich enough semantics to > be called > >>> an ontology in my view) is deliberately defined with loose > semantics > >>> - just enough for everyday applications. > >>> > >>> Where more precise semantics are needed, such as in @@@use > case@@@ > >>> and @@@ use case@@@ an additional layer can be applied. > This allows > >>> data encoded using SOSA to be processed using an OWL resoner. > >>> > >>> Then define all the semantics you like in a file at /ns/ssn/. > >>> > >>> We've been arguing about the namespace for the SSN terms. > Kerry has > >>> been saying that we don't need another namespace. Reading > through > >>> the mapping table, now I see why: personally, I only see > one vocabulary. > >>> > >>> 6. Alignment to OGC Observations and Measurements > >>> > >>> Looks like a pretty straightforward alignment to me. I presume > >>> consideration was given to using O&M terms directly in > SOSA? Can > >>> they not be used directly? If not, it looks to me as if > SOSA terms > >>> could be declared as sub classes and properties of O&M terms. > >>> > >>> I'd say that this can be part of the normative definition > of SOSA. > >>> > >>> What about om-lite and sam-lite? > >>> > >>> Well, they look pretty similar too. Am I right that these are > >>> CSIRO-only ontologies? In which case, I'd say that any > alignment is > >>> up to CSIRO to do and publish. > >>> > >>> 7. Alignment to SSN of the SSN-XG, ssn-ssnx. > >>> > >>> I'd include those assertions in a sub chapter of the one > on SSN. > >>> > >>> 8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL) > >>> > >>> For me this is optional but if there's no harm in > including it, go > >>> ahead. > >>> > >>> I am feeling very guilty. I should have looked at that > mapping table > >>> before now. I think I have learned a lesson. > >>> > >>> Proposal 1: That all vocabulary terms are defined in the SOSA > >>> namespace. > >>> > >>> Proposal 2A: That SSN is characterised as a semantic layer > on top of > >>> SOSA. > >>> > >>> OR > >>> > >>> Proposal 2B: That SSN is characterised as a profile of SOSA. > >>> > >>> Personally, I'd vote in favour of 1 and 2B. > >>> > >>> Phil > >>> > >>> > >>> [1] https://www.w3.org/2015/spatial/wiki/Mapping_Table > >>> > >>> On 31/01/2017 23:39, Armin Haller wrote: > >>>> Hi, > >>>> > >>>> Herewith I am trying to summarise what has been discussed in > >>>> today’s meeting, what was discussed and proposed on the > list and > >>>> what we have already decided on earlier in the working group: > >>>> > >>>> > >>>> · SOSA and SSN use Slash URIs/IRIs > >>>> > >>>> · SOSA and SSN use different IRIs and are > serialised in > >>>> separate ontology files (everyone expect Kerry agreed on > that one, > >>>> although there is her proposal on the wiki stating the same: > >>>> > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Co > >>>> mpromise_Proposal_6_made_by_Kerry_January_2017) > >>>> > >>>> > >>>> > >>>> · SOSA and SSN may use different ontology namespaces > >>>> > >>>> · SOSA uses simple semantics as decided upon > earlier (i.e. > >>>> owl classes, datatype and object properties, inverse > properties, > >>>> but no domain/range and no other owl restrictions) > >>>> > >>>> · SSN imports SOSA > >>>> > >>>> · SSN introduces stronger semantics, using > several types of > >>>> OWL restrictions. As far as I can tell, four options have > been > >>>> presented to add these additional semantics through the > import of > >>>> SOSA: > >>>> > >>>> 1. SSN introduces new classes/properties in its > ontology > >>>> namespace and introduces where appropriate equivalence > relations to > >>>> the class/property in SOSA > >>>> > >>>> 2. SSN introduces new classes/properties in its > ontology > >>>> namespace and introduces subclass relations and where > appropriate > >>>> equivalence relations to the class/property in SOSA > >>>> > >>>> 3. SSN reuses the IRI for classes/properties > defined in SOSA > >>>> and introduces further axioms that “narrow” their > meaning, but does > >>>> not introduce subclass or equivalence relations relying > on the user > >>>> to choose through the ontology namespace the > interpretation of the > >>>> ontology. > >>>> > >>>> 4. A separate core essentially introduces > vocabulary terms with > >>>> no semantics, only a description and a label (very abstract, > >>>> similar to the annotations that I have added to the wiki > >>>> https://www.w3.org/2015/spatial/wiki/Mapping_Table and we > had no > >>>> time to discuss), but its own IRI and “ontology” > namespace. Both > >>>> SOSA and SSN import this vocabulary and extend it with > different > >>>> semantics, solving the issue that SSN has two different > IRIs for > >>>> some classes/properties as would be the case in Option 1-2. > >>>> > >>>> I had the impression that there was no strong objection > against any > >>>> of these options in the call today, but several issues > have been > >>>> raised. > >>>> > >>>> · In option 3 the issue that has been raised was > that users > >>>> who use a class/property in their tool of choice may not > know which > >>>> semantic interpretation should be used in the given context. > >>>> > >>>> · Earlier on the mailing list, an issues has > arising that in > >>>> Option 3 SSN would use the SOSA IRIs for several > classes/properties > >>>> whereas the old SSN only had one IRI for those > classes/properties. > >>>> That could potentially be solved with Option 4. > >>>> > >>>> Please let me know if I missed an option. > >>>> > >>>> Cheers, > >>>> Armin > >>>> > >>> > >> > >> > > > > > -- > 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 Thursday, 2 February 2017 00:53:03 UTC