<joshlieberman> kerry: François will stand in for Phil this morning
<joshlieberman> roba: assumptions about what SSN is, rather than merits of options for consideration
<joshlieberman> 8 options on the "table" but some look much the same.
<joshlieberman> armin: what are the common issues in the various options
<joshlieberman> roba: difference in interpretation: ssn = axioms for sosa vs ssn - extensions to sosa
<mlefranc> agree with armin
<joshlieberman> kerry: doesn't see confusion as to what ssn "is", hasn't changed during working group, just proposals for factorization.
<joshlieberman> mlefranc: no matter how many namespaces, there will be separate URI redirections for each term. The question is really how many resources the URI's redirecdto to.
<joshlieberman> roba: concern with one namespace and two documents - not very scaleable / extensible.
<ahaller2> ahaller2: just pointing out that we already resolved the slash URI pattern
<joshlieberman> roba: still sees significant difference in viewpoint on ssn
<joshlieberman> mlefranc: scaleability can involve defining new namespaces later
<roba> i agree that specialisatuioin means new terms in the SSn namespace.
<joshlieberman> mlefranc: ssn can comprise various elements that are "in addition" to sosa
<roba> comments have specifically used SSN in term of axiomitsation os SOSA
<joshlieberman> ahaller2: may not be conflicts between views of ssn in options, but the tradeoffs vary between options.
<roba> agree with armin - this is a major limitation other options solve, but otherwise are basically similar
<joshlieberman> joshlieberman: is it wise to mix up "role of ssn" with "role of namespaces"?
<mlefranc> * François, pease louder
<roba> hard to hear - can some please repeat this point?
<joshlieberman> francois: are there useful analogies in other vocabularies?
<roba> we havent found any examples of the "add axioms" pattern - bit loads of "new namespace for specialisation"
<joshlieberman> mlefranc: sosa lean and ssn rich has some analogies in DCAT, but not very successful ones.
<joshlieberman> mlefranc: no w3c recommendation that entwines two vocabularies in quite the same way.
Josh: Being a bit provocative here... This is a mess. 1/ There is this fascination about namespaces. People are fascinated about namespaces before they just want to take the prefix
… We need to separate that issue out.
… How can we come up with prefixes that people will want to use? That's what we should do.
<roba> re an example - kerry's comment on option 8 " we have "sosa:hosts" refined by the axiom sosa:Platform rdfs:subClassOf [ owl:onProperty sosa:attachedSystem ; owl:allValuesFrom ssn:System] which is both typing constraints and uses non-core terms at the same time." This is not axiomitisation - this is specialisation.
Josh: 2/ No one has not developed a vocabulary that adds axioms to an existing vocabulary.
… There is no mechanism to do that. That's why it hasn't been done.
… 3/ Thinking that there's some difference between axiomatization and extension in terms of modularization makes this issue more complex.
<roba> +1 josh
Armin: We combined these questions because no one understood them separately.
… What you seem to propose is option 5.
… We have an extensive set of options that we thought about.
<roba> note option 8 is option 5 with a trick removed (mime type based redirection)
<joshlieberman> ahaller2: feel that the options for combining namespace, axiomitization, and modularization issues are in fact exhaustive.
<joshlieberman> kerry: understand that namespace mechanism is poor fit to modularization goals. PROV does have modularity, but implemented only in documentation. Here trying to separate in separate ontologies using ontology files.
<Zakim> jtandy, you wanted to ask why we don't just follow the PROV model of describing the relationship in documentation
<joshlieberman> jtandy: would documentation approach be valuable for resolving implementation issues with modularity here?
<joshlieberman> ahaller2: goal of some members is for instance of core (SOSA) to also be a valid instance of SSN. some options fulfill this goal and some not.
<Zakim> jtandy, you wanted to ask if the model from RDF DataCube would apply here to convert SOSA to SSN
<joshlieberman> jtandy: can one provide a mechanism to transform from SOSA to SSN rather than somehow guarantee that a SOSA instance will conform to SSN axioms?
<jtandy> ref. RDF Data Cube, see the "normalization" algorithm here: https://www.w3.org/TR/vocab-data-cube/#normalize
<joshlieberman> kerry: not clear what the Datacube reference is? PROV is an example of a simple vocabulary plus additional terms and additional constraints on vocabulary.
<joshlieberman> kerry: should be "automatic" tranformations SOA <-> SSN.
<joshlieberman> roba: entailment regime: how much work required to understand / reason over a term in either vocabulary. Endorse kerry's goal of (seamless?) SOSA - SSN interchangeability.
<joshlieberman> ahaller2: should be able to do better than PROV at modularization. least "commitment" is probably option 3. did make a strong attempt in options to leave out technical mechanism issues such as redirects.
<Zakim> jtandy, you wanted to add a bit more context about RDF DataCube normalization
<joshlieberman> ahaller2: no option (unfortunately) is satisfactory in all aspects.
<roba> sorry cant hear
<joshlieberman> jtandy: RDF datacube "normalize" uses a SPARQL query to expand a definition.
<ahaller2> +1 for roba, all options assume that SOSA and SSN are aligned
<joshlieberman> roba: no option sets SOSA and SSN as completely different vocabularies.
<jtandy> [+1 to Rob - thanks for the explanation]
<joshlieberman> roba: could prune options list for undesirable mechanisms such as equivalence.
<AndreaPerego> Just to say that an example analogous to the one mentioned by Jeremy is provided by the "Dublin Core to PROV mapping", where CONSTRUCT queries are used instead: https://www.w3.org/TR/prov-dc/
<joshlieberman> mlefranc: some options try not to duplicate terms between two namespaces, e.g. sosa:Platform and ssn:Platform, and some do.
<joshlieberman> mlefranc: some options have somewhat arbitrary division of terms into the two namespaces, making it hard to predict which to use for a given term - hence interest in one namespace.
<roba> @mlefranc - so option 1 is for a no-namespace enviroment like json (not json-ld) - in which case it is orthogonal and can co-exist with compatible patterns (5, 8)
<kerry> +1 to taht idea
<joshlieberman> roba: namespace "prediction" is orthogonal to other issues.
<joshlieberman> kerry: would be convenient not to have to remember or lookup namespace for a particular SSN term.
<joshlieberman> ahaller2: should have a vote on options?
<ahaller2> PROPOSED: We aim to NOT duplicate terms in SOSA and SSN
<roba> fine - buts its an orthoganal issue that needs its own treatment and options evaluated on their merits.
<kerry> +1 (do we mean namespace or ontology here?) but +1 either way
<mlefranc> we mean: if there is ns1:Platform, then there is no other ns2:Platform
<roba> rules out 2,3, and 4
<ahaller2> By consequence we ruled out Option 2, Option 6, Option 3, Option 4
<roba> yes and 6
<ahaller2> Option 1, 5, 7, 8
<roba> so difference between 1 and 5
<joshlieberman> ahaller2: Rules in 1, 5, 7, 8
<roba> PROPOSE; rule out 5 as it relies on mime-type - 8 is simpler
<mlefranc> (option 5 does not rely on mime-type)
<roba> @mlefrance it does to access the axiomitisation
<mlefranc> it relies on URL
<joshlieberman> 5: two ontologies, 7,8: three ontologies
<roba> @ahaller2 - that statement only holds true of SSN - strong axiomitisation
<mlefranc> @josh 2 ontologies in option 5
<joshlieberman> roba: issue of conflating strong axiomitization of SOSA with SSN
<mlefranc> OWL Client Protégé uses by default application/rdf+xml
<joshlieberman> option 5 uses mime-type to distinguish rdfs from owl, so may not work.
<joshlieberman> roba: propose to remove 5
<joshlieberman> ahaller2: disagree that 5 is disqualified on mime-type mechanism
<joshlieberman> Does the option 7 core have a namespace?
<joshlieberman> Could option 7 be explained? It doesn't make sense to me.
<ahaller2> @joshlieberman yes, you would only use the unified namespace in using the ontology, unless you want specific axiomatisation, then you can use the other two namespaces
<roba> option 7 is option 8, but allowing SSN and SOSA to have diofferent meaning for the same terms
<joshlieberman> mlefranc: "unify" namespace collects the terms. SOSA imports unify and adds axioms. SSN imports both and adds more axioms.
<ahaller2> @joshlieberman that applies to option 7
<roba> if we remove the original (and edited out) mime type basis to discover axioms, then option 8 = option 5 with a link to import (discover)
<joshlieberman> why does option 8 ssn import both if sosa already imports unify?
<joshlieberman> difference option 8 between sosa and ssn axioms?
<joshlieberman> roba: some differences in sensor specialization between sosa and ssn in option 8
<mlefranc> not necessary
<joshlieberman> ahaller2: terms split between two namespaces or contained in one namespace?
<roba> should new terms with specific restricted semnanrtics be in a new namespace
<roba> or machinery be able to handle namespace discovery ...
<joshlieberman> mlefranc: 1,7 all terms in one namespace. 5,8 terms in two namespaces
<ahaller2> PROPOSED: Do you accept that a term, e.g. Platform may have a one namespace, whereas another term, System may have another namespace
<ahaller2> PROPOSED: Can you live with three namespaces, i.e. a unified, one for SOSA and one for SSN
Resolved: Option 7 is ruled out
<ahaller2> Option 1, Option 5 and Option 8
<joshlieberman> 2 versus 3 namespaces?
<joshlieberman> what is the meaning of "package" in option 8?
<mlefranc> @roba, also the case in 1 and 5
<Zakim> kerry, you wanted to mention that we are close to bumping in to BP time on the schedule and to suggest a straw poll
<roba> depends on the client....
<ahaller2> straw poll for Option 1, 5 and 8
<joshlieberman> mlefranc: vote for / against lower or higher axiomitization of e.g. Platform
<ahaller2> first proposal, Option 1:
<mlefranc> option 1
<kerry> option 1
<mlefranc> option 1: +1 -- option 5: 0 -- option: -1
<joshlieberman> roba: "package" is a file resource, pretty much each file is an ontology...
<joshlieberman> ...in option 8
<joshlieberman> so in option 8, there are three ontologies whose membership is defined by three file resources.
<ahaller2> Option 1
<ahaller2> Option 5
<ahaller2> Option 8:
<joshlieberman> Result is largely equivocal. Should consult mailing list and resolve tomorrow, perhaps earlier.
<joshlieberman> kerry: earlier is better for remote attendees. 8am.
<roba> hopefully we can restate the options - with the known limitations - remove votes and let a wider group discuss merits
<mlefranc> I'd propose to create a new wiki page with the limited options
<eparsons> just setting up new presenter
Jeremy: Note the note in the agenda to review use cases. That's not on our plate today.
… [going through the agenda]
… Do topics need to shift in any way? Anything that you'd like to prioritize?
<roba> will be here first 90 mins...
[Re-organizing topics to help WebEx people 12 hours ahead go to bed at a not too unreasonable time]
Jeremy: Question is on samePlaceAs. We thought proposing the property in schema.org. Dan Brickly raised the fact that this was trivial.
Ed: The vagueness of Place is good.
<joshlieberman> joshlieberman: semantic versus spatial vagueness
Jeremy: Since I made this proposal, I've been looking at geohive.
<roba> we're not seeing the screen share..
Jeremy: Here there are using an "ov:similarTo" relationship
Jeremy: If you look at ov:similarTo, that comes from Open Vocabulary.
… The motivation was to have a less strict definition of owl:sameAs.
… That seems to be the same thing as what we are trying to achieve.
… That's not a spatial thing per se.
<roba> "what we are trying to achieve" ?
Josh: There is a distinction between saying that something is a similar concept and that something is at a similar location.
Kerry: For me there's a reason not to use location, because we may not know.
<joshlieberman> so we can also draw some distinction between location and position. The former can be less precisely defined than the latter.
Kerry: If there's a location, I would expect that to be precise. Place is more fuzzy.
<joshlieberman> place is not a position. it's a feature.
Kerry: I would expect the relation to be not transitive, and not symmetric.
Jeremy: I think that echoes Josh's concern.
<joshlieberman> Atlantis the place?
Byron: I don't like the word Place very much, for reasons similar to Josh. Hotel rooms across the street could be the same place but different locations.
… sameLocationAs or similarLocationAs could be a way to specify what you mean. My main point is I think this is an important discussion. If we're going to talk about samePlaceAs, we need to narrow down what we mean by that.
… Two different objects that happen to be the same physical object, for instance.
Jeremy: From your perception, the Place concept is vague. We all agree that it's vague. Some like it, some don't. You believe that adding a sameLocationTo property would be useful to give a statement that two things are on the same location but you don't have enough info for topological assessments.
… We would end up with two properties: the social or perceived relationships between two things, and the topological relation between two things.
… There is evidence of requirements but not consistent practice.
… Eddystone lighthouse example: 4 physical light house over history. You would largely say that they are at a similar location.
Rob: There's no particular reason why we can't say that two things can't have multiple relationships. For best practices, we want to encourage vocabulary reuse: use the most specific relationship that you can find for a specific purpose, and then add the more generalized version that the community might expect.
… I think it's all just one pattern. We shouldn't argue about what terms to use so much as to agree that they are different vocabularies that you can use, and you probably want to use the most specialized one to start with and a more generalized one for broader reuse.
<joshlieberman> skos gives taxonomy relations, but they are not explicitly spatial relations.
Rob: If you expect your community to be using SKOS, it would be reasonable to provide the SKOS generalized equivalent.
Jeremy: OK, so it's ok to use multiple relationships, just use the most precise relationship you can. If you can geosparl:equals, then say it. If you cannot, find the next more precise level.
… In terms of best practices, skos:exactMatch, skos:similarMatch, ov:similarTo. Statement about how you would talk about similar places and about similar locations.
Ed: I like the vagueness of Place. I like that it doesn't have a specific location. If you talk to normal people, a place is by definition vague.
… That's a valuable property for us to recognize.
… We do want to make the relationship between vague things that may not have good spatial overlap. For instance Western US and California.
Jeremy: That's why I think we should be talking about two different properties.
Ed: OK, but one is not weaker than the other.
Jeremy: I agree.
Josh: I'm looking at schema.org for Place and I realize they equated Place with Location.
… It's anything with a spatial extent. Keys are places, that's the problem with this definition.
… I think it's fine to say that some features are places. They have meaning in human perception.
Ed: People think of places as representations of human interest. Not every coordinate on the planet is going to be defined as place.
Josh: If we put in samePlaceAs in schema.org, it uses Place which is too general.
Ed: Or too specific, because schema.org requires a physical extent and we want places that don't.
Jeremy: Anything that I bother to give a name to will have a spatial extent.
Ed: Not necessarily. "Home" for instance. It may be Tellington, the village I live in. Or my house.
Byron: However you think about "home", it still has a spatial extent although you may not be able to define it.
<joshlieberman> Schema.org: Place: Entities that have a somewhat fixed, physical extension.
Linda: Since we are speaking about schema.org. Is it feasible that we might propose a change to that definition?
Ed: That's possible.
Linda: It would help up.
Jeremy: None of the examples in schema.org covers "my keys" for example.
… What we've heard so far is that there is a need to express "samePlaceAs", perception of similar place, and then a geographic statement "similarLocationTo" when you don't have precise enough topographical information.
Ed: It still might be that two places may not be topologically the same but are still referred to as "samePlaceAs".
Josh: "colocated with" can aslo be a useful way of expressing meeting points for instance.
Jeremy: We also played with "nearby" as well.
Kerry: Something can be co-located with something else, but not be places. E.g. events.
Jeremy: We said that Place is something with a location and something that people give a name to.
… Another open question: if we have colocatedWith property, what would be the domain and range of that?
… We don't want to make statements at the geometry level.
Andrea: At the Thing level.
Josh: We want to be able to assert spatial relations between spatial things but we can only test those between geometries
… That may be addressable with properties changes.
Rob: [scribe missed beginning of comment] The only rule of principle is that you shouldn't use a property outside its domain. I don't think we have the resources or evidence of practice to narrow down meanings.
Jeremy: I think you're suggestion that we add a few strong examples in the best practice.
<joshlieberman> E.g. the topological relationship corresponding to "colocate" will depend on the features, their representing geometries, and the application.
Josh: If you say "my bycicle is colocated with your bicycle", it's probably a bad thing when they overlap. Colocation of baseball and soccer fields seems good.
Kerry: If colocation is from an object to another object, then if we have a property list hasLocation, then we can say that the location is the samePlaceAs the other location.
… On the one hand, it's a bit clumsy, but on the other hand, it fits the use case.
Jeremy: That needs a little bit more unpacking.
<roba> finding the bicycle to access it is different from taking the right bicycle off the rack...
Jeremy: I would encourage folks to contribute ideas to the mailing-list.
… We're aiming towards something, although without definitive statement.
<joshlieberman> Distinguishing how to relate features, e.g. places from how to relate locations, parallels well the basic distinction between SpatialThings and SpatialModels.
<Zakim> AndreaPerego, you wanted to ask whether co-location is necessarily about "spatial things" - e.g., co-located events?
<joshlieberman> Andrea - yes, spatial but could also be spatiotemporal.
Andrea: Wondering about how people may be using the notion of co-location. We may need to clarify how the relationship needs to be used, or say that co-located can be used for non spatial things, as in "W3C SDW meeting is co-located with OGC meeting"
<roba> this was my point about making sure use is correct, and use the most specific available.
Ed: In general usage, co-located has been used in discourses beyond spatial.
Josh: When? Co-located events usually mean that travel arrangements for one event will work for the other event. Spatial relationship may be fuzzy, but it still exists.
Jeremy: The Event class in schema.org has a location property.
<eparsons> action jtandy in next sprint work on introducing relations to express similar places as well as spatial features
<trackbot> Created ACTION-291 - In next sprint work on introducing relations to express similar places as well as spatial features [on Jeremy Tandy - due 2017-03-27].
Jeremy: So feedback is use strong examples and call out examples of misusage.
<jtandy> [see Example 48 for the SIRF example that roba is talking about]
Rob: The strength of the implementation experience was tested in research environment. We found we could do a good chunk of what we needed using VoID and RDF Data Cube.
… Is that strong enough to throw that as best practice?
<eparsons> Hello LarsG !!
Jeremy: The SIRF stuff was a research activity, as opposed to an operational platform. Are we comfortable pointing to something that did not make the "next step"?
Rob: The best practice is still the same. It's just an example of a vocabulary that can be useful. I would not necessarily point out SIRF.
Jeremy: In terms of BP, "reuse VoID", but you wouldn't take the whole SIRF data as evidence.
Rob: As a possible implementation, you can point to W3C VoID.
… The best practice is "reuse vocabularies", not "reuse VoID".
Jeremy: If I draw a line under the SIRF example, we also got the data.geohive, they are using the triple pattern fragments
… hey are using a bit of VoID to make that work but I'm not sure how much.
Ed: How is it a best practice if their usage is very different?
<roba> not sure usage is so different
Jeremy: One of the things that is difficult with linked data is that you have no idea what people are saying on top of your data.
… The first possible approach is using search engines.
… The second approach is exposing the data through an API.
… The third approach is reusing standard vocabularies.
Rob: They are not mutually exclusive.
Ed: All in all, maybe this is emerging practice.
Linda: I could ask people around whether they are using the vocabulary at all.
… Now this is not an issue at all, and I don't think we should spend too much time on this.
Jeremy: Perhaps this is a section that moves to Conclusion where we talk about interoperability concerns. That section of the BP would move to somewhere else.
Action: Linda to ask Kadaster about use of VoiD
<trackbot> Created ACTION-292 - Ask kadaster about use of void [on Linda van den Brink - due 2017-03-27].
Jeremy: OK, I feel comfortable with that.
<roba> I'm going to bow out now . cheers all
Jeremy: on BP1?
Josh: I mainly changed the intro of the Why section, to distinguish exploration and validation.
Jeremy: In terms of finishing things off, in London, we tried to recognize that people with SDI would attach a lot of metadata but that this was often going to the bin, whereas it could be published.
… In a web-friendly way.
… If you look at traditional geographical records, it's full of complicated XML. Putting things in an HTML page with schema.org labels, you've exposed the data to human beings.
Ed: Handcrafted metadata separated from the data itself hasn't worked, but we're not suggesting that you don't do it. All we're saying is that if you do it, then you should expose it.
Josh: Traditionaly, the metadata as a description of the data is an alternative representation of the data file and you should negotiate that.
Jeremy: I'm wondering if BP1 is ok as it is, and BP4 should also capture the fact that you need a landing page for your dataset description.
… There's a recognition that it is needed.
Josh: To keep it small too, BP1 is to say "make metadata", which is probably long enough.
Linda: BP4 already has this information [reading BP4].
Ed: Also, remember the order of BP is going to change.
Jeremy: Thanks Josh for being a bonafide contributor to the BP document!
<AndreaPerego> And an example: http://w3c.github.io/sdw/bp/#indexable-by-search-engines#ex-schemaorg-dataset-and-place
Andrea: To mention an issue working with metadata. People click on things and have no clue what to do with the metadata.
Ed: The API thing does solve that.
… You don't want a WMS URL, you want the URL of a page that contains the WMS URL.
Josh: There is great agreement that WMS should have a root page. There is less agreement about what that root page should contain.
Jeremy: Moving on to changes to BP3.
… New title.
… [goes through description]
Ed: I find the approach useful.
Jeremy: I left the note near the bottom that talks about converting between things that have heights and things that don't have heights.
Byron: The title has CRS, but it should be a plural.
… The augmented reality case might be worth calling out. People trying to locate things underground need to think about coordinate system.
Jeremy: BP4 hasn't been materially updated.
… BP5 has not been changed in ages. We'll come back to that one later to make sure it's consistent with the rest.
Linda: I changed the title to use an imperative form.
<kerry> can linda speak up please?
Linda: Work on example 14
Jeremy: No change on BP7. BP8, thank you Andrea for the mammuth work.
Andrea: We were not providing so useful guidance in the beginning, just listing options.
… With the help of others, I tried to provide more useful guidance for what to do.
… Now, the discussion for this BP says to identify intended uses and provide alternative descriptions of geometries for each of them.
… Also, for the examples I included, I tried to reuse existing ones.
… The examples show how people represent geometries, examples of different formats, etc.
… Also example with a bounding box
… Josh and Clemens raise an issue about coordinate different from CRS.
… Also, about the features included.
… Also, some gaps.
… WKT is not very detailed. It is widely used. This needs to be addressed somehow.
… My concern is that his BP is becomming bigger and bigger.
… Some of this information may need to be addressed elsewhere.
Ed: Maybe we need to think about the scope of the BP again.
… This is massive simplification of a complex topic. Use GeoJSON but there's a bunch of other stuff.
Jeremy: 4 main cases. Full-blown SDI, data integration, web applications, and then "I want to publish information about my village" human publication.
… In the work that you've done, you're kind of assuming that they have already made that decision about the kind of uses they want to cover.
Ed: If you're an SDI person, you'll aready know these things.
Josh: One practice to talk about geometry. It should use an encoding that is useful, etc. And then provide alternative geometries for different usage as needed.
… Could be two different BP.
Andrea: I was thinking that we should say something along the lines of "always try to make it possible to use your data on the Web".
Ed: I agree the aim should be the mass market of people that don't have the experience.
… It could be that your usage is more complex and requires more complexity, but the simpler web-friendly use case is also important.
Josh: If you get the feature for Delft, you need to have along with that: what is this geometry? What can I do with this geometry object?
Kerry: I'm afraid this suggests to me an extension of the BP rather than a contraction.
… maybe there's a re-structure that would make it more elegant
Ed: We recognize the challenge of getting the balance of that BP right.
<Zakim> jtandy, you wanted to clarify joshlieberman 's 3 outcomes for web friendly geometries
Jeremy: Josh's suggestion of taking geometry choice from multiple geometries sounds good to me.
<kerry> agree many cases --- and certainly something that we would want to talk about
Ed: Making geometry more accessible on the web should be our goal.
Josh: The point of making the geometry web accessible is that the feature then does not have to be embed geometry each time.
… If you mean something specific by geometry, you need to specify that: e.g. bounding box. And then select the right format.
… That's largely the right serialization.
… We went around in circles to wonder about whether the serialization should be addressable, but we ended up saying that this was complicated.
<Zakim> phila, you wanted to talk about intended uses
<ByronCinNZ> +1 intended use
Phil: Problem with phrase "intended usage". Change to "likely usage"? It is not up to you, once data is on the web, to determine how the data gets used.
<jtandy> +1 for me to
<ByronCinNZ> +1 from intended to likely
<eparsons> thnx for the clarification ByronCinNZ
Phil: The other thing in that BP, "currently" could be included in "content negotiation is not currently available", as we'll hopefully work on that soon.
<joshlieberman> On the other hand, it may be more positive to say "unintended use" than "unlikely use"
Andrea: No problem, but that's Jeremy's fault, I copied and pasted text from another BP, where it will need to be updated as well :)
Ed: Some organizations may have issues with the use of their data online, and they may want to express an intended use for their data.
… "My intended use for this dataset was to navigate cars", for instance.
Josh: The answer to that is much larger than the question. Who decides that? Etc.
<joshlieberman> My proposal to split the difference is "expected use"
<ByronCinNZ> Intended use should be captured in BP1
Phil: I don't disagree. There are many cases where a data publisher may want to be explicit about restrictions, including for legal reasons. I don't think that's a spatial thing.
… I don't think it should affect how you word this BP.
<kerry> +1 to phila's suggestion -- talk about "likely' here even though "intended" might still exsit forthe publisher (and so would also be "likely" one would hope).
Jeremy: After going through BP changes, I will call for a vote for publication as a new WD. Josh, do think it is fit for it?
Jeremy: OK, then let's go to BP9 before lunch.
Josh: About relative positioning.
… [going through the BP]
… I put some description of geocentric, allocentric, and egocentric referencing. For instance, with Augmented reality content you often find geocentric data that you turn into egocentric data.
Jeremy: This is a very good update of the BP.
… I've got a request for something to go in.
… But let's see others first
Kerry: Wouldn't be the place where colocation could go?
Jeremy: Yes, this is the place where you could talk about colocation.
Josh: This was focusing on geometric position.
… The spatial thing equivalent is some of the colocating. I did not address that.
Kerry: Can I suggest to clarify that a bit?
… In the introduction.
Josh: The introduction of the section uses the term location and we're talking about position. Good catch!
Jeremy: When I was thinking about the new BP9, I was wondering whether it would benefit from snippet examples. I think many people will just look at examples, and copy things from there. There should be in that BP as well, otherwise people won't follow the BP at all.
[Lunch break - 45mn]
<eparsons> Lunchtime return in 45 mins - 13:45 local time 12:45 GMT
Jeremy: Re-ordered the sprint plan.
… We were on item #3.
Jeremy: BP10: Bill has refactored it. We now start from upper level, focussing on the categories of use.
… 4 main use cases - for geo-specific applications, to LD and Web. Formats and vocabulary choice is based on that.
Jeremy: Any questions?
… The relevant BP: http://w3c.github.io/sdw/bp/#semantic-thing
<gabriel> Gabriel Képéklian, ATOS
<eparsons> ank next
ByronCinNZ: Data journalism could be another use case.
Jeremy: It is probably covered by one (or more) of the use cases.
kerry: Should we say "likely users" instead of "target users"?
Jeremy: Need to have a look at this issue (mainly editorial) across all BPs.
ClemensPortele: SDI is not actually an application itself, but it can be used by applications.
… Spatial analysis is also missing from the use cases.
<ByronCinNZ> SDI are not an application
eparsons: SDIs are not typically used as backends of applications.
Jeremy: I agree that SDIs are not applications, but spatial analysis is.
Jeremy: Any other comments?
Jeremy: Let's go to BP11 - Clemens?
ClemensPortele: The changes were mainly to align our BPs to the DWBP, and to extend them with spatial-specific points.
Jeremy: Any comments on BP11?
… It's way too large. It is probably 3 BPs now.
… 1/ Equality and sameAs
… No, 1/ is about Web linkings
… 2/ Equality and sameAs
… 3/ Spatial relationships.
Linda: It is indeed too long. I would like to separate bits that are not specific to spatial data.
Jeremy: Link discoverability can be moved out.
… The first part - Web linking - is not specifically spatial, so it may go to the appendix.
eparsons: This needs to be in the BP, but where to put it is more editorial - ensure that it does not disturb the flow.
… Talks about axis order issue.
… BP17 says there are 4 common ways.
… 1/ explicit say lat/long
… 2/ use a format having implicitly a given axis order
… 3/ say it in the data itself
… 4/ describe in dataset metadata
eparsons: Should we recommend one of the options?
Jeremy: No, it depends on the context.
… "Given the choice you make, this is how to do that"
AndreaPerego: About WKT and axis order, this is an issue to be addressed in BP8, since axis order is implemented inconsistently.
eparsons: It may be a broader issue, not applying to WKT only.
Gabriel: One of the things we did to address this is to specify which tool is serving the geometry - which may provide some information on the axis order.
ByronCinNZ: Indeed WKT is not consistently implemented.
… About option (4) - putting info in the metadata - [missed it]
Jeremy: I suggest we put a note either in BP8 or BP17 about the inconsistent implementation of axis order.
eparsons: Yes, this should be worded as a warning.
Jeremy: Thanks everyone, this was the busiest sprint so far
[round of applause]
<eparsons> PROPOSED: That the editors current draft of the BP doc at http://w3c.github.io/sdw/bp/ be published by W3C and OGC as the next public release
Jeremy: With this caveat I would propose to release the BP.
Resolved: That the editors current draft of the BP doc at http://w3c.github.io/sdw/bp/ be published by W3C and OGC as the next public release
Jeremy: Let's start with BP1.
[nothing to change]
[nothing to change]
[nothing to change]
LarsG: I can supply some text on sitemap - the current text is not completely correct.
ClemensPortele: Yes, we just need to come up with a proposal about the sitemap "size", considering what can be done, and what people actually do.
Action: ClemensPortele to draft reworked sitemaps section
<trackbot> Error finding 'ClemensPortele'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
Jeremy: Would you both be responsible for this?
ClemensPortele: I can do that, and then LarsG can review
<ByronCinNZ> Bye - off to my nexr middle of the night session HydroDWG
<eparsons> thanks ByronCinNZ
… One of the things to check is the use of DQV.
... 1/ update spatial things descriptions
... 2/ provide immutable snapshots
eparsons: We could use "epoques" instead of "immutable snapshots"
… Boils down to: Use HTTP URIs (really)
Jeremy: We have already went through BP8
Jeremy: Also BP9 as been discussed before lunch
… and BP10 right after.
… Heavily relies on DWBP.
… Recommends to use REST APIs
… Already discussed.
… It includes the sameAs issue
Jeremy: Also BP17 was discussed.
Jeremy: We have two main points, about BP14 and formats table in appendix.
Jeremy: About the current order of the BPs, this reflects the order in DWBP
eparsons: Also if we claim that the order does not reflect importance, this is what actually happens.
Jeremy: We may start by saying: Use HTTP URIs
<gabriel> BP order, following the workflow
Jeremy: Then move to how to describe the data (accuracy, CRS, geometry, etc.)
… Then what we link to, indexable by spatial engines.
… then BP8, BP17
… then BP11, and finally dataset and distribution metadata
kerry: [question on how this will impact Section 12]
Jeremy: If we are ordering BPs based on the workflow, we need to include introductory text
eparsons: A possibility is to list first those BPs having greater impact
Jeremy: [going through the BPs based on this criterion]
Linda: Interesting discussion, but it is important to have this thoroughly discussed also offline before taking a decision.
… I'm not yet sure about the ordering criterion.
Jeremy: [discussing about the timing for this change]
eparsons: Agree there are many possible ordering criteria, but it may be important to make it clear (whether with the order or not) which are the BP having the major impact
Jeremy: Before re-ordering, we need however to re-factor some BPs - in particular, BP8 and BP14.
… Overall, we should then have 14 BPs (including the extra 2 ones coming from the refactoring of BP8 and BP14)
gabriel: Just a question about BP1, where I don't see information on the size of data, which is an important information
Jeremy: This is addressed in DWBP, on which our BPs are based
Jeremy: Going to section 12.5, there's a long list of vocs, that probably should be presented in a different way.
eparsons: Yes, as it is, the list is confusing - no information about which to use
Jeremy: They may go in appendix, as for the formats
<eparsons> thanks LarsG
AndreaPerego: I started adding some draft text under each of them just to provide some "coordinates" about what you can do with them
Jeremy: [checking which vocs have been mentioned in the BPs - also in the examples]
… Yes to W3C Basic Geo, Schema.org GeoSPARQL
<gabriel> from the current list of RDF vocabularies / OWL ontologies for spatial data, it can be very useful to elaborate the sameas matrix
Jeremy: No GeoSPARQL update, no NeoGeo, DBPedia, OS Geometry + Spatial relations, ONS, XKOS
… Yes to DCterms
… No to BBC
… Yes to LOCN
… No to SWPortal
… vCard: TBD
… Yes to GeoRSS - no to GeoRSS OWL (but to clarify with Josh).
Jeremy: no GNDO, IGN, INSEE
[Decisions on vocs to be in and out agreed among all participants.]
Action: AndreaPerego to develop the list of vocabs and short descriptions of each as represenative examples
<trackbot> Error finding 'AndreaPerego_'. You can review and register nicknames at <http://www.w3.org/2015/spatial/track/users>.
Jeremy: Going now to the format table in appendix (section 13.2)
… Should we do the same exercise here?
Jeremy: In terms of formats, only the open ones.
gabriel: Open, but with licence - otherwise you don't know what you can do with it
Jeremy: no to ESRI
… Yes to GeoJSON
… No to DXF
… Yes to GML
… Yes to KML
Jeremy: Going to the second table...
… What we do with GML-SF0? Should be include in GML?
[agreement: we add a clarification under GML about GML-SF0]
Jeremy: About JSON-LD, this is just an RDF serialisation, so we need just one column
… We can list the other ones (some of them, at least)
ClemensPortele: Is schema.org open?
Jeremy: Yes, it's a W3C CG
Jeremy: No to Geopkg, ESRI SHP, GeoServices, Mapbox Vector tiles.
Jeremy: We should try to have some text on the formats, as planned for the vocs. Possibly mapping them to the 4 categories in BP10
Jeremy: And add to the tables HTML and WKT
Linda: Should the list of formats be kept in appendix, or moved elsewhere?
Jeremy: Ideally, also the vocs should be in appendix. But not completely sure.
Jeremy: So this closes the restructuring.
… now for coffee - back at 4PM (less than 10 mins).
<eparsons> scribenick eparsons
<eparsons> scribe eparsons
<eparsons> jtandy: restructuring is done
<eparsons> jtandy : Next topic review of open issues
<eparsons> jtandy : spatial operators - no guidance offered so far..
<eparsons> ClemensPortele : covered by API ? reference operators to api discussions
<eparsons> jtandy : issue 298 relates to operators issue
<eparsons> action eparsons ask phila iana relations follow up
<trackbot> Created ACTION-293 - Ask phila iana relations follow up [on Ed Parsons - due 2017-03-27].
<AndreaPerego> s/AndreaPerego_ to develop the list of vocabs and short descriptions of each as represenative examples/AndreaPerego to develop the list of vocabs and short descriptions of each as representative examples/
<eparsons> jtandy : Do iana relations really matter to us ?
<eparsons> ClemensPortele : iana link relations are niche not the first place a web developer looks...
<eparsons> proposal : We defer publication of GeoSPARQL relationship types into IANA link registry until a later date
Resolved: We defer publication of GeoSPARQL relationship types into IANA link registry until a later date
<eparsons> jtandy : issue 208 from BP 7
<eparsons> jtandy : indirect identifiers - should we stick to TAG guidance ?
<eparsons> jtandy : So suggest no change needed if we don't follow TAG ? - close issue make changes to doc in next sprint
<eparsons> jtandy : open issues now done !
<eparsons> jtandy : Final Sprint Plan
<eparsons> jtandy : to do - how to use section jtandy will complete
<eparsons> jtandy : to do - provide geometries in a web friendly way AndreaPerego to complete
<eparsons> jtandy : Spatial vocabs BillRoberts to complete
<eparsons> jtandy : Positional accuracy - PeterParslow to complete
<eparsons> jtandy : lack "how to test" requirements & benefits
<eparsons> tidoust : Graphics would be easy to implement if we use same categories
<eparsons> Linda|2 : Benefits difficult to apply to our BPs' a year ago - might be easier now
<eparsons> jtandy : We should follow same categories and presentation used in dwbp
<eparsons> jtandy : Might have empty boxes but thats OK - sdw not adding any more than dwbp
<eparsons> jtandy : Those that developed BP's need to check "How to test" requirements are correct Follow ClemensPortele exmaple :-)
<tidoust> [Note from another time: the BP benefits discussion reminds me of flipcards we did for Mobile Web Best Practices a long time ago. We got lots of positive feedback about these flipcards: http://www.w3.org/2007/02/mwbp_flip_cards ]
<eparsons> action eparsons work though public comments
<trackbot> Created ACTION-294 - Work though public comments [on Ed Parsons - due 2017-03-27].
<eparsons> jtandy : payam working on Appendix C to check dwbp / sdw overlap
<eparsons> jtandy : review of Backlog..
<eparsons> jtandy : Linda|2 will close BP15 issues
<eparsons> jtandy : Deal with remaining github issues on dedicated telecon
<eparsons> jtandy : Jobs to do - Glossary needs completion - PeterParslow steps forward to fix yellow things !
<eparsons> jtandy : Jobs to do - Editors add contributors section & acknowlegments
<eparsons> jtandy : Update BP4 making metadata useful on the web - jtandy to complete
<eparsons> jtandy : b17 add note on WKT CRS order issue
<eparsons> jtandy : ClemensPortele to update BP11 & BP4
<eparsons> jtandy : Reordering proposals from Linda|2
<eparsons> jtandy : Will not be able to do doc edits until next week so publication will need to be next week also
<eparsons> thanks everyone signing off for the day ! back tomorrow 8AM local !!