W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

[Minutes SSN] 2017 02 28

From: Phil Archer <phila@w3.org>
Date: Tue, 28 Feb 2017 23:11:01 +0000
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <c791ed43-75de-a0be-4b64-c4becaecc627@w3.org>
The minutes of today's extended SSN call are at
https://www.w3.org/2017/02/28-sdwssn-minutes

Note the fancy new styling by (CSS co-creator) Bert Bos! But we still 
have the ol text snapshot below.

Progress was made...


           Spatial Data on the Web SSN Sub Group Teleconference

28 February 2017

    [2]Agenda [3]IRC log

       [2] https://ww.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170228
       [3] http://ww.w3.org/2017/02/28-sdwssn-irc

Attendees

    Present
           ClausStadler, DanhLePhuoc, Francois, RaulGarciaCastro,
           SefkiKolozali, SimonCox, [webex suddently tells me that
           my OS is not supported], ahaller2, eparsons, kerry,
           mlefranc, phila, roba

    Regrets

    Chair
           Armin

    Scribe
           Francois, Kerry, phila

Contents

      * [4]Meeting Minutes
          1. [5]Approving last meeting's minutes
             https://ww.w3.org/2017/02/21-sdwssn-minutes
          2. [6]Preliminaries
          3. [7]https://ww.w3.org/2015/spatial/wiki/Patent_Call
          4. [8]Proposal for O&M Alignment:
             https://ww.w3.org/2015/spatial/wiki/Alignment_to_O%26M
          5. [9]Use of VOAF:
             https://www.w3.org/2015/spatial/wiki/Voaf_vocabulary
          6. [10]Use of Vann
             https://www.w3.org/2015/spatial/wiki/Vann_vocabulary
          7. [11]add vann:preferredNamespacePrefix and
             vann:preferredNamespaceUri metadata in ssn and sosa
          8. [12]Use of dcterms:rights
             https://www.w3.org/2015/spatial/wiki/Ontology_rights_a
             nd_licence
          9. [13]vUse of HistoryNote
             https://www.w3.org/2015/spatial/wiki/Ontology_versionI
             nfo
         10. [14]Platform proposal
             https://www.w3.org/2015/spatial/wiki/Platform
      * [15]Summary of Action Items
      * [16]Summary of Resolutions

Meeting Minutes

Approving last meeting's minutes
[17]https://ww.w3.org/2017/02/21-sdwssn-minutes

      [17] https://ww.w3.org/2017/02/21-sdwssn-minutes

    <ahaller2> +1

    <SimonCox> +1

    <mlefranc> +1

Preliminaries

    <RaulGarciaCastro> +1

    roba: Did we resolve...?
    … I thought we had an open issue on the integration
    architecture, but it's not on the agenda

    ahaller2: It's on next week's plenary meeting. I'm waiting for
    people to vote on the current options

    <KJanowic> +1

    <roba> +1

    [18]Integration Issue

      [18] https://ww.w3.org/2015/spatial/wiki/Integration_Issue

[19]https://ww.w3.org/2015/spatial/wiki/Patent_Call

      [19] https://ww.w3.org/2015/spatial/wiki/Patent_Call

    No objection to last week's minutes

    [No comment on Patent Call]

