Re: Some errors in the discussion of SSN

I think I was scribing at this point - which was a struggle as I am less 
familiar with the issues than I'd like to be. It is very likely that I 
mis-recorded some of the conversation. One of the advantages of using 
IRC is that anyone can (and is explicitly encouraged to) make 
corrections. Use the regular expression syntax to do this

s/wrong text/correct text/

You can add regex modifiers like g (global) i (case insensitive).

But that only works during the meeting. If there are errors in the 
minutes from Lisbon, please let me know and I'll correct them.

Phil.

On 28/09/2016 16:06, Kerry Taylor wrote:
> Woops.
>
> Ø  scribe: In PROV an activity can be an entity
> Yep, arose from an effort to seek a simple solution to this problem the night before and failing to check my sources (I used to know prov - it is agent and entity that are not disjoint.... Which of course is irrelevant here).  Thank you for picking this up.
>
>
>
> Ø  > kerry: ... Simon made a proposal to just say they're the same but I don't think that works.
>
> Ø  Must be a misunderstanding here. Rather, I used the PROV alignment to show how they (ssn:Observation and om:Observation) are definitely not the same.
> Yes, mis-scribed. Was actually a lot more complicated than that. "they're the same" meant ActivityofSensing and oml:Observation are the same, as you proposed. The complication arises from the need to populate ActivityofSensing if coming from the ssn:Observation direction (was proposed to be done with rules on our paper, but even  with that there  is still a  failure to populate the relevant properties by following your proposal of equating the various ssn:Observation properties and the corresponding oml:Observation properties). Again more rules or horrible extra assertions would be required.   Summarising, simply  populating  either one of ssn:Observation or oml:Observation  requires a lot of stuff  to get either a reasoner or some direct rdf assertions to populate the other. But when someone observed that ActivityofSensing is not even an ssn: class anyway  that really threw the idea out the window.
>
>
> Ø  I don't think this is a solution. As linked above, in PROV-O (at least) prov:Activity and prov:Entity are disjoint.
> Agreed. Fortunately this idea was roundly rejected. Sometimes group decisions function well.
>
>> OK - I like that resolution of course, though I also acknowledge that there is a case for calling the class 'ActivityOfEstimating' to capture to more general semantics. That should be in the documentation anyway.
>
> Yes it was a good outcome - and (I hope) the consequent dul problems are solvable. Maxime is already onto it.
>
> -1 to the renaming suggestion from me  though. Here ssn deliberately followed  established OGC modelling by the name and properties of that concept. This is not the time to change that imho.
>
> Kerry
>
> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> Sent: Thursday, 22 September 2016 11:54 AM
> To: Kerry Taylor <kerry.taylor@anu.edu.au>
> Cc: public-sdw-wg@w3.org
> Subject: Some errors in the discussion of SSN
>
> Looking at the minutes of the meeting on Tuesday:
> https://www.w3.org/2016/09/20-sdw-minutes.html
>
>
> Ø  scribe: In PROV an activity can be an entity
> Incorrect - there is an axiom in PROV-O that makes them disjoint. See line 37 in https://www.w3.org/ns/prov-o
>
>
> Ø  kerry: ... Simon made a proposal to just say they're the same but I don't think that works.
> Must be a misunderstanding here. Rather, I used the PROV alignment to show how they (ssn:Observation and om:Observation) are definitely not the same.
>
>
> Ø  kerry: ... I want to take advantage of entity and activity not being disjoint
>
> Ø  ...
>
> Ø  kerry: No, I don't see a reason for doing that.
>
> Ø  ... In Prov, it's OK to be an activity and an entity
>
> Ø  ...
>
> Ø  kerry: The do nothing approach is to say that O&M and SSN Observation are the same thing but if you use Prov then you need to recognise that it's both Activity and Entity
> I don't think this is a solution. As linked above, in PROV-O (at least) prov:Activity and prov:Entity are disjoint.
>
> Later -
>
> Ø  RESOLUTION: The ssn:Observation will be redefined as an activity, in line with O&M Observation
> OK - I like that resolution of course, though I also acknowledge that there is a case for calling the class 'ActivityOfEstimating' to capture to more general semantics. That should be in the documentation anyway.
>
> Simon
>
>
> From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> Sent: Monday, 12 September 2016 12:02 PM
> To: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>
> Cc: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
> Subject: Re: fixing ssn
>
> Hi Kerry,
>
> Perhaps all this work was discussed in focus well before you became active in the ssn subgroup.
>
> I was active from the beginning so I remember out discussions. I just wanted to make sure we are not stepping back from our SOSA and modularization ideas/work for the new version of the SSN to be standardized. Thus, it was unclear to me why we would need changes to the old SSN.
>
> Best,
> Krzysztof
>
>
> On 09/11/2016 06:20 PM, Kerry Taylor wrote:
> Krzysztof,
> Perhaps all this work was discussed in focus well before you became active in the ssn subgroup. It was indeed some time ago, ie more than 6 months ago,  but has sat still while the modularity design (yet to be tested by experimentation/implementation) ,   SOSA and IoT issues have been given more attention.
>
> We are tasked to bring SSN to a standard, and to simplify and make it easier to use, especially by modularisation. An early  decision was made to separate dolce, and this was done at that time,  but it became apparent that something had gone wrong as we published it  in our FPWD, so I have done it again here  from scratch (with minor improvement -e.g. new dolce namespace). Given that SSN needs to be broken up (through horizontal and vertical modules, as extensively discussed, but with no resolution on how big/many of these there would be) , it would be very sad and painful  to do that from a base of an SSN now with  unintentional errors in it.   Certainly experimentation is needed, but a clean, common  base is surely a worthwhile thing to have.
>
> Some of these problems (see below) were always there (and that is where I plan to work next, with the group's support).   This was discussed briefly in the last ssn meeting too, but is also on the agenda for the F2F. I hope we can focus there on the next steps for modularisation.
>
> Does that address your concerns?
>
> --Kerry
> From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> Sent: Monday, 12 September 2016 5:16 AM
> To: 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: fixing ssn
>
> Hi Kerry,
>
> I am bit surprised by your message and what exactly it means. How does working on the old SSN align with SOSA and everything else we discussed over the past 6 months?
>
> Best,
> Krzysztof
>
> On 09/11/2016 07:14 AM, Kerry Taylor wrote:
> I have just "fixed"  the dolce removal from ssn. The version we were looking at on webprotege had some errors of uncertain provenance, so I went back to SSN  as it was left by the XG here https://www.w3.org/2005/Incubator/ssn/ssnx/ssn.owl  (more commonly known as http://purl.oclc.org/NET/ssnx/ssn) and removed dolce all over again. I also changed the ssn namespace to the new W3c one, and the dolce one to the new one http://www.ontologydesignpatterns.org/ont/dul/DUL.owl, and added some  annotation comments to reflect this.
>
> We now have, on github, a new folder sdw/ssn/ssn_separated which contains ssn.owl<https://github.com/w3c/sdw/blob/gh-pages/ssn/ssn_separated/ssn.owl> and        dul-alignment.owl<https://github.com/w3c/sdw/blob/gh-pages/ssn/ssn_separated/dul-alignment.owl>   . The latter imports dolce but the former does not.   If you look at the alignment ontology you can see that ssn has lost a few important things that now cannot be said at all and will need to be natively  rebuilt,  in addition to the constraints that dolce gave it.
>
> There are also a good few "bugs" remaining - but these are all original ssn bugs. I am thinking of a few things in annotations (including stuff we already changed in the web-protégé version) and a lot of typos, and at least one place where some class is explicitly subclassed from owl;thing.
>
> I plan to gradually work through those bugs - and will bring to the attention of the list anything that is not either already decided or for which there is some choice about what to do.
>
> If anyone would like to give it a once-over in case I have done something stupid, please do.
>
> --Kerry
>
>
>
>
>
>
> --
>
> 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
>

-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Wednesday, 28 September 2016 20:29:46 UTC