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