Proposal for O&M Alignment:
[20]https://ww.w3.org/2015/spatial/wiki/Alignment_to_O%26M

      [20] https://ww.w3.org/2015/spatial/wiki/Alignment_to_O&M

    ahaller2: Simon has made a proposal.

    SimonCox: Look at the wiki page there - this is text I had put
    into the draft of the spec that people couldn't find so I
    copied it to the wiki
    … 8.1 I propose can be dropped directly into the spec.
    … It proposes SOSA classes and properties being dropped in,
    plus OGC/ISO standard
    … Using those URIs to denate the classes and properties from
    the UML model
    … Intention is not to imply endorsement of the OWL
    implementation
    … It's a convenient naming convention that we voted on last
    time.
    … Only going to be focussed on section 8.1 that I propose is
    made normative
    … Aligns SOSA/SSN with original UML model
    … Laid out as a table
    … Links to an RDF file that encodes this

    SimonCox: I found it useful to ... for the alignment... some
    local classes...
    … That's been on the table for a couple of weeks. Lower half
    suggests alignment to OM Lite
    … That hasn;t had any use AFAIK apart from the paper so it
    shouldn't be normative but might be included as an informative
    annex.

    SimonCox: The graphs are available but I haven't done the
    documenting (scribe missed a bit of that)

    roba: Can you clarify, in 8.1, you have equivClass except for
    Feature of Interest which is sub class. Why?

    SimonCox: This might overlap with some of the discussion we've
    had about the feature Of Interest cf. Spatial Thing
    … My understanding is that when we introduced this, we
    explicitly identified the subclass of all spatial things as @@@
    ?

    roba: Looks a bit weird without a rationale

    ahaller2: We had a discussion earlier about alignment that
    Kerry proposed

    <KJanowic> +1 for DL functional syntax :-)

    <tidoust> Phil: How do you define a subclass? You write in text
    in the spec, then in RDFS in the RDF.

    SimonCox: I created tables that essentially recreate triples

    <tidoust> Phil: I think what you've written there is perfectly
    clear. The rule is to make it clear, which you've done!

    phila: What you've done there is fine
    … HTML needs to be clear (it is) then in the RDF use
    owl:equiavlentClass as you have. Job done

    <roba> agree its clear... as long as we are consistent across
    different alignment docs

    KJanowic: (missed q)

    SimonCox: You're asking about the first 2 alignments

    <ahaller2> KJanowic: asked about the iso19156-om:OM_Process
    … equivalent class
    … sosa:Sensor or sosa-om:ObservationProcedure

    [Discussion between KJanowic and SimonCox on whether alignment
    of @@@ is correct]

    <KJanowic> I suggested a subclass relation for the
    iso19156-om:OM_Process part and asked whether we are all fine
    with iso19156-om:OM_Observation
    … equivalent class
    … sosa:Observation (which I am but it may be controversial)

    DanhLePhuoc: I had a question about the alignment.

    SimonCox: Are you suggesting a warning/caveat?

    <KJanowic> what kind of warning and why?

    DanhLePhuoc: Do you expect there will be a use cases for this
    alignment?

    SimonCox: It's not inconceivable.
    … The OWL implementations of the ISO standard are publicly
    available.
    … The likelihood of them being used in a traditional SemWeb
    reasoning context isn't great as I expect the work we're doing
    here should overtake it.

    <KJanowic> May still be relevant for legacy data

    SimonCox: The interest here is to give ourselves a mechanism to
    denote those classes and properties

    <KJanowic> yes, exactly

    SimonCox: The legacy data, maybe from SOS systems, encoding in
    XML corresponding to the UML??

    DanhLePhuoc: I'm thinking this might be useful for mapping
    legacy data
    … If you do this alignment, you can do this

    <KJanowic> or for transparent proxies

    <ahaller2> DanhLePhuoc: Is proposing to have an example to
    legacy applications

    DanhLePhuoc: Maybe in the BP section, we can show how to bring
    legacy data to the new form

    kerry: Just checking that the discussion is focussed on section
    8.1

    kerry: I note that KJanowic was asking about presentation but I
    note that he was questioning it. Is there something that can be
    added

    <KJanowic> These would be formal axioms anyway, right?

    SimonCox: I can add the word UnionOf in brackets

    kerry: Good, thanks

    <ahaller2> or as proposed earlier DL functional syntax

    kerry: Did you do any formal checks... whether there are any
    problems if you put this in a reasoner together with SOSA? My
    guess is that you don't but has it been done?

    SimonCox: No.

    kerry: Then I think DanhLePhuoc's idea of adding in the caveat
    that this is just about the URIs make sense

    SimonCox: I have a list of 4 mods to do so far.

    KJanowic: Am I right that those ...

    SimonCox: The formal axioms are in the RDF graph

    KJanowic: I think this is very useful, not just for legacy data

    KJanowic: Re the axioms, Rob and I suggest a way of minting our
    own classes and then defining a relation...
    … The fact that they're not resolvable should be OK.

    SimonCox: On the resolvability - we have been in correspondence
    with the TC211 folks and triggered renewed interest.
    … Slight trap in the transfer from Norway to Sweden but I think
    it's worth nagging away. Hopeful of resolution not in weeks but
    in months

    phila: Yep, progress is being made towards best solution so
    worth waiting.

    kerry: Some of this work - which is very good - assumes some
    things that are under discussion, such as the names of some of
    the props and classes

    kerry: If we move to a vote, then I'd like to put a caveat on
    that.

    kerry: Personally, I don't think any of those changes, if they
    happen, won't change things substantially here.

    SimonCox: I worked on the basis of SOSA as it was 3 weeks ago.
    Any changes to SOSA would have knock on effect to naming at
    least, yes.

    SimonCox: For 8.2 - 8.4 I prepared those to show how the
    horizontal and vertical could work. It can go away if you like
    or it cojuld be an annex, which I think would be the right way
    forward

    ahaller2: So you're suggesting 8.1 as normative, 8.2 - 8.4 to
    the annex.

    SimonCox: In the OGC, it's normal to use annexes to give more
    pedagogical examples

    phila: Same at W3C too

    s/Working Group/SSN Sub Group/

    kerry: I am uncomfortable with ... given that OMLite has no
    uses that we know of... I would suggest that we can't afford to
    do this work in this WG

    kerry: We have a lot of work to do around this, so I'd be
    happier for it to be deferred to the proposed follow up group
    (post June

    kerry: For clarity - 8.2 onwards in new Note from new WG. 8.1
    in current doc

    KJanowic: I'd like to point out OBOE ontology which is very
    popular in Earth Sciences

    <SimonCox> OBOE

    KJanowic: having an alignment in an appendix broadens our
    potential audience

    <SimonCox> I'm familiar witOBE

    SimonCox: I can comment on OBOE
    … Alignment won't be so easy

    <KJanowic> sorry for my audio quality: IMHO, we should have
    these alignments in the appendix because they matter and will
    ensure we have a large user base (and that we do the alignment
    and not others)

    SimonCox: I have one between OM Lite and OBOE

    SimonCox: OBOE observations are collections of observations

    <KJanowic> I agree with the problem you mention but this is
    exactly the reason for the alignment

    SimonCox: SInce we don't have a notion of a coherent collection
    in SOSA/SSN, which is how OBOE works, this would be non-trivial

    SimonCox: I could look at it thought

    <KJanowic> e.g. in dataONE

    SimonCox: But I think KJanowic's point is important. OBOE is an
    OWL ontology in wide use in the biodiversity world

    KJanowic: The key issue is as you mentioned. Measurement and
    support etc. This is why we should be doing the alignment. So
    we can point out where we use the same name to mean different
    things.

    <roba> three seperate issues then: values of om-lite alignment,
    need for OBOE, and opportunity to "show how" alignment should
    be done (and if they are to be computable, then we need them to
    follow common mechanisms

    kerry: To stress again, we don't have any descriptive
    documentation, no relation to the UCR etc. I don't dispute its
    usefulness, but I'm not sure we can take it on with so many
    open issues etc.

    kerry: I think the right place for this is an associated thing

    <KJanowic> I do not see this as something new but just as
    stating the relation between our work and others thereby
    enabing interoperability

    kerry: It's good work to be done. It needs attention, but with
    4 months to go, I'm not sure we have time.

    <KJanowic> it should be an appendix

    ahaller2: On that aspect... it seems to me... the text is
    there. If we don't have any objections to the text we have then
    I see no reason not to put it in an annex

    ahaller2: The question is - is there anything that we object to
    in 8.2?

    <KJanowic> imho, ensuring that others can easily use our work
    is very, very important and alignment to common ontologies is
    exactly this

    <KJanowic> OBOE is also widely used

    kerry: Putting that text in there, without more time on those
    other ontologies, and implying that we accept those as part of
    the WG as well, is a strong statement from the WG

    roba: I'm going to agree with everyone.
    … In an ideal world we would have time to test everything. We
    could say that the informative annex gives initial thinking,
    make it clear that it doesn't have the same level of attention
    that the normative bits have.

    KJanowic: You're proposing that 8.1 is normative and the rest
    in a non-normative appendix. We're doing an alignment to Dolce,
    and OBOE is no less important

    KJanowic: We can say that the OBOE piece is not complete

    roba: No one's arguing about normative/non-normative. I am
    proposing that we put a much stronger caveat on the early
    thinking

    <KJanowic> But those 'example' wouldl be in owl, right?

    roba: "Don't use it yet"

    SimonCox: I'm not going to die in the trenches to get the
    OMLite alignment in here. I think OBOE is much more important

    ahaller2: So it sounds like we just incorporate 8.1 for now

    <KJanowic> Sounds good to me

    SimonCox: Yes, but I'll tidy up the other pieces in case we
    want it

    <KJanowic> I would prefer an alignment with a clear statement
    that it is early work to having no alignment at all

    <tidoust> Phil: I hope we'll be much more advanced after the
    upcoming F2F. There might be a way to express the uncertainty
    and so on. I'm a bit hesitant.

    <tidoust> ... We could also publish that as a Note, which can
    contain basically anything that the WG wants to put it in.

    <tidoust> ... Let's try not to throw good work away.

    <tidoust> ... We'll see after the F2F meeting.

    kerry: I'd like to remind us that we have about a dozen other
    bits of related work we could do.
    … There's SefkiKolozali's work on time etc.
    … There is other work that is at least as advanced as this
    … I'd argue that the same process should apply

    <KJanowic> IMHO, this depends on how widely these other
    ontologies are used or what the reasons for inclusion might be.

    kerry: There are many potential bits of work with similar
    status

    <tidoust> Phil: I'm just looking now on the group's home page.
    The way we handle what Kerry just said in other groups is as
    follow: we do need to focus at this stage, only 4 months left!
    The way you do that is to set up a wish list. That wish list
    could help drive the proposed IG as well.

    <roba> wish list is basically what i was proposing..

    <ahaller2> phila: Proposes to setup a wishlist that documents
    semi-mature work that we know we want to do

    SimonCox: Thanks everyone for pointing out the other
    suggestions for alignments.
    … I've found it useful to bring it to the group for discussion
    … others might find the same

    <KJanowic> I am also fine with the wish list if this is the
    minimal compromise we can all agree on.

    kerry: We do already have a wish list
    … recent restructuring may have pushed it down the page

    <mlefranc>
    [21]https://www.w3.org/2015/spatial/wiki/SSN_Wish_List

      [21] https://www.w3.org/2015/spatial/wiki/SSN_Wish_List

    kerry: Things there may not have the same level of maturity
    that Simon's wwork has

    Action: SimonCox to incorporate Section 8.2 into the editors
    draft, incorporating modification discussed today and update
    the wiki in regards to 8.2 - 8.4 to decide later on a way to
    include them, potentially in a note

    <trackbot> Error finding 'SimonCox'. You can review and
    register nicknames at
    <[22]http://www.w3.org/2015/spatial/track/users>.

      [22] http://www.w3.org/2015/spatial/track/users>.

    [23]The WG's Wish List

      [23] https://www.w3.org/2015/spatial/wiki/Wish_List

    <roba> we would need to reference the wish list in the doc I
    guess

    Action: Simon to incorporate Section 8.1 into the editors
    draft, incorporating modification discussed today and update
    the wiki in regards to 8.2 - 8.4 to decide later on a way to
    include them, potentially in a note

    <trackbot> Created ACTION-272 - to incorporate section 8.2 into
    the editors draft, incorporating modification discussed today
    and update the wiki in regards to 8.2 - 8.4 to decide later on
    a way to include them, potentially in a note [on Simon Cox -
    due 2017-03-07].

Use of VOAF: [24]https://www.w3.org/2015/spatial/wiki/Voaf_vocabulary

      [24] https://www.w3.org/2015/spatial/wiki/Voaf_vocabulary

    ahaller2: Use of VOAF in SOSA and/or SSN

    <mlefranc>
    [25]https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/
    0195.html

      [25] 
https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0195.html

    mlefranc: There is a discussion about the possible use of VOAF.

    <ahaller2> mlefranc: Ontology instances are instances of
    owl:Ontology and voaf:Vocabulary.

    mlefranc: We might use VOAF to describe the ontology

    mlefranc: People seemed to like it mostly, also VANN.
    … Which may be another agenda item

    ahaller2: The question is do we include it in SSN, SSN and SOSA
    or not at all.

    <KJanowic> there was also a proposal from roba to include this
    into its own file

    kerry: We had some objection about using it in SOSA

    <ahaller2> PROPOSAL: Put VOAF into SSN to make ontology
    instances voaf:Vocabulary

    +1

    <mlefranc> +1

    <kerry> +1

    <SimonCox> +1

    <ahaller2> +1

    <RaulGarciaCastro> 0

    <KJanowic> 0

    <roba> +1

    <DanhLePhuoc> 0

    Resolved: Put VOAF into SSN to make ontology instances
    voaf:Vocabulary

    KJanowic: Just to recall that ... what was your proposal Rob?

    roba: We could have separate files for any flavour of metadata
    we choose
    … One for DCAT, one for something else. Just a possibility I
    raised, not a concrete proposal.

    <ahaller2> PROPOSAL: Put VOAF into SOSA to make ontology
    instances voaf:Vocabulary

    <mlefranc> +1

    ahaller2: That's part of the integration discussion

    +1

    <ahaller2> +1

    <SimonCox> +1

    <kerry> +1

    <RaulGarciaCastro> 0

    <DanhLePhuoc> 0

    <KJanowic> 0 (if we do so on a case-by-case basis)

    <roba> Agree that provision of multiple flavours of metadata
    can be addresses in integration architecture, then "in SOSA"
    will have a specific implementation implication

    KJanowic: [Garbled]

    Resolved: Put VOAF into SSN to make ontology instances
    voaf:Vocabulary

    <KJanowic> (if we do so on a case-by-case basis) --> if we
    discuss each metadata vocabulary individually

    <Zakim> phila, you wanted to ask the 0 folks why

    <Zakim> RaulGarciaCastro, you wanted to answer Phil

    RaulGarciaCastro: I don't have a clear idea what we're planning
    to annotate.
    … The other properties we have, they're not going to be used,
    no?

    <ahaller2> +1 to RaulGarciaCastro, only stating that SSN/SOSA
    is a VOAF:Vocabulary

    <KJanowic> +1 to Raul

    RaulGarciaCastro: For me it doesn't add much. Anyone will
    entail that an ontology is a vocab

    <KJanowic> I agree with Raul and put myself off the queue

    DanhLePhuoc: For me, I agree with RaulGarciaCastro and I also
    add, I don't see much added value to this property.
    … From a practical POV you're adding more triples for no real
    reason

    DanhLePhuoc: If it doesn't help, why add it?

    <KJanowic> +1 to Danh and also you have to ensure that those
    vocabularies stay and are stable and so on

    <mlefranc>
    [26]https://www.w3.org/2015/spatial/wiki/Make_SSN_reachable_fro
    m_SOSA_using_seeAlso_and_comment

      [26] 
https://www.w3.org/2015/spatial/wiki/Make_SSN_reachable_from_SOSA_using_seeAlso_and_comment

    mlefranc: I understand those points. Asserting that ontologies
    are instances of voaf:vocabulary... points to wiki issue.
    … You could discover that there is an ontology that adds new
    axioms to SOSA

    <KJanowic> But we can also do so with rdfs:seeAlso

    ahaller2: All we just decided was to use VOAF

    [27]LOV

      [27] http://lov.okfn.org/dataset/lov/

    <RaulGarciaCastro> But for getting into LOV you need more than
    just having that triple

    <ahaller2> +1 phila

    phila: If a vocab is not in LOV, I won't find it. End of

    <RaulGarciaCastro> You don’t even need the triple (SSN is
    already there and does not have it)

    KJanowic: I see Phil's point, but how many vocabs are as well
    maintained?

    KJanowic: If you use terms from another ontology, you want to
    know whwo maintains it?

    <Zakim> phila, you wanted to talk about Ian Davies

    zakim close queue

    <KJanowic> But there are also many examples were they are not
    used e.g., in dbpedia, provo-o, and so forth. Again, I am not
    arguing against them but trying to explain the problems that
    people report

    <RaulGarciaCastro> Just stating that the ontology is a
    voaf:Vocabulary doesn’t add much; we could also say that the
    ontology is a prov:Entity, and similarly for many others

    <KJanowic> phila, and you believe that VANN adds something that
    we really need to state?

    <ahaller2> scribe kerry

    <ahaller2> scribenick kerry

    phila: Yes KJanowic

    <roba> back in 5...

Use of Vann [28]https://www.w3.org/2015/spatial/wiki/Vann_vocabulary

      [28] https://www.w3.org/2015/spatial/wiki/Vann_vocabulary

    ahaller2: maxime do you want to intro vann?

    mlefranc: van -- there is some confusion about namespace and
    ontology

add vann:preferredNamespacePrefix and vann:preferredNamespaceUri
metadata in ssn and sosa

    mlefranc: namespace is identified by prefixes and in xml but
    are not part of rdf standard
    … so this is the chance to precice those concepts
    … you have an rdf term that is [missed]\
    … and have at least one instance of an ontology that is defined
    in it
    … so if the file is accessible at some url for instance
    … [scribe not keeping up]
    … vann allows you to define the namespace and url for the
    ontology
    … is widely used
    … same question as for voaf...
    … use in sosa / use in ssn

    ahaller2: question is that a lot of integration prposals use
    namespace same as uri and some different

    <ahaller2> PROPOSAL: add vann:preferredNamespacePrefix and
    vann:preferredNamespaceUri metadata in ssn

    <RaulGarciaCastro> +1

    <phila> +1

    <mlefranc> +1

    <ahaller2> +1

    <KJanowic> 0

    ahaller2: lets vote on ssn first

    +1

    <SimonCox> 0

    <DanhLePhuoc> 0

    <KJanowic> roba is afk for 5 min

    Resolved: add vann:preferredNamespacePrefix and
    vann:preferredNamespaceUri metadata in ssn

    <ahaller2> PROPOSAL: add vann:preferredNamespacePrefix and
    vann:preferredNamespaceUri metadata in SOSA

    <RaulGarciaCastro> +1

    <ahaller2> +1

    <KJanowic> 0

    <phila> +1

    ahaller2: second one is to put it in sosa

    +1

    <mlefranc> +1

    <SimonCox> 0

    <DanhLePhuoc> 0

    Resolved: add vann:preferredNamespacePrefix and
    vann:preferredNamespaceUri metadata in SOSA

    ahaller2: moving on

Use of dcterms:rights
[29]https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence

      [29] https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence

    <roba> back...

    ahaller2: maxime you proposed this

    mlefranc: ther are tow little changes I made
    … updated dcterm:rights --- should we use this?
    … also dcterms: licence do we need this?

    <SimonCox> Aren't rights and license subject to W3C/OGC rules?

    mlefranc: alo want to use titles and descriptions that are
    aligned and reference each other in sosa and ssn

    <SimonCox> ALso need to add OGC license!

    RaulGarciaCastro: I can ask an expert in our group to advise on
    the best way for this
    … whether to link to text or urls for example
    … offering to ask for advice on this

    ahaller2: also need to include ogc in rights

    mlefranc: agreed about ogc, but it is just a matter of doing
    ourself - what is w3c advice on best practice here?

    phila: I think....
    … looking at previous ones and I can't see anything anywhere
    … i can't see any reference to any kind of licence in TR
    namespace docs
    … found one but it is not one of ours...
    … no --- very often there is nothing
    … so examples of bad practice

    mlefranc: so voaf or dcterms or both for licence?

    phila: we separate the doc in TR from the ontology in the
    namespace
    … I can't see an ns document that also has a tr doc that talks
    about licence in namespace doc
    … the tr space doc carries the IPR normally

    ahaller2: so we could leave it out

    phila: that is what I would do

    <ahaller2> PROPOSAL: To include licence statement in the TR
    space only, not in the ontologies

    <mlefranc> 0

    <ahaller2> PROPOSED: To include licence statement in the TR
    space only, not in the ontologies

    -1

    <mlefranc> 0

    <RaulGarciaCastro> -1

    <KJanowic> 0

    <ClausStadler> 0

    <SimonCox> -1

    <roba> 0

    <DanhLePhuoc> 0

    <ahaller2> kerry: terms are well defined, it should go in the
    ontology

    <ahaller2> ... even if it is not a best practice

    kerry: it should go into ontology -- why not?

    RaulGarciaCastro: agrees it should be propoer in ontology

    <ahaller2> PROPOSED: To include licence statement in the SSN
    ontology

    <RaulGarciaCastro> +1

    <KJanowic> 0

    <mlefranc> 0

    <ahaller2> 0

    <DanhLePhuoc> 0

    +1

    <SimonCox> +1

    Resolved: To include licence statement in the SSN ontology

    <ClausStadler> 0

    Action: tidoust to look into whether we can/should add licence
    statement to /ns docs and, if so, which one

    <trackbot> Error finding 'tidoust'. You can review and register
    nicknames at <[30]http://www.w3.org/2015/spatial/track/users>.

      [30] http://www.w3.org/2015/spatial/track/users>.

    <ahaller2> PROPOSED: To include licence statement in the SOSA
    ontology

    <SimonCox> +1

    Action: daoust to look into whether we can/should add licence
    statement to /ns docs and, if so, which one

    <trackbot> Created ACTION-273 - Look into whether we can/should
    add licence statement to /ns docs and, if so, which one [on
    François Daoust - due 2017-03-07].

    <RaulGarciaCastro> +1

    <roba> +1

    <mlefranc> 0

    <KJanowic> 0

    <ahaller2> 0

    +1

    <ClausStadler> 0

    <DanhLePhuoc> 0

    Resolved: To include licence statement in the SOSA ontology

    <RaulGarciaCastro> Sure

    <SimonCox> who is here?

    ahaller2: asking raul to check with colleague for advice on
    best way.

    Action: check with colleague on a way to formalise licenceses
    in ontology

    <trackbot> Error finding 'check'. You can review and register
    nicknames at <[31]http://www.w3.org/2015/spatial/track/users>.

      [31] http://www.w3.org/2015/spatial/track/users>.

    Action: Raul check with colleague on a way to formalise
    licenceses in ontology

    <trackbot> Created ACTION-274 - Check with colleague on a way
    to formalise licenceses in ontology [on Raúl García Castro -
    due 2017-03-07].

    phila: am asking francois to give formal advice and also Scott

    <mlefranc>
    [32]https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_li
    cence

      [32] https://www.w3.org/2015/spatial/wiki/Ontology_rights_and_licence

    mlefranc: i would like you to consider at least a url or what
    text is needed in this advice
    … [might have missed some of that]

vUse of HistoryNote
[33]https://www.w3.org/2015/spatial/wiki/Ontology_versionInfo

      [33] https://www.w3.org/2015/spatial/wiki/Ontology_versionInfo

    ahaller2: maxime to comment?

    mlefranc: again this is just on a triple by triple basis
    … the old ssn used skos;note
    … should this be changed?

    <SimonCox> FWIW - OGC software license is here:
    [34]http://www.opengeospatial.org/ogc/Software

      [34] http://www.opengeospatial.org/ogc/Software

    mlefranc: i tried to work on a triple basis and to decide what
    should be included in sosa, ssn, ssnz to make them look alighed
    … so q is old ssn used skos:note
    … see 3 options on wiki
    … and what *should* we use?

    ahaller2: skos:history note or dc:source or [missed]

    <ahaller2> Option: skos:historyNote dcterms:source
    owl:versionInfo

    <ahaller2> PROPOSE: use skos:historyNote in SSN

    <roba> depends on the content of the note...

    <KJanowic> agree with roba

    ahaller2: yes in ssn dcterms: source is used and sosa uses
    skos: historynote but not for each term

    mlefranc: says we should be consistent
    … depends on content of note

    <RaulGarciaCastro> From the SKOS primer: “”skos:historyNote
    describes significant changes to the meaning or the form of a
    concept:”

    roba: thay are all slighly seprate options and they may all be
    relvant
    … quite nice to have all those things..

    <ahaller2> PROPOSED: dcterms:source for terms in SOSA

    ahaller2: dcterms:source in ssn would stay

    <mlefranc> +1

    <ahaller2> 0

    +1

    <RaulGarciaCastro> +1

    <roba> +1

    <DanhLePhuoc> +1

    <ClausStadler> +1

    <SimonCox> 0

    <KJanowic> 0

    Resolved: dcterms:source for terms in SOSA

    ahaller2: resolved

    <SimonCox> SOSA is lightweight, many influences, how many shall
    we credit?

    <ahaller2> PROPOSED: use skos:historyNote in SSN

    ahaller2: now same question in opposite direction as
    skos:history note is already used in sosa

    <RaulGarciaCastro> -1, it does not seem to be the expected
    usage of the property

    <KJanowic> good point Simon, and my concern as well

    <mlefranc> 0

    <ahaller2> my concern as well to not overload SOSA

    RaulGarciaCastro: use of skos:history note is not as it is
    intended

    <RaulGarciaCastro>
    [35]https://www.w3.org/TR/skos-primer/#secdocumentation

      [35] https://www.w3.org/TR/skos-primer/#secdocumentation

    RaulGarciaCastro: so history note is to describe sig changes to
    meaning or form of term
    … and we are not doing this

    ahaller2: so we should remove from sosa?

    <roba> remove - or rename?

    <ahaller2> PROPOSE: remove skos:historyNote from SOSA

    <phila> +1

    <mlefranc> +1

    <RaulGarciaCastro> +1

    <ahaller2> +1

    <KJanowic> lets not overload sosa

    0

    <DanhLePhuoc> +1

    <ClausStadler> +1

    <SimonCox> +1

    <KJanowic> +1

    <roba> +1

    Resolved: remove skos:historyNote from SOSA

    <SimonCox> There is no history!

    ..now look at version info, maxime?

    <phila> +1 to SimonCox

    <RaulGarciaCastro>
    [36]https://www.w3.org/TR/owl-ref/#versionInfo-def

      [36] https://www.w3.org/TR/owl-ref/#versionInfo-def

    mlefranc: just quickly we are resolving this issue on wiki page
    … we just resolved issue of annotation for every term
    … we could sue dcterms:source for the terms in ssn

    <KJanowic> There is only one historynote in sosa and it points
    to the orginal modularization idea

    <SimonCox> Shouldn't we be dealing with these
    documentation/metadata issues *after* the group has done the
    substantive work. Largely editorial => leave it to the
    editors??

    mlefranc: and as we are now talking about annotating the
    ontology as a whole we should use versionInfo for the ontology
    itself , in both ontologies
    … and agree that skos:historyNote is not the right one

    <ahaller2> PROPOSE: Use owl:versionInfo in SSN

    ahaller2: to clarify we would need a proposal to remove
    dcterms:souirce from ssn and we have not said that -- so it
    stays by default

    <ahaller2> PROPOSED: Use owl:versionInfo in SSN

    <ahaller2> +1

    +1

    <mlefranc> +1

    <RaulGarciaCastro> +1

    <mlefranc> ack

    <roba> +1

    <phila> +1

    <ClausStadler> +1

    <DanhLePhuoc> +1

    <KJanowic> +1

    Resolved: Use owl:versionInfo in SSN

    <SimonCox> +1

    KJanowic: [garbled] nothing to remove
    … i will remove

    SimonCox: concerned we are getting bogged down

    <KJanowic> I agree with Simon, this is what I tried to say

    SimonCox: this is editoral work

    roba: was going to ask for clarification on statemnt that sosa
    is not a version of anything
    … but our charter says it is

    ahaller2: proposes 5 minute break\

    <ahaller2> [5 min] 8:55am

    ahaller2: resume at 5 minute sto the hour

    <ahaller2> [break]

    <RaulGarciaCastro> phila: They are nicer :)

    <mlefranc> * excellent :-)

    <mlefranc> * will we some day have the audio recorded and/or
    machine transcription as part of the minutes ?

    <KJanowic> nice indeed

    <ahaller2> nice! the top looks a bit 90's Web retro style

    <roba> ooh - have we got the licence right in case its a best
    seller?

    <roba> the drama, the tension, the deep characterisation !

