See also: IRC log
<trackbot> Date: 24 June 2015
<phila> I'll find it. And I'll add it to the wiki - no reason to keep it secret
<phila> I think the host key is 870267
<Kerry> yes, saw that, thks
<Kerry> chaals regret just arrived in email now
<eparsons> Having probs with webex will get there
<Kerry> lets begin
<Kerry> scribe+ mattperry
<Kerry> scribe: mattperry
scribenick MattPerry
<Frans> +1
<ChrisLittle> +1
<Kerry> http://www.w3.org/2015/06/17-sdw-minutes.html
<Linda> +1
<Kerry> +1
<LarsG> +1
proposed: approve last week's minutes
+1
<Kerry> +1
<Alejandro_Llaves> +1
resolved: approve last week's minutes
<Kerry> http://www.w3.org/2015/spatial/track/issues/10
Frans: Issue was mentioned in the
agenda
... about CRS requirements
... CRS needs to have a URI
... there should be a standard about CRS, which includes
non-geographic CRS too
<Frans> current CRS req proposal: "There should be a standard for publishing data about coordinate reference systems (CRS). It should be applicable to any 2D or 3D CRS, not only geographical reference systems. CRS descriptions should be referencable by HTTP URIs."
<ChrisLittle> Does CRS Description mean machinable?
Frans: there has been plenty of disucssion on the email list
ChrisLittle: did you intend human readable or machine processable
Frans: both
... if we are talking about data on the web, the intended
consumer is both humans and machines. Maybe this should be
clearer
Kerry: I like the way the
requirement is phrased and I would support it as is
... I think it would be a mistake to rush to machine
processable.
... I think CRS should be explicit not depend on a
default
... I would reject a requirement for a default
Frans: a default CRS is a separate requirement. We should raise an issue for this requirement
Kerry: agreed
<eparsons> Sorry.. took a while to get online
Alejandro_Llaves: Frans mentioned different requirements related to this issue. We may need to modify those requirements
ChrisLittle: I agree with the wording of the CRS requirement, and I would support a default CRS
<eparsons> +1 to default CRS
<Alejandro_Llaves> +1
<Linda> +1 to default CRS
<eparsons> WGS84 is de facto default ?
Kerry: default CRS is a separate issue
Frans: this is a separate requirement at the moment
<Alejandro_Llaves> I was also asking about the phrasing of the requirement. When a requirement ask for a "standard for publishing data...", does it mean a standard way of publishing data or a standard specification for publishing data?
<Kerry> Issue: that a default crs is a requirement
<trackbot> Created ISSUE-28 - That a default crs is a requirement. Please complete additional details at <http://www.w3.org/2015/spatial/track/issues/28/edit>.
<ChrisLittle> +1
For the record, +1 for default CRS as WGS84 long-lat
<Alejandro_Llaves> +q
<Alejandro_Llaves> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMetadata
Alejandro_Llaves: Frans proposes to add new requirement to best practices deliverable on Spatial Metadata
Frans: I think we should link
these requirements
... Spatial Metadata requirement says we should include CRS
info, CRS requirement says how to do it
... we can add a note to the Spatial Metadata requirement to
other relevant requirements
Alejandro_Llaves: sounds good to me
Frans: maybe we should move discussion to the email list
Kerry: It would be nice to conclude this discussion today
Frans: the word standard appears in many requirements, this is a broader issue
<eparsons> +1
<Zakim> AndreaPerego, you wanted to ask what we mean with "standard" - e.g., is it format-related?
<LarsG> +1
Alejandro_Llaves: what I see in the tracker is best "phrasing" for CRS requirements
AndreaPerego: My question is general. Are we saying we need an RDF standard way to represent information. We already have many standard ways to represent CRS info
Kerry: I agree about that confusion. My take is to say "a way" to publish info on CRS
<Alejandro_Llaves> +1
Kerry: and this should include
HTTP URIs, RDF is not critical
... We need to indentify the CRS, but not really how to
describe it
AndreaPerego: I think that HTTP
URI is key. The thing that is important is ability to retrieve
the CRS description in the format you want.
... what is missing is that some applications may need an RDF
representation
... if there is not one, maybe we should define it
Frans: the current phrasing
doesn't say exactly what needs to be expressed
... want to get back to the use of the word standard
... how about there should be a "best practice"?
<Kerry> +1 to best practice
Frans: best practice implies one preferred way
<ChrisLittle> +1 to best practice
<AndreaPerego> Just to note that we have already examples of CRS description in multiple formats - e.g., see http://spatialreference.org/ref/epsg/wgs-84/ and http://epsg.io/4326
+1 to best practice
<Linda> +1
<AndreaPerego> +1 to BP
<LarsG> +1 to best practice
eparsons: I agree with Frans' point. Requirements are just identifying the problems, not providing a solution. That is for best practice deliverable.
Alejandro_Llaves: I totally agree with Ed
<Frans> Agree with Ed: we need so separate requirements and possible solutions
Alejandro_Llaves: solution does
not belong in the requirement
... I would avoid mentioning "standard" or "Best practice" in
the requirement
<ChrisLittle> "Data must be published ..."
Kerry: I like Chris' wording
<Kerry> +1 to Chris
Frans: this changes the meaning of the requirement: you are wrong if you do not publish it
eparsons: maybe we're saying it
should be a default or point to a definition?
... I'm strongly behind it should be default or something
else
Frans: I can live with "a way"
Kerry: that suits me
Linda: I don't really like "a way"
MattPerry: I agree with Linda
<Linda> "a recommended way"?
ChrisLittle: "a way" is a bit too
sloppy
... "best practice" or "should be published"
<Alejandro_Llaves> "Spatial metadata shall include CRS metadata"
<Frans> I think the should is not being questioned
<ChrisLittle> +
<ChrisLittle> 1 alej
<eparsons> +1 should
ChrisLittle: lets stick with "should"
<LarsG> "shall" is too strong (equal to "must") -> "should"
BartvanLeeuwen: can we have a written out proposal so we can see the whole thing
<Kerry> http://www.w3.org/2015/spatial/track/issues/10
<Frans> I would propose: "There should be a best practice for publishing data about coordinate reference systems (CRS). It should be applicable to any 2D or 3D CRS, not only geographical reference systems. CRS descriptions should be referencable by HTTP URIs."
Alejandro_Llaves: "best practice"
could be considered a solution. This is about
requirements.
... I can live with "best practice" though
eparsons: I agree. Can we just
change the "shall" to "should"?
... my concern is that Frans' propsal is already solving the
problem
<ChrisLittle> bacak to "Data should be published about ..."
<Kerry> ac lars
<Linda> +1 Ed, i.e. the requirement is to be able to reference a CRS with a URI, and to get useful information about the CRS when you dereference that URI.
LarsG: I see Ed's point. If we have coordinates, we need to know what they mean, so we need to link to the CRS.
<AndreaPerego> +1 to Ed also from me
Kerry: I don't think Frans' proposal is a solution
<Alejandro_Llaves> Proposal: "Spatial metadata should include coordinate reference system (CRS) metadata. It should be applicable to any 2D or 3D CRS, not only geographical reference systems. CRS descriptions should be referencable by HTTP URIs."
eparsons: one solution could be a default. Frans' proposal implies too much of a solution
Kerry: whether or not we have a default, we need to refer to a CRS
<Alejandro_Llaves> Spatial data*, sorry!
Kerry: I'm happy with
Alejandro_Llaves' propsal as well
... does anyone disagree with that one?
eparsons: it still sounds like a solution
Kerry: I disagree ed
... implicit or explicit is a separate point
eparsons: We do need to solve the implicit / explicit issue
Kerry: we do, but that is a separate issue
<LarsG> Proposal (piggybacking on Alejandro): "Spatial data must contain a reference to the CRS used. [...]"
Kerry: let's put this to a vote
LarsG: This one doesn't say if it's implicit or explicit
<Alejandro_Llaves> I'm happy with Lars' proposal
<ChrisLittle> +1 Frans
<Frans> "There should be a best practice for publishing data about coordinate reference systems (CRS). It should be applicable to any 2D or 3D CRS, not only geographical reference systems. CRS descriptions should be referencable by HTTP URIs."
<Kerry> +1
<Frans> How can we improve recording?
BartvanLeeuwen: I have an issue that this doesn't refer to the data
<Frans> Thanks Bart
<Frans> PROPOSED: "There should be a best practice for publishing data about coordinate reference systems (CRS). It should be applicable to any 2D or 3D CRS, not only geographical reference systems. CRS descriptions should be referencable by HTTP URIs."
<Kerry> +1
Kerry: I think we're going to have to give up on this one
<ChrisLittle> open issue
Issue 10 is not RESOLVED
<phila> trackbot, open issue-10
<trackbot> Sorry, phila, I don't understand 'trackbot, open issue-10'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<Kerry> https://www.w3.org/2015/spatial/wiki/Notes_for_Context
Kerry: please have a look at this link, which shows info about best practices document
<ChrisLittle> bye and thanks
<LarsG> Thanks Kerry
<BartvanLeeuwen> thx kerry
<Alejandro_Llaves> thanks, bye!
<AndreaPerego> Thanks, bye!
<BartvanLeeuwen> and frans
bye
<eparsons> bye !
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/should/must/ Succeeded: s/whould/whole/ Succeeded: s/it sill/it still/ Found Scribe: mattperry Inferring ScribeNick: MattPerry Present: kerry PhilA (IRC only) LarsG Frans Linda Alejandro_Llaves MattPerry AndreaPerego BartvanLeeuwen eparsons Regrets: Andreas_H. Rachel_Heaven Clemens_Portele Bill_Roberts Jeremy_Tandy Philippe_Thiran Chaals Simon_Cox Cory_Henson Josh Antoine Zimmermann Found Date: 24 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/24-sdw-minutes.html People with action items:[End of scribe.perl diagnostic output]