- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 7 Feb 2017 14:22:23 -0800
- To: Kerry Taylor <kerry.taylor@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Armin Haller <armin.haller@anu.edu.au>, "rob@metalinkage.com.au" <rob@metalinkage.com.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, "maxime.lefrancois@emse.fr" <maxime.lefrancois@emse.fr>
- Message-ID: <b5d33824-ba9c-de9c-a11e-5bea92d8e640@ucsb.edu>
> In ssnx we have an alignment ontology for backward compatibility > whose purpose is to (with a reasoner) turn any old ssn into new ssn so > they can play together. My problem was what goes there. [Trying to navigate all the many emails]. What you mean with *any* old ssn? Data that used the old ssn? Also keep in mind that old ssn creates many different assertions compared new ssn, so I am not 100% sure what you mean by compatibility. On 02/07/2017 02:16 PM, Kerry Taylor wrote: > > Now I don’t know what you mean --- sorry – but I note Danh and Maxime > seem to have resolved this backward compatibility question in another > thread. Maybe there are other ways too. > > In ssnx we have an alignment ontology for backward compatibility > whose purpose is to (with a reasoner) turn any old ssn into new ssn so > they can play together. My problem was what goes there. > > Kerry > > *From:*Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] > *Sent:* Wednesday, 8 February 2017 8:09 AM > *To:* Armin Haller <armin.haller@anu.edu.au>; Kerry Taylor > <kerry.taylor@anu.edu.au>; rob@metalinkage.com.au; > public-sdw-wg@w3.org; maxime.lefrancois@emse.fr > *Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only: FIRM PROPOSAL > > Hold on – > > ØExcept it is NOT backwardly compatible for ssn users, who use > “property” for things that are observed. > > Is this still the URI issue, or are we worried about local names, or > is it the definitions that you are worried about? > > If it is the URIs, then ‘ssn users’ used > http://purl.oclc.org/NET/ssnx/ssn#Propertyfor things that are observed. > > In the revised vocabularies, it will be > > http://www.w3.org/ns/sosa/ObservableProperty and > http://www.w3.org/ns/ssn/Property > > These are different anyway. > > I don’t know that we should worry about local-names. > > The definitions (textual and axiomatic) can be dealt with. > > Is there something else? > > Simon > > *From:*Armin Haller [mailto:armin.haller@anu.edu.au] > *Sent:* Wednesday, 8 February, 2017 07:49 > *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>>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>; Cox, Simon (L&W, > Clayton) <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>; Maxime > Lefrançois <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>> > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only: FIRM PROPOSAL > > This is a compromise I thought we were heading to yesterday. > > +1 from me for this approach on solving the observable property issue. > > *From: *Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> > *Date: *Wednesday, 8 February 2017 at 1:54 am > *To: *Rob Atkinson <rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>>, "public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>>, "Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>>, Maxime Lefrançois > <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>> > *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only: FIRM PROPOSAL > *Resent-From: *<public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>> > *Resent-Date: *Wednesday, 8 February 2017 at 1:55 am > > Rob, Simon, Armin , Maxime and all, > > Don’t get me wrong – I totally agree that ‘a distinction is > meaningless”. Given (a) the existence of an OGC standard (O&M) and > (b) the long time practice in SSN (whcih was only because of (a)) , > “Property” really does seem the sensible default. And its easier to say! > > However, if indeed ‘Property" was too ambiguous” , and recognising the > painful double-meaning in RDF, and subject to something sensible > happening around here for Actuators, and noting that ‘Observable > property’ seems to be entirely equivalent in meaning to “Property” in > anyone’s use of it that I can see, > > and following up on Armin’s suggestion, > > We could > > (1) use Observable property in sosa > > (2) use “observable property” in ssn in the restriction context (as in > sosa) of a property that is the observedproperty of an observation > > (3) in ssn assert observableproperty subclassOf Property > > (4) continue to use Property for all those other things that ssn uses > it for now, such as the superclass of “survivalrange”. > > (5) leave it to a user if they want to assert that those other > properties (e.g. survival range) are also subclasses of > “observableproperty” incase they want to observe it > > (6) fix rdfs:comments accordingly > > This is entirely consistent with my integration proposal but its is > MUCH harder than just sticking to “Property”. > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017 > . And it a alows sosa-ssn interoperability perfectly (ie all your > observational instances still interoperate both directions). And I > can’t see the dul alignment being affected. > > Except it is NOT backwardly compatible for ssn users, who use > “property” for things that are observed. Ideas? Such users could add > “observableproperty equivalentclass Property” I suppose? We could put > this in ssnx ontology? Is it just much too late at night for me to > see if there is no problem here anyway – mihgt have to have another > look at observation to be sure. Maybe its ok without the equivalent > assertion… > > ØBtw: “But it is clear that some properties definitely are not > “observable” in any normal sense (e.g. “name”, “owner”, “creator”) and > could never be associated with sensing procedures or instruments. “ > > I think that is in direct contradiciotn with our own definitions of > “observable property’, but I don’t care….see “Assertion’ type below. > Surely a human sensor can observe the price of an item in a shop? Or > the name of a person from a nametag? Or the creator of a piece of art > by studying its style? So can an image processing sensor. Or maybe a > barcode scanner. But it is not important. > > Change of topic… > > ØOn subclassing: why is it that you dislike having these in > alignments? Is there a principled reason for this application, or does > subclassing introduce some general difficulty that I’m not familiar with? > > Lots of reasons. *But the most important one is the bi-directional > interoperability*. So you can take a ssn full instance , let a > reasoner run for all the instances, throw away any non-sosa terms and > voila you have a proper sosa instance. E.g. if you have a > sosa:observation subclass of ssn:observation you cannot do this. OTOH > you can take a sosa instance, and it is a fully formed ssn instance > just start decorating it as it is with any extra ssn properties you > want. E.g. if you have a ssn:observation subclass of > sosa:observation you cannot do this. > > Ok equivalentclass can do that right —but that ‘s inelegant for other > reasons. > > And its not an “alignment” --- what an ugly design to make an > ontology ”align” with its simple core! Truly bizarre. > > And what do we think we are doing to our poor users forcing them to > use the same term with two different prefixes in the same ontology? > Whoever would force that on anyone???? How are they supposed to know > what they are to do – even if they actually notice there is a > difference before they break everything. > > I should take on the task of formalising this property - I am quite > sure I did not invent it --- it is really important to me or else > how can sosa make any sense as a core of ssn?– and Jano’s original > modularisation proposal seems to have this property anyway. Where did > it all go wrong? > > *So … will you help?*Is there anyone out there that can understand > what I am saying yet? Maxime seems to get it!! I absolutely cannot > do this alone. > > Kerry > > *From:*Rob Atkinson [mailto:rob@metalinkage.com.au] > *Sent:* Tuesday, 7 February 2017 6:07 PM > *To:* Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>; Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>>; janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>; maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>; public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > FWIW, my experience of people using O&M is that "Property" was too > ambiguous and people used it in rather arbitrary fashion - strictly is > should relate to a property of the feature being observed, but with > intermediate sampling features, and in general the model of the > observed feature not being available formally this was generally too > hard to unravel - and people tend to use it as a surrogate for the > procedure, or a generalised classification of the subject, or just > their cat's name or something. > > So I would suggest the current long-hand name of "ObservableProperty" > is helpful - and its an opportunity to educate that "observations" may > be performed by physical sensors or via models. IMHO there are > actually a chain of scientific models in play for every physical > sensor, and its all the same thing and a distinction is meaningless. > Sensors are a way to give a shorthand identifier to part of such a > chain, because the sensor construction makes that chain immutable. > > Rob > > On Tue, 7 Feb 2017 at 13:44 Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>> wrote: > > Kerry, you seem to be ok with recasting uses of Property in SSN, as > below. I note here that it does not have to be a recasting of **all**, > only where appropriate. There are already several other subclasses of > Property in SSN, e.g. SurvivableProperty, OperatingProperty etc. which > seem to be introduced in SSN to make it easier for the user of the > ontology to know what is meant with “Property” in a specific use of > the class. The same would apply to ObservableProperty that is > introduced in the core, making it easier for the user to know what > this class means, in the absence of OWL axioms that give the informed > user a clue on its intended use. > > *From: *"Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>" > <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>> > *Date: *Tuesday, 7 February 2017 at 1:29 pm > *To: *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>>, > "janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>>, "maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>" <maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>>, "public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>> > > > *Subject: *RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > Thanks for exploring this Kerry. > > I agree that at least some ‘derivation’ processes fall into our broad > definition of ‘sensing’ and ‘observation’. > > Note that I did hedge the subclassing with the statement > > “These are not necessarily disjoint …”. > > But it is clear that some properties definitely are not “observable” > in any normal sense (e.g. “name”, “owner”, “creator”) and could never > be associated with sensing procedures or instruments. > > So there is a spectrum, but I would suggest that in the SSN layer at > least we really are only interested in Observable Properties, and it > is likely that inventories of these could be usefully assembled, > alongside catalogues of sensors. And that it is useful to keep these > clear of the non-observable properties. > > On subclassing: why is it that you dislike having these in alignments? > Is there a principled reason for this application, or does subclassing > introduce some general difficulty that I’m not familiar with? > > Simon > > *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>] > *Sent:* Tuesday, 7 February, 2017 12:37 > *To:* Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>; Maxime Lefrançois > <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>>; Cox, > Simon (L&W, Clayton) <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Subject:* RE: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > This subclass means that ssn instance data does not become > sosa-compliant instance data (I would love to have that if you take > all the instances of all the core terms out of an ssn full instance > you also have a usable sosa instance. I know this is asking a lot… but > I want bi-directional interoperability which is implied by my proposal > for integration. I should have spelled this out earlier – and I > suppose it needs some formalisation to be useful. > > In this case if we really need “ObservableProperty)” ( and my own > view is that this is just silly vocabulary, and I’d much rather keep > “property” for O&M compliance anyway, nevertheless I can live with it) > I would like to check again whether **all** SSN uses of Property > could be recast as “Observable property”. They are certainly not all > “Observed” properties, but given an explanation of what distinguishes > “observable” from others kind of properties I would look at the > implications. > > OTOH looking at Simon’s ISO list : > > >-Observation > > >-Assertion (e.g. name, price) > > >-Derivation (e.g. classifications based on combinations of observed > properties) > > >- Inheritance/instantiation (e.g. where a property value is assumed on > the basis of class membership) > > >These are not necessarily disjoint, and it is likely that observable properties are the most interesting > (depending on you epistemological viewpoint) >but it is useful to > recognize that observable properties are a distinct class. > > It is very clear that in sosa we do **not** want “observable > properties” because we have sensors that are computational > simulations making observations by ‘Derivation” so this may not be > Observable at all. And surely ours can also can be “Assertion” (in > the case the sensor is a human, for example). Maybe even > inheritance/instantiation too. For the latter if we want to observe > that some animal instance (such as animals caught in my trap) has > the property of being a member of some species (e.g. “Homo Sapiens” ) > on the basis of class membership --Why not? Why should we prohibit > that property being observed? > > So this is a really strong reason why we should stick to “Property” > surely! If “Observable property” in this ISO vocab means anything at > all then it must be distinc t from the union “Property” and so > “Property” is what we need! > > I really dislike subclass alignments….and I dislike equivalentclass > almost as much, wherever they actually sit. I way prefer using the > same terms throughout, > > Which I tried to show in my proposal. > > Just catching up here so maybe I missed something. > > Thoughts? > > -Kerry > > *From:*Armin Haller > *Sent:* Tuesday, 7 February 2017 11:49 AM > *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Maxime Lefrançois > <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>>; > Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; Kerry Taylor > <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > The sub-class relation would only be introduced in SSN not SOSA. I > should have been more explicit in the second dot-point. The third > dot-point means to say that. > > *From: *Krzysztof Janowicz <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> > *Reply-To: *"janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>" > <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> > *Date: *Tuesday, 7 February 2017 at 11:44 am > *To: *Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>, Maxime Lefrançois > <maxime.lefrancois@emse.fr <mailto:maxime.lefrancois@emse.fr>>, > "Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>>, Kerry Taylor <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>>, "public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org>> > *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > Not sure, whether I am fully understanding this. > > -ObservableProperty is a subclass of ssn:Property > > > This would violate one of our design principles, namely that SOSA does > not make use of SSN. > > > On 02/06/2017 04:41 PM, Armin Haller wrote: > > It looks like we have a proposal here to resolve issue 87: > https://www.w3.org/2015/spatial/track/issues/87 > > Please let me try to restate what was proposed: > > -ObservableProperty is introduced in SOSA (as is currently > implemented in: > https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl) > > -ObservableProperty is a subclass of ssn:Property > > -ObservableProperty is introduced in SSN as well and the subclass > relation to ssn:Property is stated within > > That leaves the door open to have another property in SSN (and) > SOSA concerned with ActuableProperties. > > This should also mean that SSN instances are SOSA instances, since > no axioms in SOSA are violated. > > Is my understanding correct? > > *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr> > <mailto:maxime.lefrancois@emse.fr> > *Date: *Tuesday, 7 February 2017 at 10:14 am > *To: *"Simon.Cox@csiro.au" <mailto:Simon.Cox@csiro.au> > <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>, > "janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu> <janowicz@ucsb.edu> > <mailto:janowicz@ucsb.edu>, Kerry Taylor <kerry.taylor@anu.edu.au> > <mailto:kerry.taylor@anu.edu.au>, "public-sdw-wg@w3.org" > <mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org> > <mailto:public-sdw-wg@w3.org> > *Subject: *Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > *Resent-From: *<public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org> > *Resent-Date: *Tuesday, 7 February 2017 at 10:15 am > > Yes indeed, this is what I meant. Thanks. > > Le lun. 6 févr. 2017 à 23:50, <Simon.Cox@csiro.au> > <mailto:Simon.Cox@csiro.au> a écrit : > > Øit appears very strange to me to state that a ssn:property is > a sub property of a sosa:ObservableProperty > > ØThis is what can be read at [1] > > Assuming you mean “it appears very strange to me to state that > a ssn:Property is a sub class of a sosa:ObservableProperty” > then I agree.That looks like my error. > > Simon > > *From:*Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr > <mailto:maxime.lefrancois@emse.fr>] > *Sent:* Monday, 6 February, 2017 17:55 > *To:* janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Cox, Simon > (L&W, Clayton) <Simon.Cox@csiro.au> > <mailto:Simon.Cox@csiro.au>; kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org > <mailto:public-sdw-wg@w3.org> > > > *Subject:* Re: Proposals (was Re: Architecture of SOSA/SSN > integration) : issue-87 only > > ØAnd it appears very strange to me to state that an > observable property is a sub property of a property. > > That was a slip of the tongue, I meant: > > it appears very strange to me to state that a ssn:property > is a sub property of a sosa:ObservableProperty > > This is what can be read at [1] and is also what I would model > when Phil says: > > >>> 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. > > [1] - > https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/ssn-sosa.ttl > > but anyways, +1 in favour of your arguments, and I propose that: > > - we update sosa-ssn.ttl to reflect what we all agree on; > > - we also consider either to add sosa:ActuableProperty, or > roll back to just sosa:Property. > > Kind regards, > > Maxime > > Not strange actually – not all properties are > observable. In the revision of ISO 19109:2015 we > distinguished between > > -Observation > > -Assertion (e.g. name, price) > > -Derivation (e.g. classifications based on > combinations of observed properties) > > -Inheritance/instantiation (e.g. where a property > value is assumed on the basis of class membership) > > These are not necessarily disjoint, and it is likely > that observable properties are the most interesting > (depending on you epistemological viewpoint) but it is > useful to recognize that observable properties are a > distinct class. > > Yes, not strange at all. I agree with all of Simon's > arguments and we also made them in one of our telco's half > a year ago. > > > > > On 02/05/2017 04:57 PM, Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au> wrote: > > ØAnd it appears very strange to me to state that an > observable property is a sub property of a property. > > Not strange actually – not all properties are > observable. In the revision of ISO 19109:2015 we > distinguished between > > -Observation > > -Assertion (e.g. name, price) > > -Derivation (e.g. classifications based on > combinations of observed properties) > > -Inheritance/instantiation (e.g. where a property > value is assumed on the basis of class membership) > > These are not necessarily disjoint, and it is likely > that observable properties are the most interesting > (depending on you epistemological viewpoint) but it is > useful to recognize that observable properties are a > distinct class. > > Simon > > *From:*Maxime Lefrançois > [mailto:maxime.lefrancois@emse.fr] > *Sent:* Monday, 6 February, 2017 00:22 > *To:* Kerry Taylor <kerry.taylor@anu.edu.au> > <mailto:kerry.taylor@anu.edu.au>; SDW WG Public List > <public-sdw-wg@w3.org> <mailto:public-sdw-wg@w3.org> > *Subject:* Re: Proposals (was Re: Architecture of > SOSA/SSN integration) : issue-87 only > > +1 for Kerry's arguments. > > And it appears very strange to me to state that an > observable property is a sub property of a property. > > I just changed to sosa:Property instead of > sosa:ObservableProperty in the proposal I am currently > working on. > > + add relations and classes that are missing > > best, > > Maximle > > Le dim. 5 févr. 2017 à 13:44, Kerry Taylor > <kerry.taylor@anu.edu.au > <mailto:kerry.taylor@anu.edu.au>> a écrit : > > PhilA has said > > >>> 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. > > This is issue-87. As you can see by my analysis > last November in the tracker > https://www.w3.org/2015/spatial/track/issues/87 , > > (1). A sosa: Observable Property is NOT an O&M > property. The O&M standard has no such term. > > (2) The ssn:Property has the same intended > meaning as an an O&M Property (and, yes it is an > O&M “Property”) and this is explicit by the > annotation within ssn“<dc:source> skos:exactMatch > 'property' [O&M] > http://www.opengeospatial.org/standards/om > </dc:source>” > > (3) What is shown in the mapping table is not the > complete annotation for ssn:Property – just an > extract. However that very paragraph deserves > improvement. > > (4) ssn:Property is used in other places > throughout ssn that have nothing to do with the > narrow context associated with Observation as it > is used in SOSA. > > In particular, nothing to do with a > > (5) ssn:Property cannot be deleted --- many, many > things will break. Nor can it be replaced by > sosa:ObservableProperty (see 4). Maybe it is > possible to say sosa:Property rdfs:SubclassOf > ssn:Property but this has its problems too (ssn > instances would not be sosa instances). A more > sophisticated workaround is required if we head > that direction. > > (6) ssn users know it as “Property” . So do O&M > users. Why change, who are we serving? > > (6) OTOH a simple name change in sosa to > “Property” and some clarification on the > rdfs:comments in both places would work – and then > ssn and sosa can use the very same term. This is > the essence of my proposal on the wiki as a > pattern to solve all these many problems. > https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017 > > In this case the rdfs:comment suggested by Armin > looks very close but I prefer abbreviated as > follows (due to (4) ) “An observable quality of a > real world phenomena (thing, person, event, etc.) > “ or here is another idea that I propose “An > observable quality of a real world phenomena > (object, person, or event), typically a > FeatureOfInterest” . That works well in the > context for my proposal that also shows how to use > it in the simple core. > > -Kerry > > Dr Kerry Taylor > > Associate Professor (Data Science) > > Research School of Computer Science > > ANU College of Engineering and Computer Science > > Canberra ACT 2601 Australia > > +61 2 6125 8560 <tel:+61%202%206125%208560> > > -- > > 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 <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 Tuesday, 7 February 2017 22:23:01 UTC