RE: Proposals (was Re: Architecture of SOSA/SSN integration) : issue-87 only: FIRM PROPOSAL

Sorry, missed this. I mean data ie instances recorded wrt the old ssn.  The alignment should be such that, with a reasoner, that data is translated to new ssn (and instances of old ssn concepts can then be deleted if desired).


Ø  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.

“many”? For example? I can only think of very few – but perhaps this depends on what you want kept in mind. Can you kindly explain please?
-Kerry

From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Wednesday, 8 February 2017 9:22 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; Simon.Cox@csiro.au; Armin Haller <armin.haller@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

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> [mailto:Simon.Cox@csiro.au]
Sent: Wednesday, 8 February 2017 8:09 AM
To: Armin Haller <armin.haller@anu.edu.au><mailto:armin.haller@anu.edu.au>; Kerry Taylor <kerry.taylor@anu.edu.au><mailto:kerry.taylor@anu.edu.au>; rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; maxime.lefrancois@emse.fr<mailto: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#Property for 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<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net