See also: IRC log
This was one of two parallel meetings held so that the WG could divide its work up most efficiently. This one focused on the requirements relevent to the Best Practices document, the other focused on the other deliverables.
<eparsons> Hangout link https://plus.google.com/hangouts/_/event/c4jg7851fkfmo3f9sjm1ck7epe8
<eparsons> Hi Linda - Can you get on Hangouts OK ?
<eparsons> Hi Matt & Ian R U OK with hangouts
<eparsons> Link above
<Ian_Holt> Should be
<MattPerry> Can I dial into a hangout with a phone?
<phila> I'm trying to listen to both conversations - nad it's already impossible
<eparsons> Matt no sorry online only
<MattPerry> Ok. That's not going to work for my current location. I'll have to dial into the other group.
<MattPerry> Bye. I'm going to jump into the other one.
<scribe> scribe: Linda
Ed: preliminarieds
two housekeeping items:
1: email conversations should go via the public mailing list
at least cc
<eparsons> http://www.w3.org/2015/11/TPAC/
2: we are planning the next face to face in Japan, W3C TPAC meeting.
Try to get there
Bart: when will it be definite that we have the f2f there? Because then I can book my plane ticket as prices are rising.
Ed: we'll make the decision in the next week or two.
Phil: It will be either monday/tuesday or thursday/friday
If you go to Sapporo, we'll ask you your preference
<eparsons> https://www.w3.org/2015/spatial/wiki/BP_Requirements
Ed: we'll go quickly through the work we did at the f2f and then go on with the rest of the UC's
thx phil
scribe: created a spreadsheet with requirements. Will go through the list.
Frans are you ok with that approach:
Frans: ok
eparsons: goes through the list
<eparsons> https://www.w3.org/2015/spatial/wiki/BP_Requirements
eparsons: what was the one on validation about?
phila: having difficulty seeing what column we're at.
<phila> -> RDF Data Shapes WG https://www.w3.org/2014/data-shapes/wiki/Main_Page
phila: we have ways of validating xml, no standard for validating rdf. But the data shapes wg is working on it.
<phila> SHACL
-q
eparsons: we are also talking
about whether the geometries are valid
... so two things: valid data and valid geometries
... the one about fuzziness is perhaps the most relevant and
one we've been struggling about
BartvanLeeuwen: re hierarchical
relations between locations: there could also be other spatial
relations. Is that the same thing or a different topic
... administrative connections between features. Example: child
care place on fire, need to place the kids in another daycare
center.
... maybe not the one closest by, but one that is close and
also from the same organization.
... I could put another paragraph in my uc to clarify this.
eparson: or add it to the
requirements doc that Frans is editing.
... if you add the clarification, we'll capture it in the doc.
It's a good requirement.
<eparsons> Hangout link at the top of the irc
eparsons: 3D geometry: just x,y,x
or more complex than that?
... moving on to the reqs not specific to spatial data
... reqs around performance could be difficult
... we went through the first 25 or so use cases
<BartvanLeeuwen> +1
<Ian_Holt> +1
eparsons: I suggest we go through the rest of them now. Everybody clear about the process so far?
+1
<AndreaPerego> +1
scribe: Smart cities 101 use
case
... a lot of information available at the links in the use
case.
... digging through those links seems not helpful now.
BartvanLeeuwen: it links to a 101 different use cases
eparsons: next one. Linked data
for tax assessment.
... provenance of data from authoritative sources
AndreaPerego: a similar issue was discussed in barcelona.
ed: yes I think it was discussed and I think we need to add it.
frans: provenance seems out of
scope
... because it's not typically spatial
eparsons: yes, I suppose. We can
discuss that one.
... next one: Images, e.g. a Time series of a water course
eparsons: the idea of being able
to capture time series of imagery.
... I think we did capture that
... next: droughts in geological complex environments.
eparsons: isn't this modeled environment instead of real world?
AndreaPerego: not clear if this is about spatial data on the web
eparsons: no, it's not clear.
frans: there was a similar thing in the time group
eparsons: we'll move on
... its not that clear to me, Chris can clarify if needed.
<AndreaPerego> Next UC: http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Soil_data_applications_.28Best_practice.2C_SSN.2C_Coverage.29
eparsons: next: Soil data.
Anything specific here?
... noone argues, we'll move on
... next: bushfire response.
<AndreaPerego> http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Bushfire_response_coordination_centre_.28Best_practice.2C_SSN.29
<AndreaPerego> URI issue mentioned here.
eparsons: reads the list of
interrelated use cases.
... not sure if there's anything new. Have we covered
synonyms?
Linda: I don't think so.
eparsons: Frans? can you remember?
frans: no, I can't think of one
eparsons: so we'll need to add it.
AndreaPerego: a related req is
place names can change and people use unofficial names.
... not sure if we can merge these all together. Maybe should
be separate, but are related.
<AndreaPerego> See: https://www.w3.org/2015/spatial/wiki/BP_Requirements#Named_places_can_overlap_and_change_over_time
eparsons: definitely a key requirement
frans: all data on the web can change
eparsons: true, but there are issues that are more complex. Like colloquial geography.
Linda: important for cultural heritage use cases
frans: i remember Chaals made a point of scoping the requirements because we should be careful not to have too much work.
<BartvanLeeuwen> +1
frans: and this is not typically spatial, so out of scope.
<AndreaPerego> Not sure...
<Ian_Holt> +1 Andrea
eparsons: maybe discuss this offline / via email. Maybe not typically spatial but there is a spatial element to the problem. Not convinced we can drop this. Discuss via email.
<AndreaPerego> More discussion needed indeed.
eparsons: will try to come up
with a convincing example.
... next: observation of geological samples
... nothing use here except things for the other group
BartvanLeeuwen: my comment was about the previous question.
eparsons: next: spatial sampling,
Covered by the other group.
... next: Select hierarchical geographical regions. Again the
hierarchy req we were discussing.
eparsons: the changing over time
thing comes up in this uc.
... next one :satellite data processing. More for the other
group.
<AndreaPerego> http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Satellite_data_processing_.28Best_practice.2C_SSN.2C_Coverage.29
eparsons: the ones on marine
observations as well.
... next: BIM. anything new here Linda?
Linda: no, everything covered
eparsons: next: landsat data services
<AndreaPerego> http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Metadata_and_Search_Granularity_.28Best_Practice.2C_Time.29
eparsons: related to level of granularity and URIs. Nothing new, anyone? ?
AndreaPerego: how to make
available spatial data that may be not easily consumable by web
applications.
... depending on granularity you can have huge files.
... a req could be to describe the data in the metadata
... the use case should be described more clearly
eparsons: are you talking about something in the middle between metadata and very finegrained data.
AndreaPerego: yes, exactly.
eparsons: is this a new
requirement?
... lets put this on the email
<AndreaPerego> +1
eparsons: not going to rush through the rest of the uc's. Next week: start with Crowd sourced earthquake observation information, nr 42.
<AndreaPerego> http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Crowd_sourced_earthquake_observation_information_.28Best_Practice.2CSSN.29
eparsons: and will have at least
a couple of email discussions.
... everybody ok with the process?
Linda: this is fine
<AndreaPerego> +1
eparsons: anything else ?thanks everyone for calling.
we'll use Hangout again
bye!
<eparsons> thanks phil !
<BartvanLeeuwen> thx ed bye