Platform proposal [37]https://www.w3.org/2015/spatial/wiki/Platform

      [37] https://www.w3.org/2015/spatial/wiki/Platform

    Armin: Kerry authored a Wiki page where she proposes use of
    Platform and how that would transfer to "sosa"

    Kerry: I see some changes were made to the page, feel free to
    jump in to explain them.
    … I'm proposing to extend SSN to assert that both Sensors and
    Actuators are Systems.
    … I don't think that's controversial although that has not been
    decided.
    … The reason to that is that in SOSA, Sensors can be attached
    to Platforms. In SSN, Sensors are not Systems.
    … The proposal would make it possible to attach Sensors to
    Systems in SOSA
    … That's the key message here

    <ahaller2> KJanowic+

    Kerry: As a side effect of that, Systems are allowed to be
    virtual.
    … I've particularly suggested for SOSA that we use the SSN
    terms for these, because they make more sense, have been around
    for some time, and have been widely used already.

    KJanowic: Thanks for the details, I think we are discussing too
    many things here. I thought it was just a discussion about
    Platform, but this goes way further.
    … [sound chopped, scribe missed point]

    <KJanowic> sorry for the audio, I changes location and can try
    again now

    <KJanowic> the many things in one was a comment to your
    proposal touching on issues of our integration discussion.

    Kerry: This has been on the table for 2-3 months. Platform is
    necessarily introducing a lot of issues because it is a complex
    concept in SSN.
    … The implications of that to SOSA are complex and I can't just
    make that go away.
    … What I've done is my best attempt to make things consistent
    … Issues cannot be dealt with one by one.

    <KJanowic> we already discussed that the definition of sosa and
    ssn platform is not inconsistent

    Kerry: SOSA used the concept of Platform independently of the
    way it's been used in SSN.

    <KJanowic> sorry for my audio kerry, I changed locations now
    and can retry

    Armin: I don't think there's a lot of issue on the table. What
    Kerry is proposing is that Sensors and Actuators can be
    attached to Systems, which seems quite uncontroversial.
    … We can replace @@@ by attachedSystem if necessarily.

    <KJanowic> I see problems with this proposal

    Kerry: There is a bit more than that, to re-work the concept of
    System to make it work in SOSA.
    … It belongs to SSN but it is an extensive issue

    mlefranc: I think what Kerry says is important. There are at
    least 3 votes here.
    … Sensors and Actuators as subclass of ssn:System.

    <KJanowic> yes, many issues here

    mlefranc: Second on the naming.

    <KJanowic> there is no system in sosa so
    "onPlatform/attachedSystem" would be an issue for me

    <KJanowic> also kerry "Please bear with me. In particular I am
    NOT suggesting that sosa:Platform exists at all." I would not
    be happy with removing platform from SOSA

    Kerry: Maybe the separation in 3 issues proposed by Maxime
    could work?

    Armin: Let's give it a try

    <ahaller2> PROPOSED: Actuators and Sensors in SSN are made
    subclass of System

    <mlefranc> +1

    <ahaller2> +1

    <kerry> +1 but note side efects are necessary

    <RaulGarciaCastro> +1, that will help us to align with other
    initiatives (e.g., WoT)

    <KJanowic> So human eyes are systems?

    <SefkiKolozali> +q

    <DanhLePhuoc> +1

    <KJanowic> and systems cann be virtual?

    <mlefranc> yes

    <mlefranc> yes

    Resolved: Actuators and Sensors in SSN are made subclass of
    System

    <ahaller2> Actuator and Sensor class, apologies

    <ahaller2> please ignore the plural

    Sefki: Half question and half statement. If we have many
    sensors, then they will create a System? If so, how do
    Platforms can create Systems?

    <Zakim> kerry, you wanted to answer

    <KJanowic> IMHO, we were supposed to discuss platform here but
    we are discussing systems and many, many other issues here

    Kerry: Sefki raises a very good question. The notion of a
    Platform hosting a system of sensors does not go away.
    … The difference is, if you wanted to go to a Sensor, since a
    Sensor was not a System, you went through the Device level.
    That was a way of putting a sensing device as part of a
    platform.
    … This was done with a somewhat more complex mechanism.
    … You can still do that, that does not go away.

    <SimonCox> what is the functional role of 'System' - is it (a)
    collections; (b) indirection?

    Kerry: If you have a SOSA sensor which is on a Platform, this
    can be done directly because a sensor is a system in SOSA,
    which can be part of a Platform.

    <KJanowic> again, keep in mind that sosa has no System class

    <SimonCox> 'system' is such a generic term, appears in lots of
    other places, need to be careful about allowing conclusions to
    be jumped to ...

    Kerry: This is a generalization of SSN. It's not really
    necessary in SSN, but needed for SOSA.

    <ahaller2> PROPSOED: There is a property in SSN that allows
    Sensors or Actuators to be “attached” to a Platform, pending a
    decision on the name

    <mlefranc> +1

    <SimonCox> +1

    <KJanowic> +1

    <kerry> +1

    <ahaller2> +1

    <RaulGarciaCastro> +1

    <KJanowic> (and we have this in sosa)

    <ClausStadler> +1

    <DanhLePhuoc> +1

    <mlefranc> via the System class ?

    Armin: Related to that, there needs to be a property in SSN to
    attach Sensors and Actuators to a Platform.

    <SefkiKolozali> +1

    Kerry: Right, it is a necessary consequence.

    <KJanowic> +1

    Resolved: There is a property in SSN that allows Sensors or
    Actuators to be “attached” to a Platform, pending a decision on
    the name

    <mlefranc> then -1

    <KJanowic> This “attached” relation is already in SOSA

    <RaulGarciaCastro> -1 if we are not going to use the existing
    properties

    <KJanowic> +1 to maxime

    <RaulGarciaCastro> for what mlefranc is saying

    <kerry> agreed with Maxime -- that is right

    mlefranc: Let's say we choose sosa:isHostedBy and sosa:hosts, I
    don't see a problem in SSN, because in SOSA, rangeIncludes will
    do what we want. sosa:hosts can link systems and platforms in
    SSN.

    <KJanowic> so we can keep what we have

    Armin: We did not decide on the actual name.

    <kerry> +1 to maxime -- that is to mirror this change for
    sensors and platforms

    <RaulGarciaCastro> But the property should go from System, not
    from Sensor and Actuator

    mlefranc: I feared that there could be multipled properties for
    sensors and actuators

    KJanowic: As Maxime just said, we already have sosa properties
    that we could use directly.
    … The only thing that I would object is if we would remove
    those and introduce a system concept in sosa.

    Armin: Right, no one suggests that.

    <KJanowic> We have all we need for that in sosa sosa:hostedBy
    and sosa:hosts . This relates sensors and actuators to
    platforms. We also do not have a system concept in sosa. We can
    easily reuse the sosa properties in ssn.

    Sefki: My point is with systems of systems, common in IoT,
    clusters of sensors. Can we do that with this proposal?

    <kerry> sefki, you can do that but only with ssn, not in sosa,
    under this proposal

    Armin: Yes, multiple sensors can still be connected to multiple
    systems. No change there.

    <KJanowic> hosted by attaches a sensor/actuator to a platform

    Maxime: Is it true that in this form a Platform is the name of
    a role. Isn't hostedBy another way to say that a system is a
    sub-system of another system?

    <Zakim> kerry, you wanted to respond to sefki and to repond to
    maxime

    Maxime: I'm questioning how different this is from a system
    being hosted by a platform. The bigger system could be the
    platform.

    Kerry: I actually think you're right that this is a confusion
    that arises from this proposal.

    <KJanowic> I see your point sefki

    Kerry: I could not find a way to clarify that and provide
    directions. I tried but could not really solve that. I thought
    it just better to leave it open.
    … The concept of a platform was a "ship" or a "buoy", with
    different systems, composed of sensors and actuators.
    … I do not think we can be more specific here.

    <SimonCox> SensorML terminology is very closely linked to some
    specific sensor scenarios, particularly ships, satellites,
    UAVs, aircraft - big platforms which carry complex systems.

    <ahaller2> [38]https://www.w3.org/2015/spatial/track/issues/85

      [38] https://www.w3.org/2015/spatial/track/issues/85

    Kerry: Your phone could be a system of sensors, and the
    platform may end up being the same thing in that case, but
    there's no real problem with that.

    <KJanowic> why would platform have to by physical?

    <SimonCox> It does not necessarily carry over to other
    scenarios. The scope of SOSA is arguably more
    general/relaxed/permissive than SensorML.

    Armin: Can you remind us of the resolution on issue 85? Isn't
    that about the question of having systems part of other
    systems?

    <SimonCox> tidoust: "buoy" not "buoy"

    Kerry: No. In this proposal, a system is composed of
    subsystems, some of these subsystems will be sensors. In the
    previous SSN, a system was composed of subsystems, and
    subsystems were composed of sensors.

    KJanowic: Again, I think we are trying way too many things
    here. In many cases, you do not need a system or a platform.
    The typical example for me for a platform is if you have
    multiple sensors and you want to keep track of the positions of
    the relative sensors.
    … (cameras example)

    Maxime: If I understand well what Kerry is suggesting, you can
    have systems that are not platforms, systems that are also
    platforms, systems that belong to platforms. That's fine with
    me.
    … [scribe missed comment on onPlatform]

    <KJanowic> so how would systems that are not platforms differ
    from systems that are platforms?

    Rob: Can someone clarify whether we're talking about types of
    platforms or instances of platforms?

    <Zakim> SimonCox, you wanted to comment on scope of SensorML
    and why it might not be an ideal or complete precedent

    <ClausStadler> I think the question can be rephrased as whether
    a concrete system or its architecture is being modeled?

    Simon: Kerry's doing a very good job at reminding us to look at
    precedents.
    … SensorML was such a precedent.
    … We need to be a little bit mindful as to where SensorML came
    from. The idea of systems mounted of platforms was very strong
    in that community.

    <KJanowic> +1 to what Simon said

    Simon: When we're moving to other types of systems/platforms,
    the language changes a little and the precedent in SensorML may
    no longer be very useful.
    … I'm also concerned about the word System itself which is a
    very generic term.

    <Zakim> kerry, you wanted to answer roba

    Simon: I'm guess I'd like to call for caution when copying
    SensorML ideas.

    Kerry: We still have that use case for SSN that hasn't gone
    away, around observations. Still around for coverage work in
    this group.
    … Scientific observations in HIPS.
    … Also, for me that's the only way to make sosa work.
    Alternatives would move heavy-weight.
    … The use case that supports the purpose of the Platform
    concept is still there.

    <roba> no one has yet answered whether its types, instances or
    both?

    <KJanowic> why can't it be used in ssn directly?

    <mlefranc> @Rob, if in OWL, object properties always link
    instances

    Armin: I think there is just one issue here. In sosa, people
    want a generic term to attach a sensor to a system or platform.
    It cannot include "platform" because that would make it hard to
    use in SSN to attach to systems and not platforms.
    … attachs/attachedBy perhaps.
    … Trying to find a compromise here.

    <roba> no RDF instances, tpyes of devices vs deployments...

    <mlefranc> @Rob, you can talk more generally about classes, by
    using subClassOf some restriction

    Kjanowic: To follow-up on SensorML, it's important to
    understand differences. We already took different decisions in
    the past.

    <ahaller2> ahaller: we need a generic property in SOSA, e.g.
    hosts/hostedBy or attached/attachedBy and more specific ones
    that could be a sub-property in SSN, e.g.
    onPlatform/attachedSystem

    <Zakim> kerry, you wanted to say that is not the choice

    <ahaller2> [39]https://www.w3.org/2015/spatial/wiki/Platform

      [39] https://www.w3.org/2015/spatial/wiki/Platform

    <KJanowic> The page, for instance, states that " In particular
    I am NOT suggesting that sosa:Platform exists at all"

    Armin: I don't think we have a disagreement on the Platform
    class

    Kerry: Maybe I need to summarize the page again. This assumes
    that sosa has a Platform class. Maybe I got that wrong but I
    don't think so.
    … A sensor can be hostedBy/attachedTo a platform, and that can
    work equally well in sosa and ssn.

    <SimonCox> OK - thanks Kerry - that helped.

    Kerry: We could separate what that property and inverse
    property names are, but that property can be used in both sosa
    and ssn, to attach to systems and platforms.

    <mlefranc> @Armin, that's exactly what I wanted to say, let's
    just choose the names

    <mlefranc> proposing hosts/isHostedBy,

    Armin: Right, I think the last question is just around the
    names of the properties.

    <KJanowic> System does not exist in SOSA so attachedSystem
    would be an issue but what about subroles?

    Armin: I'm not sure if we can resolve this today or if we need
    more property names.

    Maxime: I think the core issue is how to integrate sosa with
    ssn. hosts/hostedBy, onPlatform/attachedSystem.

    <KJanowic> I agree with Maxime

    Maxime: Maybe we can just choose the name, and see the
    implications on SSN.

    <Zakim> kerry, you wanted to say how it is modelled in ssn

    KJanowic: given sosa does not have system, so we can keep
    hosts/hostedBy and create subproperties as needed?

    <KJanowic> yes!

    <KJanowic> so everything is fine. we are in violent agreement

    Kerry: It's even simpler than that, the same property names can
    be reused in both ontologies
    … This is what adjusting the definition of system gives us.

    <KJanowic> yes!

    <mlefranc> PRO POSAL replace URI of ssn:onPlatform in SSN by
    sosa:isHostedBy

    <ahaller2> yes!

    <SimonCox> Violent agreement?

    <KJanowic> so can we vote on hosts/hostedBy?

    Armin: On the Wiki, there is an option for onPlatform and
    attachedSystem, and my feeling is that the group thinks these
    are not good names because they are not generic enough.

    <KJanowic> we discussed names for weeks and hosts/hostedBy
    turned out to be the most neutral

    <mlefranc> PRO POSAL replace URI of ssn:attachedSystem in SSN
    by sosa:hosts

    <ahaller2> PROPOSED: have a generic property in SOSA that
    allows attaching of Sensors/Actuators to Platforms and name it
    hosts/hostedBy

    <mlefranc> -1

    <SimonCox> +1

    <KJanowic> +1 (we already have this)

    <roba> +1

    <kerry> 0

    <DanhLePhuoc> +1

    <kerry> +1 to maxime's comment

    <ahaller2> PROPOSED: have a generic property in SOSA that
    allows attaching of Sensors/Actuators to Platforms and name it
    hosts/isHostedBy

    <mlefranc> +1

    <SimonCox> +1

    <KJanowic> +1

    <kerry> 0

    Maxime: I just wonder why we don't have "is" here, because we
    have it in other places

    <RaulGarciaCastro> +1

    <ahaller2> +1

    <ClausStadler> +1

    <DanhLePhuoc> +1

    Armin: Fair enough, adjusting the proposal

    <roba> +1

    Resolved: have a generic property in SOSA that allows attaching
    of Sensors/Actuators to Platforms and name it hosts/isHostedBy

    <KJanowic> I can do that change in sosa.ttl

    <SefkiKolozali> +1

    <KJanowic> lets vote on using them directly

    <kerry> please same!

    <mlefranc> +1

    Armin: And now the question is, are we using the same
    properties in SSN or are we using different ones?

    <ahaller2> : have a generic property in SSN that allows
    attaching of Sensors/Actuators to Platforms and Systems and
    name it hosts/isHostedBy

    <mlefranc> +1

    <ahaller2> PROPSOED: have a generic property in SSN that allows
    attaching of Sensors/Actuators to Platforms and Systems and
    name it hosts/isHostedBy

    s|RESOLVED: have a generic property in SSN that allows
    attaching of Sensors/Actuators to Platforms and Systems and
    name it hosts/isHostedBy||

    <ahaller2> +1

    <mlefranc> +1

    <RaulGarciaCastro> -1

    <kerry> +1 but noting consequence has to be those changes to
    system as in proposal on wiki

    <mlefranc> Sensors/Actuators "as subclassof of system" --> to
    platform

    Raul: If sensors and actuators are systems, why do they need to
    be associated with systems?

    <roba> I dont understand whyt we need another one - arent we
    just re-using sosa: properties ?

    <KJanowic> +1 to roba

    Kerry: Before the change, sensors were not systems, but the
    proposal is to say that a sensor is always a system, and as
    such you don't really need to associate them with systems

    <KJanowic> yes, me too

    <KJanowic> ssn uses the sosa properties

    <ahaller2> PROPOSED: have the same property in SSN that allows
    attaching of Sensors/Actuators to Platforms and Systems and
    name it hosts/isHostedBy as defined in SOSA

    <KJanowic> +1

    <mlefranc> +1

    <roba> +1

    <SimonCox> +1

    <kerry> +1

    <ahaller2> +1

    <ClausStadler> +1

    <RaulGarciaCastro> My problem is with the “and Systems”

    <mlefranc> agree with Raul

    Raul: Can we remove the "and systems" from the text?

    <KJanowic> (the systems ) would not be in sosa, so no reason to
    worry. Raul is corect, it is 'automatically'

    Kerry: No.

    <mlefranc> have the same property in SSN that allows attaching
    of Systems to Platforms and name it hosts/isHostedBy

    <RaulGarciaCastro> have the same property in SSN that allows
    attaching of Sensors/Actuators and Systems to Platforms and
    name it hosts/isHostedBy as defined in SOSA

    Kerry: Ah, I see Raul's point, let me rewrite the proposal

    <kerry> ROPOSED: have the same property in SSN that allows
    attaching of Sensors/Actuators/systems to Platforms and name it
    hosts/isHostedBy as defined in SOSA

    <ahaller2> PROPOSED: have the same property in SSN that allows
    attaching of Sensors/Actuators and Systems to Platforms and
    name it hosts/isHostedBy as defined in SOSA

    <RaulGarciaCastro> +1

    <ahaller2> +1

    <mlefranc> +1

    <SefkiKolozali> +1

    <roba> +1

    <ClausStadler> +1

    <KJanowic> +1

    <kerry> +1

    <DanhLePhuoc> +1

    <SimonCox> +1

    <mlefranc> any actions ?

    Resolved: have the same property in SSN that allows attaching
    of Sensors/Actuators and Systems to Platforms and name it
    hosts/isHostedBy as defined in SOSA

    <KJanowic> One tiny issue before we stop

    Action: Kerry to implement the changes we decided on in SSN and
    the DOLCE alignment

    <trackbot> Created ACTION-275 - Implement the changes we
    decided on in ssn and the dolce alignment [on Kerry Taylor -
    due 2017-03-07].

    <KJanowic> Armin, one tiny issue

    <kerry> bye!

    <RaulGarciaCastro> Bye!

    <KJanowic> wait

    <KJanowic> [40]https://www.w3.org/2015/spatial/track/issues/88

      [40] https://www.w3.org/2015/spatial/track/issues/88

    KJanowic: please close issue-88, same as what we discussed.

    <SimonCox> Effectively the action resulting from this vote
    resolves ISSUE-88 ?

    <KJanowic> bye bye

    <RaulGarciaCastro> Bye

    <ahaller2> bye

    Armin: Let's wait for the action implementation and close the
    issue then

