See also: IRC log
<trackbot> Date: 31 March 2011
<ahill> alex here
<matt> Core Draft
<danbri> (aside: I started a conversation with Ron Lake, GML originator yesterday ... he points us to http://www.galdosinc.com/archives/1192 which offers 'dictionary model' for understanding GML's role. I almost mentioned same metaphor yesterday to explain why RDF people avoid SHOULD and MUST in schema design )
<Ronald> scribe: Ronald
<matt> Scribe: Ronald
matt: we have core draft, ar landscape and ar vocabulary
... it was supposed to cover the gap between the core draft and AR
... I was thinking that while drafting the core, I was imagining that we would run into styles and other things that we might want to move into the ar vocabulary
... but we all are focusing on the core
<JonathanJ> W3C's vocabulary examples #1 - http://www.w3.org/TR/ddr-core-vocabulary/
matt: question is do we continue to ignore them and focus on the core draft
alex: does the charter say AR landscape, it says AR notes I think
<matt> Charter
<JonathanJ> examples #2 - http://dev.w3.org/html5/vocabulary/
matt: there is POI recommendation
... AR and web standard is a long name so I renamed it to AR landscape
... I put some stuff in the text around the deliverables
... I really thought people would say "Here's the core" with a lot of properties and that we needed a place to put the stuff that we did not feel should be in the core
alex: there are 2 worlds, the nokia's and navteq's, and the people who want to use POI in AR
... I think we are trying to architect things to not specifically make room for 3D models, images, etc
... they would become presentation data that can be attached to the core POI
matt: via linking, not saying here is our markup language
alex: I agree with that, but we haven't got a full list of what will be added
matt: maybe we should do more core work before knowing how to progress on this
alex; why don't we have a look at what pieces should go into this
alex: such as mentioning what kind of things people would add to a POI for AR. Like sounds, models, html content, interactivity
martin: things like lines, 3D area, connecting geopoints, coloring, transparency, tons of things
alex: sounds a little like openstreetmap, cartogrophy
... some people would argue whether that is AR
martin: for example if you are on a tower and want districts colored, that is AR
alex: agree, these features can be added. but what are they called?
... curves, regions
fons: sounds like SVG
alex: in some sense yes, but it may be described a bit different. at a higher level, that is what people want to do, but how we don't know yet
... svg could be possible, kml has something as well
... and for sound, there are many different ways of doing that as well. mono, html5, spatial
... and 3D models
... you are going to want some interactivity with these models
... maybe an extension to javascript like HTML (hover, click) for easy authoring
... or go deeper with X3D and DOM
jacques: or webgl
alex: many things seem obvious, but I want to get them down on a list
matt: I just started collecting some use cases from this discussion
jacques: you are speaking about content, but what about POI and linking POI. Do we want to have the notion of groups of POI in our spec?
luca: also clustering. If there are a lot together, how do we cluster and explode?
... in our AR application, we saw that if there are many things close together, you cannot click
<JonathanJ> I suggest we start from what/how POI can interact other (POI action) - http://layar.pbworks.com/w/page/30763878/Activity-types-for-POI-actions
ronald: this sounds like something for the AR note as it is a visualisation
luca: don't you think we should have a recommendation in the core spec
alex: I think it is something that might need to be in the core POI
... for instance in KML you have folders, and some level of detail control
... they have some visualisation paradigms
... if you have some on top of each other, you see one POI and it expands if you click on it
... this is very much an information visualisation technique
... not sure if there is anything structurally in the data controlling that
ronald: that's why I see it as not part of the data model
alex: has something to do with occlusion as well
martin: It is more of a feature than part of the data model
alex: I think it is good to mention it in the AR note now
... ronald: the clustering seems to be an implementation issue that should use information from categories and relations from the core POI spec
jacques: what if you want to navigate from one POI to another POI. You can switch to google maps or openstreetmap
... you must have a two level navigation system
<matt> Google Earth with a cluster of POIs at same point
jacques: I try to write a format very close to open streep map and link from core POI into the navigation level
<matt> Google Earth with a cluster of POIs at the same point, when clicked upon
alex: let's paraphrase. we need a higher level way of linking POI to POI to POI, and there needs to be a way to link it to a street level navigation system
... if we use gml kml, it is easier to link to openstreetmap, but if we write our own core POI it might be more difficult
jacques: we can go with something similar to this, but if we define a format for developers and nobody is using gml.
... gml is dead in some sense
... it is very difficult to find information in gml
... maybe SG
matt: I got an email from the creator of gml. he envisioned gml as a schema language for creating other formats
... for example citygml, but also georss
... he was not envisioning gml being used, but let people subset it
jacques: the schema for openstreetmap is 5 lines. that is very compact
<matt> GeoRSS
alex: please show us some examples. if I google georss, I get a main page with an example
<matt> primitives in OSM
<matt> OSM XML Schema
alex: so open street map is made of nodes, point in the world
jacques, we have nodes, ways (bunch of nodes)
jacques: it can have semantic data, links, rfd data
... it is very powerful, nothing is really missing
<matt> OSM Map Features
jacques: it is very compact and simple. that is why it is so succesful
... if you have a POI format that is close to this, people will more easily move
<danbri> it should be possible to ground a simple format in GML ideas, even if the simple format is CSV/JSON
alex: looks like a different approach. bottom up vs top down
... osm looks great. 200.000 developers and succesful
... we don't want to ignore and push away this crowd
... is it possible to come up with something that satisfies this crowd and everybode else
... and everybody else is everybody in this room
... there are multiple ways of standardising. one of them is not standardise, and the other is more formal like W3C
jacques: but it is a specified schema that is well defined
matt: we should look at how to look at the "normal" web developer, not just the big data owners
<danbri> (no jacques in irc?)
jacques: In different AR browsers, there is content from osm. Just search for mtrip
<jacques> mtrip and "le guide du routard
<danbri> OSM is great, an amazing achievement, but schema-wise it pushes a lot of modeling into tags
ahill: why can't the POI recommendation be OSM?
... using a schema very similar to OSM
jacques: it would be possible
... but after that you have to define meta data
ahill: so does that mean all POIs would go into the OSM database
jacques: no, it is just user data
<danbri> matt, from the map features page, 'OpenStreetMap does not have any content restrictions on tags that can be assigned to OSM-Elements (Nodes , Ways or Relations ). You can use any tags you like as long as the values are verifiable.'
<danbri> 'However, there is a benefit in agreeing to a recommended set of features and corresponding tags in order to create, interpret and display a common basemap. This page contains a core recommended feature set and corresponding tags.'
<danbri> so it's a kind of wiki approach
<matt> I see now, thanks danbri!
<danbri> if the schema encoded those it would be a bigger schema
<danbri> so comparing complexity by looking at the size of the schema is only a partial measure
<danbri> otherwise I'll make a <dan:Geo> </dan:Geo> schema with one element :)
<ahill> reading dandri's comments
<danbri> I'm off to read about http://linkedgeodata.org/
<danbri> (will let you guys get on)
<matt> Display attributes
jacques: schema is small with a lot of semantic data
ahill: but can I get anything out of osm using just the schema?
... judging/evaluating if something is a small schema you need to look at the semantic data
... what does this mean for us. why can't we use this?
... I am thinking that anything we create can be simple enough and it can be easily converted to osm
... but the same applies to gml, kml
... but it does not give me any guidance on how to structure our recommendation
matt: as far as I can tell, all osm is WGS84. so we would need to add our other location constructs
ahill: are there points that are not absolute
jacques: no, everything is to describe points in the world. we would need to add it
... but being close to this spec would help
ahill: is gml more verbose, because we are not relying on convention?
matt: having a namespace will avoid clashes, but still have convention
ahill: is it possible that with osm are less verbose, but if we add more things it becomes not clear to read anymore?
jacques: in a tag you can put an uri to an svg file
... your can reference HTML5, or complex graphical systems
matt: how do you do that in practical. is it on a node?
ahill: how do I render it
matt: is it an idea to make an example POI
jacques: I can provide that
ahill: to me, the discussion is that jacques is a C# guy, and I am a Java guy
... things are expressible in OSM or RDF or XML. This is not the question
jacques: the question is who will be using it
ahill: that is an important question, but I am unprepared to answer this question
... I presume that because we are in W3C, we would create a standard that is W3C like
jacques: open street map likes W3C
ahill: so why did osm not approach W3C
<matt> Danbri's mail about the spec's users
<ahill> does W3C like osm?
<matt> scribe: martinL
ahill: I have no doubt that we can use ARML or OSM
Ronald: more than the actual data format, it matters more to define the data model
ahill: We can then map it to a data format
... that's for later to wory about
<matt> Danbri's mail about hte spec's users
<matt> current use cases
ahill: i like to check the usecases dan proposed
... dan has described a very typical case. somebody wants to publish POI data and looks for guidance (W3C) how to do it and save wasting his time
... let's look it in light of something like OSM
... any examples of OSM playing with RSS (event scheduling etc.)? or are they just mapping streets (that's what i suspect)
... does the community use OSM for other tasks? social data? feeds? news?
jacques: yes - traffic information, other tools, additional layers can be added to the model
... for example REST API to query POIs
ahill: so people already creating POIs in the community (classes, add description, the type of information we are talking about)
... tools to create, query APIs exist
... something like SPARQL vs. OSM data?
jacques: use can use SPARQL to query OSM data, but RESTful API is much simpler
... RESTful interface is faster
<matt> [[LinkedGeoData is an effort to add a spatial dimension to the Web of Data / Semantic Web. LinkedGeoData uses the information collected by the OpenStreetMap project and makes it available as an RDF knowledge base according to the Linked Data principles. It interlinks this data with other knowledge bases in the Linking Open Data initiative.]] -- http://linkedgeodata.org/About
ahill: low-level efficiency issues: questions like "Why do you use SPARQL with OSM?"
jaques: with GML, it will take a lot of time to define complex queries
ahill: OSM has simple schema, the query APIs are simple (no complexity) vs. RESTful APIs on complex structures like GML
jacques: Before XML, there was SGML, but it was not successful - they wanted to move to something simpler
<Luca_> http://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language
jacques: We should use something simpler
ahill: message received
... we've talked a lot about it. in the end, we're agnostic. we do not choose OSM over GML or vice versa
... we're not experts in something like timestamps etc.
... Safe to say GML is a toolkit of things?
... how do you turn GML into a language?
<danbri> re query, my take is that we're primarily about data structures; different folk will query it in different ways / environments
ahill: just pick parts of it?
... When you look at GeoRSS, there are no new fundamental types, you'll find GML
matt: We can have our own XML and map to these things
... or JSON
ahill: Answer to OSM question is: "Nothing" - we won't reject it, but it doesn't provide a way forward to the discussion
Ronald: We should keep OSM in mind to create a mapping to it
ahill: we won't shut out the OSM people
<danbri> aside re SGML, ... the message that announced the Web was http://www.w3.org/People/Berners-Lee/1991/08/art-6484.txt says 'SGML (ugh! but standard) mark-up' :)
<matt> ACTION: Jonathan to merge landscape draft and browser draft into one document [recorded in http://www.w3.org/2011/03/31-poiwg-minutes.html#action01]
<trackbot> Created ACTION-47 - Merge landscape draft and browser draft into one document [on Jonathan Jeon - due 2011-04-07].
ahill: how does OSM handle altitude?
jacques: they are not using it
ahill: that's a concern. elevation is optional?
jacques: yes
ahill: if i make an OSM-based map, where do you get elevation?
jacques: you don't need elevation in navigation
martinL: in AR, elevation matters
ahill: of course, and you care about buildings
jacques: they are using Collada
ahill: let's switch gears
... let's work through the existing data format
matt: we've talked about time, categorization and name
ahill: not all problems are solved, but we are further in the discussion
<Luca> thanks J but it's not true :(
ahill: for the name primitive, we don't need to take care of things like encoding etc., cause it will come with a specific encoding, that's metadata
... multiple names for POIs in different languages is implementation-specific and will be in the matadata
... we need to decide if a simple name is enough
Ronald: last december, i think we came to a same conclusion
sorry for the "typo" :-)
<danbri> re labels, SKOS has some terminology for labelling: http://www.w3.org/TR/skos-primer/#seclabel and http://www.w3.org/TR/skos-primer/#seclabelsoutsideSKOS ... you can give labels in various languages, and a 'preferred label'
ahill: Preferred Labels is a way of prioritizing labels
... this adds to the discussion. a single name is not enough
... charset is a different topic
<matt> PROPOSED RESOLUTION: Character set is an implementation detail, will likely be handled at the XML processing level
Ronald: that's implementation
<JonathanJ> similar example : skos:prefLabel "ë™ë¬¼="@ko;
ahill: name is a textual label for a POI
<matt> RESOLUTION: Character set issues are an implementation detail that will be handled at the processing level (e.g. by XML processor)
ahill: done
<JonathanJ> we need to consider I18N issues - http://www.w3.org/International/techniques/developing-specs
ahill: in XML, there is no ordering, we need to define default labels
JonathanJ: we need to find best practices, not read the entire document
Ronald: reading through the best practices, maybe the Resolution should not be 5-4-3-2-1-done ...
matt: created a placeholder for internationalization issues
<danbri> (the spec(s) will also need review from the Accessibility community)
ahill: suming up: we need labels, but do we want a preferred label vs. alt label
Ronald: did we make a conclusion that label is better than name?
... i like label better, but personal preference
Luca: What is the difference?
<JonathanJ> right danbri. Normally, W3C specs need review from horizontal WGs - I18n, Accessibility community
Ronald: name has more meaning
... i can imagine a lot of POIs where name does not make sense, but label does
Luca: i'm in favor of the labels
ahill: we want to change name to label
Luca: ... we could have both
Ronald: that creates confusion
Luca: When using forsquare, there are tons of names that are different, cause everyone wants to create his own place.
... something that is more concrete, that connects the labels to the official name
ahill: that raises the question of authority
... question: should the data format propose to solve that?
... a boolean saying "This is the important one"?
... I would say no
... "e.g., Who owns the White House?
... there's nothing in HTTP or HTML or so that handles that question
Ronald: agree
ahill: so we use label. what about language?
... should metadata describe different labels for different languages?
<ahill> matt is typing
<matt> <poi xml:lang="en-US"><label>in en-us</><label xml:lang="es">en espagnol</></>
martinL: I like that
<matt> Ronald: Matt doesn't know Spanish.
ahill: do we wanna capture this in a document, and then move on
<JonathanJ> we might be to need like as ICANN for POI ownership
<danbri> "When using forsquare, there are tons of names that are different, cause everyone wants to create his own place." => this suggests we should capture a de-duplication use case: mechanisms to tell when two POI descriptions are about the same real-world entity (eg. via restaurant's phone number or url)
<Luca> <label xml:lang="it">In Italiano</label>
ahill: considering the two things coming into the IRC
... we don't want to consider ownership
matt: i think we don't want to cover registration
<matt> matt: We should facilitate being decentralized as much as possible. Using URIs to accomplish this is the Web accepted way (setting aside the centralization that occurs due to ICANN, etc).
Luca: For referencing the same name, we could probably use the location
martinL: That's tricky
Luca: Right, it could reference the big building, or outtakes from the building
ahill: We do need ways that two things refer to the same place
... do I want to refer from my POI to another POI ("that's the official building")?
fons: Consider databases where you have lots of addresses - we need a way to resolve duplicates
<matt> Scribe: Luca
matt: if your are going in a place and you create a POI: how do you avoid duplicate
?
<JonathanJ> there is two types of approach : supervised (Wikipedia style), unsupervised (foursquare style)
alex: there is 2 worlds: Information and something phisical
... GUID for the physical world?
RONALD: in reality we expect to have a multiple information that reflect the same element (POI)
<matt> matt: I think all we can do is pop up a layer, and assuming there is a URI for a POI, and we are in a well designed Web environment, that if two POI's URIs resolve to the same URI, that they are the same POI. I think that's the only claim we can make.
Alex: is it possible that we get down to specifying a location we can refer to identity (?????) a building?
... concern: there can be multiple db that have data, and there would be inconsistency. How can we resolve it?
<JonathanJ> How Facebook Can Solve The Duplicate Venue Problem - http://ericleist.com/2010/08/18/how-facebook-can-sole-the-duplicate-venue-problem/
sorry i miss Martin and Ronald talk about the authority
:/(
<matt> Alex: We can provide guidance on this. There will be authorities such as Ordnance Survey.
<martinL> i was saying the same problem we were talking about is approached through semantic concepts and the Linked Data Cloud
thank!
Alex: if 2 people drop 2 pois, similar, close, how our data format is going to solve the resolution on the duplication?
<danbri> the principle of having a location be able to 'claim itself' is pretty cool, and goes beyond Facebook. You could have the org's homepage declare an OpenID, and then if someone logs into your site (eg. Layar developer site) using that OpenID, you know it's the person controlling the org's site.
ronald: we need to address this problem (duplication) when we will looking at the relationship
<matt> matt: I think we help ease some of these issues by specifying a lot of 0 or more properties, e.g. labels: we can have the "California Pizza Kitchen" AND the "CPK" in one POI. We can have more than one location, it could be a point, or a model, or both. Without this ability to have multiples we will certainly cause lots and lots of duplication.
<danbri> related and somehow harder, is when two POI descriptions are at slightly different levels of abstraction; Tushinski as historical building vs Tushinski as film venue. Not clear whether to merge or not. The WG's approach to categories has some impact there.
<JonathanJ> +1, danbri
<inserted> Topics: More on names/label
Martin: I don't think metadata should be internationalize
... like the Label that should be use for visualization
Ronald: all of these premitive are data
... we should try to keep these things separated: Label - metadata
Martin: What would be the UC for label?
... What's the use case to use label in different Languages?
... when developers will use Label primitives?
Alex: new issue: people want to search for certain things
... and somehow Label are used for that
Ronald: Is XML:lang is enough to address internationalization (for label) ?
<JonathanJ> W3C I18N Techniques: Authoring XML - http://www.w3.org/International/techniques/authoring-xml
<matt> jacques: In OSM they use: <tag k="name:en-US" v="...">
<JonathanJ> W3C I18N Techniques: Developing schemas - http://www.w3.org/International/techniques/developing-schemas
<danbri> matt it's very likely a Ralph Swick-ism, from the '97 RDF spec: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#intro "The distinction between "data" and "metadata" is not an absolute one; it is a distinction created primarily by a particular application, and many times the same resource will be interpreted in both ways simultaneously."
<matt> RESOLUTION: We will use label instead of name.
<danbri> +1
<JonathanJ> +1
Ronald: we should add into the spec something that would help in adding the internationalization
+1
<danbri> for i18n http://www.w3.org/International/articles/language-tags/ is a good read
alex: do we want to distinguish from primary label to the other (in case of multiple labels)
<JonathanJ> <preferredlablel xml:lang="ko">캘리í¬ë‹ˆì•„ í”¼ìž í‚¤ì¹œ</>
<JonathanJ> <preferredlablel xml:lang="jp">カリフォルニアピザレストラン</>
Recap before lunch
Alex: long discussion on OSM
... we looked at that - very simple -
<matt> [[Discussion resulting in the XML examples here: http://www.w3.org/2010/POI/wiki/index.php?title=Core/Draft&oldid=404#label_primitive or latest here: http://www.w3.org/2010/POI/wiki/Core/Draft#label_primitive ]]
<matt> scribe: Matt
<Luca> Alex: Jack ask was : why don't we use OSM looking a the extreme success in the developer communinty?
Alex: We spent some time looking at various formats, OSM, RFD, etc. In the end we're going to be language neutral.
<Luca> Alex: and the groups said or thought: why not
<Luca> thanks matt
<Luca> and sorry for the readers
<Luca> :)
<Luca> about my minutes
Alex: For instance, we looked at LinkedGeoData.org, which takes OSM data, converts it to RDF and then allows SPARQL queries over it. It confirmed that people can make POIs in various ways, but didn't resolve the problem.
jacques: OSM is very easy for Web developers to use. Researchers can move to RDF format.
... We've moved back to OSM format as it's very efficient.
... A format similar to OSM same schema perhaps would be nice, and you can build applications with navigation and with POIs that are close to navigation systems.
... I think it would be easy to do this in something close to OSM format.
... It's very easy to use and very usable by Web developers.
Alex: He doesn't want the POI spec to be so different that it can't be linked to OSM data.
... How do you feel today vs how you felt in Seoul?
... We also talked about not wanting to inline things like HTML necessarily.
jacques: If we had something like KML for presentation above OSM for location data, that would be ideal.
<JonathanJ> http://www.perey.com/ARStandards/POI_from_OSM.pdf
<JonathanJ> http://www.perey.com/ARStandards/Markup_Language_Comparison.pdf
<Luca> OK
-> http://www.w3.org/2010/POI/wiki/Face_to_Face_Meetings/2011_Future_Face_to_Face_Meetings F2F options
Alex: I cannot go to a June meeting in Taiwan
martinL: I'll be at OGC meeting in Taiwan.
... But I'll go wherever we go.
<JonathanJ> If June meeting is not WG meeting, I cannot go to there
matt: My preference if we were to colocate a meeting with OGC, that it be one where we have relevance, e.g. the Denver OGC meeting where the 3DIM people will be meeting.
Alex: If we had the Geolocation WG, the DAP WG, Khronos and us, what are we going to come away with that? It'd be fun, but what do we get from them wrt what we're doing?
... I'm not sure if that recipe is really what we need.
... If we met with OSM people (not sure who they are), and Carsen for CityGML, I think that's something fruitful.
<JonathanJ> one of other option is meeting with OMA mobileAR
[[Looking at OGC agenda]]
Alex: Who is meeting at this meeting?
<JonathanJ> next OMA meeting will held in Budapest, Hungary (June 27 ~ June 30)
Alex: We need a way to make the players feel they are represented. Having members from other orgs be there, is positive.
... I don't have serious expectations that they will come to the table with lots of content to contribute.
... Let's not let our priorities get effected by things others want to inject. We can liaise with them.
Luca: We might find overlaps with other specs. OMA doesn't seem to have a specification themselves, they'll use our stuff to model their specification.
... I think it's best for us to meet with those who have skills we don't have right now.
... OGC may have the people we need. We only have three f2f meetings per year, we have to focus on what is good for us.
... Then there is the issue of them having a full agenda, how can we meet with the people if they're busy with other things.
matt: I think we should look at skills and things that we are lacking now, where we can get insight, then maybe figure out specific people/organizations to work with?
... e.g. geo, I think has a long history, lots of details.
martinL: I think we should be looking for computer vision folks too.
<JonathanJ> WG Meeting in Korea is available whenever we want :)
Ronald: Agreed.
Alex: Having danbri here for example was very valuable as we had someone speaking with authority on the Web. Having Thomas here was also good in that he's implementing this stuff.
Ronald: He's one of our personas for our use cases.
<JonathanJ> +1
Alex: I think we need the geo detail people too.
... We need something beyond just the data set folks, offset by other geo standards folks, e.g. OGC and/or OSM.
<scribe> ACTION: matt to work with OGC on participating in WG [recorded in http://www.w3.org/2011/03/31-poiwg-minutes.html#action02]
<trackbot> Created ACTION-48 - Work with OGC on participating in WG [on Matt Womer - due 2011-04-07].
Alex: If the people we need are not in Taiwan, we shouldn't cohost there.
... If there isn't an agenda item for us to meet with them, I don't want to go. If it's just hallway conversations that's not good.
... I would favor a US meeting in the fall, either OGC or TPAC, or our own.
Matt: We could also try to work around ISMAR 2011.
-> http://www.ismar11.org/ ISMAR 2011
Matt: I'd rather not attend ISMAR itself, but if it helps, I'd attend a WG meeting around it.
Alex: I'd say I'm still at "I'd go to something in the US"
Matt: Who will be at TPAC? Layar?
Ronald: Maybe, could be Dirk, or Jens or not at all.
JonathanJ: I'll be there.
Luca: If we meet, I can go. DAP is meeting as well, Marco is going to that.
Fons: ?? may go??
Matt: I'll be there for my other WGs at the very least.
... TPAC would probably give us more interfacing with the AR folks. OGC would give us more Geo expertise. We could also invite OGC to TPAC.
<JonathanJ> I think TPAC meeting must be valuable for us
Alex: OGC meeting seems more valuable to where we are.
matt: TPAC will also let us meet more Web people too, like danbri.
<JonathanJ> ISUVR 2011 - http://www.isuvr.org/
Alex: I'll be on an island south of Korea for ISUVR at beginning of July.
... Last few days in June or 1 July works for me in Korea
<JonathanJ> If we want it, I can co-host in Jeju, June 28(Tue) ~ June 30 (or June 27(Mon) ~ June 29)
Matt: My guidance would be to have us attend TPAC. It's really very useful.
... I'll put a poll together for F2F meetings.
Alex: Should we put Taiwan in the poll?
... If right OGC people are there, we can do it.
matt: Could probably get some OGC people at MIT in summer.
<scribe> ACTION: matt to work on poll for future F2F options. [recorded in http://www.w3.org/2011/03/31-poiwg-minutes.html#action03]
<trackbot> Created ACTION-49 - Work on poll for future F2F options. [on Matt Womer - due 2011-04-07].
RESOLUTION: Group will have the 3rd 2011 meeting at TPAC
<JonathanJ> +1
<Luca_> +1
Alex: Have Taiwan in the poll.
+1
Alex: I declare that I have a POI within Silicon Valley, and sv is represented by a URI.
martinL: If I want to put a POI in somewhere, I need a reference to it, it's like a hyperlink.
... So you're saying how can we make your ID for a POI unique in the world?
... Let's say you create a POI called Silicon Valley, and I want to create a POI for Palo Alto, should we allow for linkage?
-> http://www.w3.org/2011/03/16-poiwg-minutes.html URI discussion
Alex: If there's a POI that represents Silicon Valley, and there's some consensus that it's SV someone with some authority is going to have a URI for it.
martinL: If we do what we're saying, you won't have a URI for a POI.
matt: So, we could be talking about putting the URI on the envelop, or in the envelop, or combining the URI to fetch it with the fragment syntax to reference things within the POI.
Alex: Not following the envelope thing.
matt: On the Web, a web page doesn't really know it's URI. That's on the 'outside' of the envelope, it's how you fetched it via HTTP. And you can reference and create fragments though, fetch via "#" syntax and use id= or name= within HTML.
Alex: We've had conversation yesterday about how to fetch just a particular piece without the whole thing, which is a bit weird, as the server never sees the # in most cases.
matt: On the visible Web, the way it works is the hash portion of the URL never gets to the server. Once the whole HTML page comes back, the client looks for an id/name that matches the hash portion and jumps there.
jacques: Looking at how it works with OSM...
-> http://wiki.openstreetmap.org/wiki/Relations OSM Relations
matt: We're really back to the ID discussion.
Alex: We've had discussions about this, experts, etc that said use URIs.
matt: How does OSM handle mashing up things? Can I make my stuff reference an OSM data portion, or vice versa?
jacques: When you talk about this, you're not talking about OSM -- OSM is the database. You're talking about an OSM style schema to describe POI.
... We're speaking of a channel, that has something like OSM data. Now in that you want to refer to my personal channel, there's something.
... Linking within a channel is obvious, between channels, I don't know. If there's a URI for your channel, you could expand the URI, it should be possible, but you'd have to write it.
matt: channel=layer?
jacques: yes.
cperey: Does this happen in Wikitude?
martinL: We haven't rolled it out yet.
... There's a URI and an ID that references the world and then ??. You can call it from a web page or whatever.
cperey: So you can call one world from another?
martinL: Yes.
... We do some of this through wikitude based URIs.
Alex: Say someone made a Christmas tree layer. Can I include a reference to that in my layer?
jacques: With a REST API, it shouldn't be difficult.
Alex: It's one thing to click on a link and get a channel, but there's another to be able to link to a subset of a channel.
martinL: There's "I am linking to your data set" (e.g. your whole web page, or a new set of POIs). Then there's linking to a particular POI.
Alex: If I had made a POI in my world of a Christmas tree and Jacques wants to include that POI, does he copy that data or link to it?
martinL: Links to the data set with the fragment pointing to the particular POI.
Alex: We're saying basically support linked data. Not terribly complicated.
matt: We say that now...
cperey: Say, I want to put an ornament on that tree, but I don't have one, but Jacques does.
martinL: It's not all that dissimilar from iframes on the visual Web.
... Instead of copying, I link through an iframe.
Alex: It's not in the DOM for the hosting page, it's really quite limited.
martinL: I don't think we should get into the recursion or inclusion in an AR DOM or anything right now.
Alex: Let's codify this Christmas tree example.
cperey: I think it's much more likely you want it in an urban planning setting. e.g. a catalog of virtual objects being put on the walls or something like that.
Alex: Something dangling moving, hanging off of things... that's a requirement people will want.
matt: I think this is back to the relationships part rather than the ID part.
RESOLUTION: Core POI must be able to refer to a POI through an HTTP URI (recommended) or other global identifier outside of the POI itself.
martinL: We still need to figure out what the POI ID is.
Alex: I think we want to figure this out. People want to refer from the outside of the POI, e.g. "here's an HTTP URI that points to a POI". That is different than a bunch of POIs in one place, how do I refer to just one of them.
... We've said that that fragment part is how we will identify it.
PROPOSED RESOLUTION: The ID specified within a POI document will be addressable via the fragment notation in a URI.
matt: Yesterday I said "are there multiple POIs in a POI document?" and the response was kind of "huh?"
Alex: Today we say "yes", there can be.
cperey: Using the mall example, there could be a single document with all of the stores within it.
martinL: Right, otherwise you have to start with the whole universe.
cperey: There can also be synonyms and reassignments of the URIs, etc.
RESOLUTION: The ID specified within a POI document will be addressable via the fragment notation in a URI.
Alex: It was simple enough when we had a document and a fragment within it. Now we're talking about documents within documents --
martinL: It's not, it's a document that references other POIs
Alex: If POI A contains POI B, how does that work? How many different documents do I have?
martinL: Essentially you have a link. "contains" is a link. There's no nesting.
Alex: Flatly represented.
[[note, this topic change should be moved to where we have the topic of relationships]]
<scribe> ACTION: cperey to determine which OGC WGs are meeting at OGC TC in June [recorded in http://www.w3.org/2011/03/31-poiwg-minutes.html#action04]
<trackbot> Created ACTION-50 - Determine which OGC WGs are meeting at OGC TC in June [on Christine Perey - due 2011-04-07].
matt: I was thinking the three options were: TaichungTaiwan, Boston MA, Boulder CO for the poll.
cperey: Adjust the date to do it by Monday, have it close the next monday. Talk on TC in between.
jacques: A panoramic may have POIs within them, not separate POI documents.
... Don't want them nested.
Ronald: A POI is always a separate relationship, and not always just accessible within a POI group.
Fons: There's a difference between having the relationship expressed in the datastructure itself.
Alex: POIs are POIs, data structures that are grouping them together are what? POIs?
Ronald: Would this building be a POI, or would it be a group of company POIs?
Alex: I find it hard to find a situation where something isn't a POI.
... We think of a POI as something different to a grouping node.
... For the sake of argument if the grouping mechanism wasn't called a POI that might be more obvious
jacques: I'd prefer to keep a POI close to a point.
Alex: What about a building? It's a volume, not a point.
jacques: It's a building with a POI inside.
Alex: From an OSM point of view, there are points, and a point of interest is just a point.
... There are other datastructures that group them into shapes through relations.
... I disagree with that conception of it.
Ronald: I think it would be hard to model the other things we want to bring via AR. e.g. use cases that aren't only geo.
jacques: If we can stay close to that it would be good, otherwise there's POI within POI, etc.
matt: Just to be clear, we're not talking about the datastructure when we say "POI within POI", e.g.: <poi id="a"><poi id="b"><poi id="c"></poi></poi></poi>" -- we're not saying that.
Ronald: The adjacent to relationship, the routing info. I think there's debate about the OSM way of routes of points, vs Karl's statement of it is a relationship between POIs.
Alex: There's another thing that we've discussed, taking it out of the POI and make another data structure for expressing relations.
jacques: In OSM the relations are recursive too.
... To OSM a point is a point.
... To you a point is more vague.
Ronald: I get the feeling that points at OSM are closer to our lat/lng primitve.
jacques: I would prefer that the pois be between the relationship.
...
Alex: Declaring that two POIs are the same is a POI?
Ronald: No. There may be a relationship between the old restaurant and the new at the same location and you might want to capture that relationship.
cperey: You could do that with temporal information.
jacques: Relations and relationships are different things.
... In Geo they call a grouping of ways/nodes/relations relations.
... While what you're speaking of is a relationship.
Ronald: Some of us are talking about relations on a geo level, and others are talking about relations between POIs.
... I think the relation primitive of a POI has nothing to do with the geo relations.
... A POI in it's location primitive has a relation defining the geo boundaries. e.g. a polygon showing an extensible building. In OSM you would reuse that relationship from the geo perspective, but they are two different concepts.
cperey: We also talked about relationships like provenance, for-sale, etc.
Alex: I am not sure we agreed that that was within scope of our relation tag vs the metadata.
... KML has atompub bits to it that allow you to ascribe provenance, and there are other standards in use too.
... In some sense we want to restrict the usage to what really matters for POI, not to cover all cases.
Ronald: This is also somewhere we meet the semantic web too.
<relation type="http://...." id1="#a" id2="#b"/>
Alex: The conversation thus far: rather than having a few types that we prescribe, we could be flexible. Then we talked about POIs within POIs. We do want to accommodate the social provenance too. We do want to capture some relations like "California is contained within the US".
martinL: A city tour may contain POIs for it, but is the tour itself a POI?
Alex: I would say the tour itself is also a POI.
cperey: But you could also call that a way or a route.
jacques: I'd prefer that.
Alex: Do you want to restrict what we can attach to it?
Ronald: If this tour is a POI in our definition, then the POI will have a location primitive. If it can contain an osm way, we can do that, or have relationships to the individual points on the tour.
... I really see OSM as a way to represent the location primitive.
jacques: No, semantic data is attached to it.
... If you have a recursive definition of a POI it is much more difficult.
Ronald: Is the POI the leading factor or the location.
matt: I say it is the POI -- we can have POIs whose location is not geo based.
Ronald: That is the key difficulty.
... If everything is geo the OSM approach is fine. Is there a way to extend the OSM to other location primitives that we want to support?
Alex: Some of the examples we had at the last f2f-- it is weird that everything I am saying is being typed -- ha-- oo- a--
... At the last f2f we had some examples of a number of states or a bunch of businesses and there was a desire to have another grouping element -- a POI whose extent is implied by them.
... We could have a city which is prescribed by the things within it.
jacques: We would have to have a complex definition of a location.
Alex: We acknowledge that. We may use something like OSM to describe them, or something like GML for complex regions/paths/etc.
... Ronald is saying that those are the extents, the volume, the structure of POis -- but those are a conceptual term. The POI are the semantic data being added to points of space, and you may even group a number of POIs and say "this is a POI".
... I think your concern is that you grouped not POIs, but geometric objects and that those are a POI.
... I think what Jacques wants us to do is establish relationships between extents from a POI, not a POI to a POI.
... We're not working on a just geometric level.
[[Alex draws on board]]
http://wiki.openstreetmap.org/wiki/Relations/Multipolygon
http://wiki.openstreetmap.org/wiki/Relation:boundary
Alex: These all look like very geo oriented relationships.
Ronald: It's not metadata about it, just what it is.
Alex: an administrative boundary is as close as we've gotten to the semantics. It's just geographical.
... OSM seems to be geometry on a sphere. It doesn't have altitude even.
... We see that but want to do something more powerful moving towards, well, not exactly concepts, but things that may defy those boundaries of lines on a sphere.
Ronald: We also have a use case of a dynamic POI, a GPS on a bus for instance.
Alex: Bus going down the road has three labels on it "John" "Sally" and "Someone else" -- they're creating a POI, some call it an annotation, some call it a thought bubble, but they are all taking advantage of the fact that there is a location of "the bus".
... So there is another one of "the bus" itself. Maybe another pops up of "BGTV 26", which is in the bus, manufactured by Mitsibushi, etc. They're a single point.
jacques: I'm going bottom up, you're going top down.
Ronald: Can one integrate within the other?
jacques: It's a very ambitious format. I think you will run into trouble at some point.
Alex: Aren't these just triples? a verb b
Ronald: We may introduce this POI concept, besides the point and the way concepts and have links made via linked data.
Alex: We have an issue here. Brainstorming:
... This group has been operating for some time with the model on the board -- POIs can have relationships between POIs -- maybe these relationships are not geometric. The question is what problems does this cause?
... One issue raised: is there a recursion here? What issues does that cause?
jacques: Recursion is a real problem here, it could prevent a real implementation.
Ronald: Isn't this problem true of the semantic web too?
Alex: Yes, inference engines have these problems.
... So we need to resolve if this is going to create a problem for us. One concrete way to see this is through examples.
... We cannot walk away and meet again without examples, where we've tried to implement these things. Let's go try it.
... The value of trying is to get more minds to look at this objectively.
Ronald: danbri started a repository for examples.
Alex: That is where they should go.
... If we send around emails and it's not one click away for people, then that's a potential problem.
<JonathanJ> [picture from board] - http://instagr.am/p/Cs0Fv/
Alex: Let's use the wiki for now, then when we're ready for testing, we can use the repository.
-> http://www.w3.org/2011/03/29-poiwg-minutes.html#ActionSummary Action Items day 1
-> http://www.w3.org/2011/03/30-poiwg-minutes.html#ActionSummary Action Items day 2
-> http://www.w3.org/2011/03/31-poiwg-minutes.html#ActionSummary Action Items day 3
<scribe> ACTION: matt to clean up f2f minutes [recorded in http://www.w3.org/2011/03/31-poiwg-minutes.html#action05]
<trackbot> Created ACTION-51 - Clean up f2f minutes [on Matt Womer - due 2011-04-07].
<inserted> Scribe: matt
RESOLUTION: Group will work in XML, and not do the mappings to other formats simultaneously, but keep mappings in mind as we go.
... The WG expect that broadly equivalent POI descriptions will be exchanged in the Web using at least XML, HTML5, JSON formats, often embedded within some surrounding format or spec.
... The normative mapping included will be XML.
Alex: Action from day 2 on me is now to place examples in the wiki instead.
<scribe> Scribe: matt
RESOLUTION: Matt to start acting as informal editor. WG will bring together issues weekly for entering into wiki.
... WG will meet f2f three times per year
... Character set issues are an implementation detail that will be handled at the processing level (e.g. by XML processor)
<scribe> Scribe: matt
RESOLUTION: We will use label instead of name.
... Character set issues are an implementation detail that will be handled at the processing level (e.g. by XML processor)
... WG will meet f2f three times per year
... Matt to start acting as informal editor. WG will bring together issues weekly for entering into wiki.
matt: rrsagent hates two resolutions in a row. stupid bug.
RESOLUTION: Character set issues are an implementation detail that will be handled at the processing level (e.g. by XML processor)
matt: blah
<ahill> http://www.w3.org/2010/POI/wiki/index.php?title=Core/Draft&diff=380&oldid=379
RESOLUTION: WG will meet f2f three times per year
matt: blah
RESOLUTION: Time primitive is NOT required
alex: We need to decide if the label primitive is required. Create an issue.
ISSUE-10?
<trackbot> ISSUE-10 -- Should we require a label for POIs? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/10
ISSUE-09?
<trackbot> ISSUE-9 -- Is an ID required within a POI itself? -- raised
<trackbot> http://www.w3.org/2010/POI/track/issues/9
Alex: Motion to adjourn
<JonathanJ> Thanks for Layar's hosting - http://instagr.am/p/Cs4ad/
Alex: Thanks to everyone for coming! It is hard work!
matt: Thank you Layar!!
matt: The following is a complete list of resolutions made during this F2F. The discussion of each one can be found elsewhere in the minutes.
... Resolution 1:
RESOLUTION: Category primitive is not required.
matt: Resolution 2:
RESOLUTION: Character set issues are an implementation detail that will be handled at the processing level (e.g. by XML processor)
matt: Resolution 3:
RESOLUTION: Core POI must be able to refer to a POI through an HTTP URI (recommended) or other global identifier outside of the POI itself.
matt: Resolution 4:
RESOLUTION: Group will have the 3rd 2011 meeting at TPAC
matt: Resolution 5:
RESOLUTION: Group will work in XML, and not do the mappings to other formats simultaneously, but keep mappings in mind as we go.
matt: Resolution 6:
RESOLUTION: Matt to start acting as informal editor. WG will bring together issues weekly for entering into wiki.
matt: Resolution 7:
RESOLUTION: POI descriptions will be more useful when they include categorisation information. This could include classes of entity (eg. products, brands), as well as broader topics (eg. Medieval). Defining particular schemas in detail is beyond the range of the group, but we anticipate that URIs will be used to identify these classes and/or categories. There may be scope for publishing a small high-level taxonomy that integrates existing deployed practice, as wel
matt: Resolution 8:
RESOLUTION: The ID specified within a POI document will be addressable via the fragment notation in a URI.
matt: Resolution 9:
RESOLUTION: The WG expect that broadly equivalent POI descriptions will be exchanged in the Web using at least XML, HTML5, JSON formats, often embedded within some surrounding format or spec.
matt: Resolution 10:
RESOLUTION: The normative mapping included will be XML.
matt: Resolution 11:
RESOLUTION: There are lots of ways of identifying relevant POI descriptions, including GPS, QR Codes, image recognition (of specific things, of types of thing, of places, people, RFIDs). W3C POI data should be easily associated via various such techniques, and not be rigidly tied to any particular association mechanism.
matt: Resolution 12:
RESOLUTION: Time primitive is NOT required
matt: Resolution 13:
RESOLUTION: WG will meet f2f three times per year
matt: Resolution 14:
RESOLUTION: We should have just one normative mapping to use in the document
matt: Resolution 15:
RESOLUTION: We will use label instead of name.