Summary of Action Items

     1. [41]SimonCox to incorporate Section 8.2 into the editors
        draft, incorporating modification discussed today and
        update the wiki in regards to 8.2 - 8.4 to decide later on
        a way to include them, potentially in a note
     2. [42]Simon to incorporate Section 8.1 into the editors
        draft, incorporating modification discussed today and
        update the wiki in regards to 8.2 - 8.4 to decide later on
        a way to include them, potentially in a note
     3. [43]tidoust to look into whether we can/should add licence
        statement to /ns docs and, if so, which one
     4. [44]daoust to look into whether we can/should add licence
        statement to /ns docs and, if so, which one
     5. [45]check with colleague on a way to formalise licenceses
        in ontology
     6. [46]Raul check with colleague on a way to formalise
        licenceses in ontology
     7. [47]Kerry to implement the changes we decided on in SSN and
        the DOLCE alignment

Summary of Resolutions

     1. [48]Put VOAF into SSN to make ontology instances
        voaf:Vocabulary
     2. [49]Put VOAF into SSN to make ontology instances
        voaf:Vocabulary
     3. [50]add vann:preferredNamespacePrefix and
        vann:preferredNamespaceUri metadata in ssn
     4. [51]add vann:preferredNamespacePrefix and
        vann:preferredNamespaceUri metadata in SOSA
     5. [52]To include licence statement in the SSN ontology
     6. [53]To include licence statement in the SOSA ontology
     7. [54]dcterms:source for terms in SOSA
     8. [55]remove skos:historyNote from SOSA
     9. [56]Use owl:versionInfo in SSN
    10. [57]Actuators and Sensors in SSN are made subclass of
        System
    11. [58]There is a property in SSN that allows Sensors or
        Actuators to be “attached” to a Platform, pending a
        decision on the name
    12. [59]have a generic property in SOSA that allows attaching
        of Sensors/Actuators to Platforms and name it
        hosts/isHostedBy
    13. [60]have the same property in SSN that allows attaching of
        Sensors/Actuators and Systems to Platforms and name it
        hosts/isHostedBy as defined in SOSA
Received on Tuesday, 28 February 2017 23:11:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 February 2017 23:11:24 UTC