See also: IRC log
<trackbot> Date: 30 March 2011
<danbri> yesterday's notes: http://www.w3.org/2011/03/29-poiwg-irc
<danbri> draft minutes: http://www.w3.org/2011/03/29-poiwg-minutes.html
<matt> Scribe: danbri
discussing recap from yesterday
role/value of rdf
oh http://blogs.talis.com/n2/archives/818 might be useful, 'Select the name, lowest and highest age ranges, capacity and pupil:teacher ratio for all schools in the Bath & North East Somerset district ' (uk open linked data example)
<martinL> test
<matt> trackbot, start meeting
<trackbot> Meeting: Points of Interest Working Group Teleconference
<trackbot> Date: 30 March 2011
<JonathanJ> see yesterday's minutes : http://www.w3.org/2011/03/29-poiwg-minutes.html
JonathanJ, yes I think that might be useful. Perhaps in terms of exploiting externally maintained data (e.g. school-related info)
<inserted> scribe: matt
<danbri> ahill mentioning eg. from yesterday, http://www.rottentomatoes.com/m/matrix/ ... not a POI but potentially a movie showing in a local POI
<danbri> ronald, see also http://lists.w3.org/Archives/Public/public-poiwg/2010Nov/0034.html
[[introductions around the table again]]
<danbri> 15 Gigs of OSM data: ftp://ftp.spline -dontcrashyourbrowser- .de/pub/openstreetmap/planet-110323.osm.bz2
<scribe> Scribe: matt
Martin: I'm the CTO of Mobilizy/Wikitude.
Thomas: Bertine and I are working on an AR browser at a company called LostAgain.
cperey: Who has implemented a browser?
[[everyone but Matt and Dan]]
<scribe> scribe: cperey
Matt: new agenda
<matt> -> http://www.w3.org/2010/POI/wiki/Face_to_Face_Meetings/March_2011#Day_2 Day 2 Agenda
<danbri> 'lost again': http://www.lostagain.nl/
Matt: AR Landscape Drafts
... what Jonathan has put up and the AR vocabulary, to extend the core work, what is the shape of this, get an editor
Alex: do we have room for AR Notes? Yes, Landscape Note is part of what we will do
Matt: our charter
<matt> POI Charter
Matt: first is POI recommendation. Then, the charter says that we will produce two AR Notes. A note is slightly less rigorous thing
... could be published on our web site. Vocabulary to extend teh core recommendation Might include presentational characteristics... could include anything
... we have started the Vocabulary at all yet
... have NOT started yet
<danbri> http://www.w3.org/2010/POI/wiki/index.php?title=AR_Landscape/Browsers&action=history
Matt: we have AR Landscape.
<danbri> http://www.w3.org/2010/POI/wiki/AR_Landscape/Browsers
<matt> scribe: matt
cperey: It's not a gap analysis document
... This is more of a product feature landscape an inventory of what's in the products today.
... I'm looking to codify the standards that describe the different functional blocks that AR uses.
<scribe> scribe: cperey
<scribe> scribe: matt
cperey: I think that this is will focus on those parts that are about making AR on the Web. There may be scenarios where there is a client.
<scribe> scribe: cperey
matt: this is just a starting point. we will discuss it. I think this will evolve into a gap analysis of current standards wrt the Web and AR.
Ronald: is this group chartered to look at the full range of AR?
... or are we going to focus on POI
Matt: we are broader than just the POI in this area
bit from the charter... Dan... we should begin the conversations
Matt: there is distinct possibility that when we get core draft done, we can recharter
Alex: but I tihnk what Ronald is asking about is the AR note
<danbri> (so where are we collecting info about geo APIs: e.g. http://www.wikitude.org/en/developers https://simplegeo.com/ http://site.layar.com/create/ https://github.com/sogeo/whatser http://foursquare.com/apps/ http://code.google.com/apis/maps/index.html http://code.google.com/apis/earth/ ...etc etc ...?)
Alex: my feeling that the AR notes was restricted to what this group is chartered to speak about
... what is the POI we are putting forward and how it applies to AR
<matt> danbri, I'd suggest adding them to: http://www.w3.org/2010/POI/wiki/Related_Specifications
Alex: if it includes talking about 3D, then great, it probably means that talking about Device APIs, we don't need to cover the whole gamut
... in some sense, a landscape of all existing browser is not a requirement of our discussion, to understand how we go forward
... it is not necessarily in our charter that we cover all of that depth
<danbri> 'The WG may also publish use case and requirements, primers and best practices for Points of Interest as Working Group Notes. ' --http://www.w3.org/2010/POI/charter/
Matt: should we look at list of mobile user agents on browser page
<danbri> (so if someone e.g. wanted to make a 'how real projects are putting geo-related info in QR Codes, imho that'd be in scope for a separate Note)
martin: supported platforms could be added to the tables
Matt: Jonathan how d you want to proceed?
Jonathan: I'd like to talk about the document
... as mentioned, the landscape is main document, browser document is the details of one area
... I have discussed with many Korean people and community
... gathered many criteria so far
... first, is the comparison targets. I think we need to make a narrow scope for AR apps
<danbri> (matt, ok I've added them to http://www.w3.org/2010/POI/wiki/Related_Specifications )
Jonathan: because too many applications in AR domain. We can make technical specification for our standard. We need to narrow the scope
... I have written the features. First the .. second, linking to web services, third is rendering, fourth is...
... Collected a list in the document, about 13 products
... Christine made some comments. this are on the page
Alex: where do we the line? our browser is not commercially supproted
... it is in teh iTunes store but anyone can make an application. it's penetration is negligible but the features are important because it demonstrates some of what we are talking about
... some applications/user agents don't codify AR, read it...
Thomas: the data standard must look at main commercial ones. because if the standard can't do what they say that they do
Martin: mixare is downloadable, available outside of the laboratory environment
Jonathan: need to consider extensibility
Alex: the list is probably right.
Martin: as soon as something is publically in use
Matt: we stop collecting when we have all the features covered
Alex: Google Goggles is AR
... Recognizes a POI
... information about the POI pops up
... it may have features
Thomas: API for visual recognition engine could be on their roadmap. The feature that they have is one which AR browsers will have
Ronald: Visual Search and AR will merge
Martin: we can't separately Geo and Visual
Alex/Thomas: Nokia Point and Find should be added
<matt> ACTION: Jonathan to add Nokia Point and Find: http://pointandfind.nokia.com/main_publisher [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action01]
<trackbot> Created ACTION-38 - Add Nokia Point and Find: http://pointandfind.nokia.com/main_publisher [on Jonathan Jeon - due 2011-04-06].
<matt> ACTION: Jonathan to fix link for Wikitude [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action02]
<trackbot> Created ACTION-39 - Fix link for Wikitude [on Jonathan Jeon - due 2011-04-06].
Alex: Nokia Point and Find at some point you could download it for a phone
... some features I've seen demoed, are not available to everyone, but worth looking at and considering again
<JonathanJ> I was referenced a good report from edinbergh univ. - http://mobilegeo.wordpress.com/2010/11/23/comparing-ar-browsers/
Alex: some of the things that Petros mentioned , aggregating POIs into footprint of buildings
... street view like browsing
... so does StreetView belong on this list
Thomas: and you can use the gyro in your phone to see things
Alex: it's not strictly AR
but what should we be focused on?
<matt> Petro/Nokia's position paper
Alex: I want to say that the definition is not tight or exclusive to keep StreetView and Goggles out
... these are close enough to be considered here
<matt> close ACTION-39
<trackbot> ACTION-39 Fix link for Wikitude closed
Alex: it's remote, browser based, worth considering
Thomas: AR is a potential output method, the same data can be viewed on many different applications, in an AR form if appropriate
... non-issue what you call AR or not
Alex: and at some point there will be a maturation of this definition
... like VR, lots of things expanded outside the original definition
<Zakim> danbri, you wanted to ask about qrcodes
Alex: It's a visualization method for POI
Dan: what about QR codes?
... I find AR unconstrained, it's fine, does lots of cool things
... useful for navigation in real time
... QR codes are quite well understood technoogy
... I'd like to make a pitch that they are in scope for this group
... I just want one standards thing taht is part of QR code
<matt> GIST QR codes
Thomas: AR should be small enough to act as a direct link to the data
<matt> [GIST]QR_Code_Data_Representation_for_AR.pdf QR Code Data Representation for AR
Thomas: QR code is very limited in what and how much it can store
Alex: I second what Dan is saying
<danbri> can we resolve unanimously that this group hopes to make some contribution around the use of QR codes for POIs? (whether documenting existing practice, or suggesting a design...)
Alex: for the notes, for us considering the implications of a POI standard, this use case of seeing a QR code and sanpping it is applicable
... it should be in scope
Martin: looking at the list, these are all mobile applications
... we should also include in scope non-mobile applications
... like Total Immersion things on desktop
Alex: but didn't you (Jonathan) want to restrict it to mobile browsers
<danbri> re QR code capacity, see my thread last year http://lists.w3.org/Archives/Public/uri/2010Apr/0007.html on lengths of URIs 'in the wild'
Alex: at the same time, you could imagine street view
... if you have been excluding it from the discussion is the wrong thing to do
Thomas: it would be ludicrous if you had to pull down data from one source for desktop and a different place for mobile
<danbri> oops wrong link. http://lists.w3.org/Archives/Public/uri/2010Apr/0003.html 'URI length statistics "in the wild"?'
Thomas: for content providers that would be a show breaker
... we want to avoid all the systems that labs have done but at the same time, it is appropriate to include StreetView
Alex: I recommend that it be included in the list
Thomas: if you are dealing with image relative position, there is a great advantage to including them
... at the end of the day it is a marker and a model (3D model) on the marker
... a standard way of associating a marker and a 3D model regardless of where it is would be useful
Jonathan: we need more time
Luca: my feeling for AR is that it is something that you put on the real world
... for example, StreetView it is not exactly AR. Desktop can be included as long as you use a webcam to put things in teh real world
<JonathanJ> It is not problem, what product is included or excluded
Luca: for me, for what I include when I think AR, it is display of information on top of the real world. Google Maps is not AR. You do not see the real world
<danbri> Luca, not everyone can see...
Alex: if you are walking down the street and you take away the background
Jacques: you are switching from AR to mixed reaity
Dan: is AR only for people with good vision
Thomas: geo-located sound is in scope
Alex: he's talking about it is synthesized background. but if you take away the backgrond ad you see the same content, the same rendering engine is doing
... that is Ar
<JonathanJ> I don't think AR only for people with good vision.
Luca: because we don't have to be on the street for us to have AR experience
... I don't want to say that only geo located can be AR. It can be visual recognition, sensors, printers, etc all of this is included and in scope
<JonathanJ> ISSUE: what AR is our scope
<trackbot> Created ISSUE-6 - What AR is our scope ; please complete additional details at http://www.w3.org/2010/POI/track/issues/6/edit .
Alex: overall features.... is there anything on this list that doesn't make sense. I see the idea. Does it have an SDK
... is it using Points of Interest?
Jonathan: I can see that filling out this table is going to get messy. Everyone is going to be full of caveats
Thomas: what user interaction standards should be defined
... define a click action
Alex: for me the biggest differentiation is Web 1.0 and Web 2.0
... whether you can put your finger on it and stretch the world, manipulate the model
... data representation is an important feature to add
... I think is of value. We use KML and HTML for Argon
... I don't know what Acrossair does
Martin: Acrossair is closed and proprietary system
Alex: edits into the document
Thomas: should the data representation be separate from the POI? Is that important? Is that relevant to discuss
Alex: for first pass, we list what we know about these things.
... filling in the table
... does anyone at this table know anything about Google Goggles data representation
Thomas: it is probably going to be like MapAPI
<martinL> http://www.junaio.com/publisher/examples/example/examples1/addon/#example1
Alex: how they do it. this is where the rubber meets the road
<fons> s/probsbly/probably
Ronald: you get XML back and you get a URL to which you can go
Alex: is that a POI? Did it return a POI?
Martin: is a POI tied to a location?
Alex: if I'm standing in front of building, and I shoot an image, and I get the name of the building, have I got a POI?
... yes
Thomas: whatever links the real world to the virtual content is POI
Alex: I pick up my phone and I look at the courtyard and I see a Polar bear. it is AR.
... nothing is there but a lot of people who argue it is a POI
... sometims these lines are difficult to draw
... we agree that kooaba is returning data and POI
Ronald: It's JSON. No ties to any other standards at this time
Alex: but the JSON is returning POI and data
... maybe because what we need is a column that describs how we are triggering in some sense
... Have it in the table
... why don't we change user interaction
Dan: finish the column
... ovijet
... put proprietary
Jonathan: they are visual search
<fons> s/tey/they
Alex: what is sekaicamera
... it is social AR in geospace
... this doesn't answer the question of data representation
Sekai camera is also JSON
<matt> Mixare JSON docs
Alex: wikitude
Martin: ARML, based on KML
Alex: when we say KML we mean XML
Thomas: the format is same but KML has things already sorted , already specifies location
Alex: what is the difference between name space and ...
... markup language
Dan: XML was born as a simplification of SGML
... it XML was created, they wanted to interleaved
<matt> xmlns is the default, prefix is the non-default ones
<danbri> re XML namespaces see http://en.wikipedia.org/wiki/XML_namespace
<JonathanJ> There are a missing point. I want to compare from 1st cloumn (Data Representation) what they support 2D, 3D format.
Coffee break.
Alex: it's become obvious that we need to focus on our objective. We don't have time to flesh out the document here
... we need to focus on what's available and how our POI standard effect people who want to deliver AR
... how do we answer that
Matt:
<matt> Snesor
Matt: technologies listed here. some with work going on in W3C
<JonathanJ> see http://www.w3.org/2011/02/mobile-web-app-state.html
Matt: gyroscope work in progress
... microphone work in progress
Thomas: these are all very big things,
martin: there are other people doing work on these
... as a reference, we should point to others who are working on this
Dan: I don't see video feed here
Jonathan: add camera input
Matt: add the applicable standards
Alex: where are we going to put this
<matt> scribe: ahill
thomas: should we separate device access standards from POI standards?
<cperey> http://www.perey.com/Standards_for_Augmented_Reality_March_28.pdf
<matt> ACTION: matt to add links to existing standards http://www.w3.org/2010/POI/wiki/AR_Landscape/Browsers#Sensors_and_Device_Capabilities [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action03]
<trackbot> Created ACTION-40 - Add links to existing standards http://www.w3.org/2010/POI/wiki/AR_Landscape/Browsers#Sensors_and_Device_Capabilities [on Matt Womer - due 2011-04-06].
<danbri> (finished editing now)
<cperey> http://www.perey.com/ARStandards/Landscape_of_AR_topics.pdf
agreed
thomas: what about user rotation in the POI spec?
ronald: we've discussed the orientation of content, but not the orientation of the user
martin: we need to separate meta data of POI, geo-location and data representation (visualization)
<matt> scribe: cperey
martin: we need a clear separation. We go to this point and not further
Alex: I never felt that our responsibility would be to render teh content
... the question is how do we facilitate teh data coming with the POI
Thomas: there is some overlap, may want inline data with teh POI you don't want to link to a remote text file if you want only a two line...
Bertine: maybe a CSS?
Alex: we all have in our minds, ideas of POIs that include lable and description
... you're saying that's so cannonical that we don't want an extra standards for describing that
... does this argue that there should be a place in teh standard to relate that?
Thomas: you wouldn't embed a JPEG in an HTML page
... same with a model. If you have a short bit of text it makes more sense for it to be in line
... it has to be related
... needs to be standard for a simple label annotation. It needs to be in a Standard
Ronald: we have name primitive in our browser
... style sheet is not directly part of POI Spec
... you can say that POI Spec has a couple of fields but up to the specific browser to show content of a particular type
Thomas: but does the creator of content want to specify how it is visualized?
Ronald: yes, but not in the POI spec
... the question is if it is part of POI. Or if you have a link to the visualization within the POI
ThomasL should POI include a class reference
Martin: KML does something like that
Essentially what you have is an XML represetnation of a POI
Martin: do we define a new POI standard. KML defines almost everything we have talked about
... our proposal is to eliminate all of the stuff we do not need in AR
... we pull the KML tags we need and we add AR tags we need
Alex: let's say that the way you describe coordinates, if you disagree with that then you would be leaving the standard
Thomas: simple differences like Lat vs. Latitude
Alex: funny to hear say that. Dan was showing how we could put RDFa into a web page. Lots of angle brackets. Seems a little verbose
... point of view, perspective changes the definition of "verbose"
probably not worth it for us to invent another way to represent
Alex: at some point we are going to need to peruse other standards and come up with ways to improve them
WGS84, etc
Alex: we need to get down to brass tacks and say who's description we are adopting and what we think it is going to look at
<matt> trackbot, close action-40
<trackbot> ACTION-40 Add links to existing standards http://www.w3.org/2010/POI/wiki/AR_Landscape/Browsers#Sensors_and_Device_Capabilities closed
Alex: wouldn't necessarily throw out KML if verbose, if millions of people are using it
Thomas: you establish key value pairs and maybe in a few year's time, the changes may come
Matt: eXdInterchange
<danbri> re XML compression, see http://www.w3.org/TR/exi-evaluation/ Efficient XML Interchange Evaluation
<matt> Efficient XML Interchange WG and specs
<danbri> "This Working Group Note is an evaluation of the Efficient XML Interchange (EXI) Format 1.0 with reference to the Properties identified by the XML Binary Characterization (XBC) Working Group, relative to XML, gzipped XML and ASN.1 PER. It is conducted using the XBC Measurement methodology. "
<JonathanJ> matt, I think we need cooperate with DAP - http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0029.html
Alex: back to KML, we were talking about representation.... I'm not... not to say it's not the right way to approach it but in our KARML version, we take desription tag
and it is HTML. YOu can have styles. Put some text in and browser would render as a default, but you can add HTML for presentaiton. You could imagine extending , add some SVG instead
Alex: so in that case, now the data is inline with the POI
... the isue is that in some circumstances we want a link to presentation data. so effectively, we get the POI data, it has a link to Web Page, and that's the data we want to present in AR
... yesterday we were looking at the entire web page. bottm line is the minimal set that we want to allow people to inline
Dan: there are part of the HTML ....
you can ask it to bring back a really simple version
Dan: can't remember the header names. At the HTTP level thre's a whole set of ...
<matt> alex: How common is content negotiation?
matt: very common, gzip
<matt> matt: Depends on the content types. For instance, most browsers support saying "I accept HTML, and gzipped HTML" -- this is widely deployed.
content negotiation, if we define a format with its own MIME type, one of its characteristics could be its compressed
Dan: wikipedia might implement it
<danbri> see http://en.wikipedia.org/wiki/Content_negotiation
Ronald: web servers also try to figure out what type to send
Alex: but that's not reducing what gets sent, it is an efficiency
Thomas: yes it is
Martin: one question return to. What metadata
... do we really need a separate POI Standard separate from what already exists? can't we just pull out what we need form KML?
Marin: what tags would we really need?
Alex: we agree with you in general
Matt: we would take a profile of GML and augment with our specific vocabulary
Thomas: we need metadata. If there's an existing standard we should use it
<danbri> (re existing standards, also http://www.georss.org/Main_Page http://geojson.org/ )
Alex: we only chose KML because it was the broadest adopted markup
Not because we said it was the most/best
Alex: so yes, if you say GML, I agree
... I imagine in the future what we are adding to the dialog is quite small
matt: Yes, it could be a profile of GML.
Martin and Alex are in agreement
<JonathanJ> s/profiel/profile/
<Zakim> danbri, you wanted to assert that extensions shouldn't be an afterthought
Dan: yeah there's all these existing standards
... we've already begun picking up common elements
... story how they are the same is useful. Strongest we can do is extensibility
... figuring out the specific use cases, to specify how different datasets are represented
... connecting hop between what other's do and what AR does/needs is what we can do
Thomas: ...
... it needs to be automatically coming up when the conditinos are right
Dan: value adding services need to be able to bring out their data and the people to publish POI data to provide connections between their data and other data without W3C coming up with new vocabulary
Thomas doesn't need to define a movie database format
Dan: example of semantic markup,
<matt> scribe: Matt
ahill: When you say linked data is the way to go, can you describe it? I'm walking down the street looking for particular data, and you're talking about returning links?
Thomas: machine readable links.
ahill: My browser could follow these links and add information from these databases. We don't need to reinvent how to do that by any means.
... What do we need to do to facilitate this?
... Some people might argue that we would need a registry to facilitate these things.
Thomas: I don't think so.
danbri: Maybe at a high level to bring them all together, but the Web is it's own regsitry.
<JonathanJ> see Linked Data - http://en.wikipedia.org/wiki/Linked_Data
danbri: I'm walking along and my phone is relating my location to some service. I get a notification that there is a movie playing nearby with actors you like in it.
ahill: My project is relaying this to proxies who then go find this information out, rather than from the device directly.
... What is the difference between agent based semweb stuff and AR?
thomas: I don't think there is one.
ahill: Good, rather than reinvent the wheel we can piggy-back on other efforts.
cperey: I want to throw a monkey wrench in this: you haven't paid for this information. There should be a token to authorize that agent. It's not all just for free.
-> http://ietherpad.com/VVKVaoHANE scratch pad
cperey: Then there are ethics, laws. Is this person looking for illegal stuff?
... I just looked at a building and it had one picture, but now it has another, who has the rights for changing that?
Thomas: I don't think that's up for us to implement it.
cperey: Don't you want it in a standardized fashion?
Thomas: There are already standards for these things, SSL, certificates, etc.
cperey: Then we need to write that there are other standards that we could use.
ahill: I don't see the AR uniqueness here. So we don't have to worry about it then.
Ronald: There are security standards.
ahill: People are solving those problems already.
cperey: People aren't solving the problem of predatory real-estate.
Thomas: There's not going to be a one-to-one relationship, the user choses to accept whatever datapublisher they wish.
... If I use a mail service, I'm going to have their ads, that's known. Whatever source we use is going to be responsible for the adverts, etc.
ahill: Another thing we're doing in Argon is offloading to the proxy server under the acknowledgement that search becomes a bigger issue when you walk over to a place and it has 1000 POIs, that's a mess. Your trust network, who your friends or whatever, is really going to affect it.
... We have to acknowledge that at one location there will be a large number of things people have vied to get there.
<Zakim> danbri, you wanted to say 3 things before brain fills up: i) thinking about incentives is good; in my simple scenario, tushinki haveincentive to get customers ii) those are real
danbri: You're right to think about incentives. In the movie case, they want customers. If we do something as simple as Facebook, they'll get customers.
... The social issues exist. We'll have to look at them.
... And last, oauth is a big piece of this. They want their app to work and be deployable to lots of devices. OAuth seems to be the solution of choice at the moment for that.
Thomas: I think there is a lot of power to come from it. I don't think it's up to us to decide on that.
... The spec shouldn't require a third part auth.
Ronald: Responding to Christine's suggestion to standardize the too much content problem: I'm not sure that's really feasible. Are search engine results standardized in how they order things?
... No. That area of discovery of information, I'm not sure it's standardizable.
... It's a real problem for AR, but not necessarily one that gets solved by standardization.
Thomas: It's a big issue and so much room for innovation that I think that is where clients will differentiate.
cperey: How do you formulate the query could be standardized, but not how the response is formulated.
... When I heard query POI I was thinking: "Oh, that's talking about a directory of POIs", which isn't the same thing as querying.
... "These are my circumstances, here's a query for that" vs a directory of layers/channels.
<danbri> (ahill, if someone queries for Amsterdam Red Light District, their AR service(s) should route them to http://www.coe.int/t/DG2/TRAFFICKING/COMICS/ )
<danbri> (but that's a marketplace thing)
Ronald: In the end from our findings, it was quite difficult to get to something that the user really valued.
ahill: With them being the authority.
... No one on the web has defined how to index content in a standardized way.
cperey: There's SEO. In libraries we used the Dewey decimal system and found that to be useful.
bertine: I think the difference with the library example is that books are static.
Thomas: It could start off fantastic and then get swamped with ads.
... The order shouldn't be defined, but the request could be, is that right?
Martin: Web pages care about being ordered, but that's all search engine based.
Ronald: There is part of the HTML specification with keyword metadata.
... That gives content providers a way to find the right information.
ahill: Sounds like when possible we could leverage such things.
Thomas: metadata on the Web isn't useful anymore, hard to trust.
... search engines basically ignore metadata these days.
ahill: That's a shifting tide thing though. Might have been useful years ago though.
<danbri> google do use http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html
ahill: So how do we standardize around it?
Thomas: There will likely be AR search engines that look into the AR data and figure out if it's being abused.
<danbri> (you need another signal for trust and quality, eg. google rank, or facebook LIKE, ... then metadata can be exploited)
cperey: Is this matching our agenda?
matt: Is it what the group wants to talk about?
ahill: I think we should talk about these things now.
... I think the tone is that AR is going to be visually based. I think people see that as something very different than the kind of AR we have today.
... I think the points where these things come together is maybe location and description.
... Take the visual sensor example. I'm agnostic about the sensor.
cperey: That whole thing is heavily what the interface that the sensor web folks worked on.
Thomas: That's why I like to call them triggers.
... I'd argue that the POI has to contain the trigger.
matt: I don't understand why trigger has to be a unique part of the structure?
Ronald: I think we said that the trigger is part of the location primitive, maybe not using that word.
<JonathanJ> I'd like to suggest to make another document, something like "Requirements and Use Case for Linked POIs" by danbri
ahill: I could do a search around me and get 100 POIs around me, one of them is this cup. Some people want to call this a trigger, some people like me want to just say "I have the means to know I am in front of this cup".
Thomas: The difference I see is the metadata what you use to search with, while the trigger is an automatic thing.
... For instance the only ones that are in the field of view are triggered.
danbri: It's not up to the objects to determine that.
<cperey> http://www.perey.com/ARStandards/MOB_PatternsOfInterest_Proposal.pdf trigger position paper
ahill: Looking at a web page there's a ton of links. You scroll down and click on any of these things with the mouse. The triggers thing seems to be a way to simplify that, but it's more complicated than that, I could have preferences, etc.
Thomas: I'm thinking it's just more of a passive thing. Something that appears merely by association. A browser may or may not display them. I think there's a clear differentiation between active and passive things.
<cperey> http://lists.w3.org/Archives/Public/public-poiwg/2010Dec/0011.html trigger by Thomas
martinL: I think location then is a trigger as well.
matt: Why isn't any data in the POI a trigger?
Ronald: It sounds like search criteria.
Thomas: While you could search to have something appear automatically, it's not automatic. I search and don't get all of those results popping out all at one time.
<JonathanJ> POIs could be crawlable by search engine ?
Thomas: With AR there's a lot more automatic than the Web. We can't just have users activating everything manually.
<cperey> http://lists.w3.org/Archives/Public/public-poiwg/2010Aug/0053.html in the public mailing list
Thomas: I think it's the association of where the content creation believes the data should be put, whether it's image/location/sound based. That's slightly different than what the user wants to see at any given time.
ahill: Imagine there's a landscape with one item. The author specifies where it is, what it looks like,etc. That's AR, I don't need the word trigger yet to filter that.
... I need an argument for the word trigger now.
Thomas: I think you need a way to represent the association.
... A way to associate the data you want and an intended location.
martinL: Alex said filter, I like that, that's essentially what it is.
cperey: no!
ahill: We're talking about filter at one place, and then this trigger that describes the POI that is there.
bertine: It's trigger like a landmine, not a trigger like a gun.
Thomas: We can call it something else if trigger is confusing.
danbri: I found it confusing on the mailing list.
ahill: It's a linkage between place and content.
Thomas: I'd say it's part of the linkage.
... There's two parts: what causes it and what goes to it.
... The trigger is what causes you to go to it.
danbri: So is it up to the client to recognize the class of thing?
Thomas: Yes.
ahill: Is this linkage a POI that the spec is to connect data (SVG, HTML, COLLADA models) to a context of the user. That is our charge.
... Then when you talk about seeing a pen and using a trigger, it makes it confusing.
... A lot of people think "I see this and something is going to happen" -- that's a somewhat different subject.
<danbri> 'trigger' for me has a strong imperative reading, ... that the 'triggering' is inevitable
Thomas: The POI is a link between real and virtual.
... I was using trigger or whatever the word is to indicate the category of the sensor that you're correlating to.
ahill: So, there is a unique item, if I got a description of how to recognize it visually, I could dereference that eventually to the exact location on this table and then it's just like a movie theater, or whatever.
... So it's the same, but a different matter of how we get there.
... Then there's the example of "every pen that looks like this" -- which is a reasonable use case, but to me it's more of a pattern than a trigger to me.
<JonathanJ> POI trigger is like this ? - http://www.azouk.com/218107/Context-information-as-enhancement-for-mobile-solutions-and/
ahill: Now, say every building from a company sets aside an area for AR, and that's a pattern. Buses could have a sign on the side --
Thomas: How do you find it if the data isn't there in the POI?
ahill: I know I'm in a store, I look at my coordinates, dereference and I'm done.
Thomas: But that store is static. This is ludicrous, then the bus must relay it's coordinates to a server then the client has to fetch it.
... I have nothing against publishing moving coordinates.
... I also think that POIs should be able to specify relative coordinates. I just don't think you can limit it to just the coordinate space.
ahill: This just isn't unique to the domain of visual recognition. I think we will use visual recognition, I'm just saying that visual triggering can happen the same way by other means
... I'm more inclined to push it towards a special case in some sense.
Thomas: To me we need both. The most basic visual recognition is QR codes. That's literally just an image that is then decoded to a URL.
ahill: But that's not a trigger, that's just a linkage.
Thomas: We're associating an image with data, that's just as useful as associating coordinates, whether static or moving.
... The POI needs the capacity for both.
ahill: We need both, but they're not different enough in my mind that they can't be handled.
Thomas: I'm just saying a field in the POI that has coordinates or an image.
ahill: This is what Ronald was alluding to, that a location could have a visual description of pen.
Ronald: And it can be a combination of geo and visual too.
cperey: How it's stored is part of the POI, but not what is in there.
Ronald: Sure, the algorithms will change, etc.
cperey: The device which detects those conditions on behalf of a user, whether mobile or stationary, is using sensors.
ahill: Something like identifying a particular pen could have a number of criteria, so how do you author it. My sensor is going to be picking up that pen all over, but it's not necessarily going to be triggered.
Thomas: The system would have the image criteria already in it's memory.
cperey: You're never looking at the real object, you're just encoding those unique features that identify that class of object. Only those features, so you have an extremely fine sample, you're not walking around sending entire photographs of the pen around to be detected.
Ronald: Most of the time you're sending an image from the mobile to a server.
Thomas: There can be client side recognition.
cperey: But the point is the server side would probably just maintain the extracted features for recognition.
ahill: if I want to recognize this computer, I take multiple image that then get distilled down to something recognizable.
<Carsten> Morning, just wanted to have a quick look at what you guys are doing
martinL: I don't think there's a chance of standardization there as under different conditions have different better algorithims.
<danbri> (lunch-7.5 mins and counting....)
<Zakim> danbri, you wanted to discuss pre-lunch recap. Any actions arising?
danbri: Where are we? We've been chatting, but what action items are coming out of this?
cperey: We've been here before, and we've had people with agendas from geo-physical data that they want to solve.
ahill: And they didn't want this in scope.
matt: That's not what I saw at the last f2f.
cperey: In the next few minutes, the composition of the people in the group has shifted a bit. And it can shift back.
ahill: This is the part of the meeting where we are addressing AR stuff. We are talking about what are the implications? How does the POI stuff relate to AR?
cperey: This is entirely in scope as the subject of long/lat.
... And the traditional problems of those who own large POI databases?
ahill: Our existing spec solves that. It allows the POI database folks to add WGS 84 coord and a name/description/ec.
... Our existing spec also allows for a pen POI with a visual description and an unknown location.
<danbri> (this is a good time to have people make commitments to do things, and to record those in the issue tracker. I'd be happy to take an action to summarise what I could find out about encoding of URIs in QR Codes, for example)
ahill: In my mind I've got a search that includes "pen's that belong to Layar" -- I have those POIs, but I may not be displaying them. To me that's not any different than a POI that's on a building over there that's occluded by a building over there.
... I don't see it as any different than things popping in there.
Thomas: 99% of the time they'll be preloaded, there is a lot of precaching and displaying later.
ahill: You're interests, your context at the moment, those things all determine context that determine which POIs are in my browser currently.
danbri: If this room has a POI, there's a URI to it.
Thomas: QR code could be the link.
<scribe> ACTION: danbri to summarize URIs in QR codes to POIWG group [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action04]
<trackbot> Created ACTION-41 - Summarize URIs in QR codes to POIWG group [on Dan Brickley - due 2011-04-06].
ahill: In my mind our spec at the moment could work for a QR code with linkage to some data.
... I could imagine a QR code being the equivalent of a pen being recognized.
Thomas: There's also the case where the QR code could contain the POI itself, QR codes don't have to be links.
ahill: Practically what is happening? I see a QR code, it's got a URL, I get back a POI. It needs to be linked to something physical, maybe it's a marker to track, or the QR code itself, or four inches from the phone. That's the POI, the QR code is a specific means to encode the URL and there's a separation there.
Thomas: I am seeing a scenario where the QR code decodes to a link which has a POI which then may link to the 3D model.
... But the QR code could be just the POI itself and go directly to the 3D model.
<JonathanJ> QR code can encode in other many information bytes.
ahill: I see that you want to be pragmatic about the links followed etc, but I'm not sure that's what we need to accomodate in our charge.
Thomas: Perhaps not specifically, but it would be nice.
... We're talking a minimal spec and lots of optionals. Maybe the small thing could be in a QR code.
ahill: In our lab we worked with markers for ever, and now they're totally out. We recognize full-on images, which doesn't have any data encoded in those images. I could imagine that some day if we did push for QR codes that people would laugh at us in the future.
Thomas: I see advantages to not having the data require a separate lookup.
ahill: I think no one here wants to create a byzantine set of links.
... We've had a lot of discussion but no consensus.
<JonathanJ> we need raise issues
ahill: I think we can resolve that our POI standard that we've put forward accommodates many different scenarios.
... Whether it handles triggers, image recognition, etc. I've resolved in my mind that we haven't excluded any of those things. We haven't excluded any representations too, like COLLADA models, or HTML.
... I think that's valuable, as someone always pipes up on something like this and then we have the discussion again. I don't think we should have to do this conversation again.
<danbri> do we agree? "...that 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."
<JonathanJ> +1
<Ronald> +1
PROPOSED 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.
<Luca> +1
<cperey> +1
<JonathanJ> s/%1D//
Thomas: future issue: are the different criterias and-ed or or-ed?
<danbri> ... not hearing any objections; are we resolved?
ahill: True. I think people handle lots of this sort of thing in code. I think if people want conditions... they write code.
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.
Thomas: It's a fair point that we don't want to go into the logic too much.
... If you make a web page you don't have to code the functionality of a link. Metaphorically we're working on the equivalent of that, right?
ahill: I won't disagree with that. We're trying to provide some structure that keeps people from writing code to present data.
cperey: Is this called a "data format"?
... Because the OMA folks said specifically say they're considering doing an AR data format.
... I think these two words have universal meaning.
ahill: I'm concerned about making such a statement that is someone will say "POI is not an AR data format". I'd be inclined to say that our POI data format can be used for AR and we have specifically taken note of it. We haven't created a specific AR data format, but we believe it could be applied to that.
<JonathanJ> "AR data format" can include anything
ahill: I'd be hesitant to say it's an "AR data format".
Ronald: There's a reason there's a Core data format.
matt: And part of that is because there are other things that will use the POI format without being AR.
ahill: AR is the linkage format.
<danbri> http://www.ics.uci.edu/~lopes/dv/dv.html
<danbri> another use case where the publisher has incentive to be found: Best Buy stores: http://stores.bestbuy.com/153/
<danbri> ACTION: danbri identify relevant specs for rotation/orientation included at point of photo/video creation - what is current practice? [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action05]
<trackbot> Created ACTION-42 - Identify relevant specs for rotation/orientation included at point of photo/video creation - what is current practice? [on Dan Brickley - due 2011-04-06].
<danbri> eg scenario: I'm stood in middle of Dam Square, looking (west?) towards the palace, running e.g Layar + a flickr layer. Would it be useful to show only photos that are taken facing that same direction, ie. showing the palace and stuff behind it, ... or also the things behind me (Krasnapolsky hotel...)?
<JonathanJ> geolocation WG have been making the orientation spec. - http://dev.w3.org/geo/api/spec-source-orientation.html
matt: I see this: http://www.impulseadventure.com/photo/exif-orientation.html
... but it appears to be just about the image orientation.
... iPhone appears to capture in EXIF the data: "Exif.GPSInfo.GPSImgDirectionRef", from: http://gallery.menalto.com/node/97763
-> http://www.exif.org/Exif2-2.PDF EXIF 2.2 spec includes GPSImgDirectionRef and GPSImgDirection
<danbri> matt, thanks I'll read
<danbri> i made a test image http://www.flickr.com/photos/danbri/5573454469/in/photostream/ but maybe i have geo turned off
<scribe> Scribe: cperey
<danbri> matt, re http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs/ ... how do we go about getting a filetree for a testcases repo?
I'll scribe for an hour
when are we going to finish March 31? at 6 PM
Matt: we are moving the AR vocabulary to the end, in order to begin working on POI core spec page
... is there anything in the Landscape since last time we reviewed the AR landscape?
Alex: what are we going to do? don't want to go through item by item
<matt> Landscape Document
Alex: we should move on
Matt: get into core drafting, do more of this tomorrow when we have a better understanding of what's in/out of the core.
Alex: Or dedicate a future teleconference to it.
<matt> Agenda again
Matt: questions about the core draft
... we should deal with these up front, some we dealt wth yesterday
Ronald: are we trying to split up the work?
... can different people take more focus on specific sections?
Alex: maybe we should take the easier items and get them out of the way
... get the ball rolling with Time and Categorization. It also gives us a process.
Matt: we look at requirements of each primitive
Alex: if we do that as a group, then it's a shorter list
... we have (after Time and Cat) Relationship Primitive-- not something to be done in a smaller group
... then we have location, which is core
Thomas: agree that we need to work together
... Location is low hanging fruit already
Alex: Time establishes the format of what we are going to write
<matt> Core Draft
<danbri> matt can/should I bug sysreq for a poiwg repo? for testcases etc (and specs eventually...)
Alex: we might start with something circumspect
... location can get messy
Ronald: agree that location is pretty complex
Alex: begin with time
<matt> Time primitive
Alex: POI must--> can have a time primitive
... could be time when business is opened and closed
... that is relegated to metadata, not the primary function of POI
... time when this POI was created. This falls in provenance
... time that this thing came into existence.
... it's not obvious that every POI needs to come into existence and left
Thomas: if you say that something exists in this range of time, you are saying that we will move the user forward and backward in time
Alex: Google earth (KML) has a time stamp and time Span
<matt> KML Time primitive
Alex: Time Stamp says when and a date
... Time Span has a beginning and an end
... this is used in Google earth, to slide back in time to see content in past
... that's about the extent that we need to define
Thomas: suggestion that we have one more, ideally, time stamp of the last time the data was updated.
... it is useful for the client to know if they need to download it again or not
Expiration date
Thomas: it is a form of time which is useful
... Modification time
Ronald: might be better to put this in the metadata primitive
<matt> [[what about recurring time sets? (e.g. open hours) or relative times? (a store has open hours relative to the hours of the mall it is in)]]
Alex: this is where the conversation has gotten baroque
... lots of attributes you might want to stamp
... let's say some linked data has a date stamp
Thomas: technical level it is only necessity to have this type of time stamp in the linked data
Alex: how many links are we limiting a POI to?
Thomas: thinking it was One
... if it is more than one, it could be a time stamp per linked data
Alex: we ask for header, pull out o fheader, say no I don't want the data. Ct short the request, inspect the header
Thomas: COLLADA, X3D don't have those types of headers, may be wrong on that
Alex: is that our scope? to provide mechanism for lInk data to provide an expiration data
Ronald: don't think so. I'm not sure it is valuable. Adds too much complexity. In Layar we have.... to all the links (do they all need modification time stamp)
... in our concept they are all linked to the same POI
Thomas: i don't want clients to constantly update/download big files to see if it has been updated recently or not
Matt: HTML has this distinction
... it gets messy
We need a data modification
Ronald: in Layar definition, we have a single modificaation time and that it applies to all the data
Alex: concerned that utility might be limited. People might over-ride it. Head did not really capture what we wanted
Thomas: adamant that either it is possible to do this without time stamp, if it can't be done, it has to be there
... if not possible to do in header, it HAS to be in POI
... this could cause huge problems down the road.
Alex: that's a good argument for time modification time stamp, time span, time of applicability, could have a beginning and end
Matt: when this is being served over HTTP, these headers.... and any other transport mechanism must similarly
<danbri> (ok i've requested a poiwg repo for testcases etc to be added at http://dvcs.w3.org/hg ... time to read the Mercurial manual...)
Alex: if other POI query other links, they want to be able to send a time stamp to you to relect how recently the underlying digital object has been updated
<matt> matt: Basically, I think we should say "if you are transporting POIs over HTTP, you should be setting these X,Y, Z headers with the appropriate values. Other transport mechanisms should likewise provide such information."
matt: If I got a POI and it indicated that something has been changed, then it is my responsibility to go through and check each and to identify which elements have been updated
Alex: save the consumers of this data having to go through the subsegments and check this "manually"
Jacques: this is a basic feature of collaborative AR
Alex: can you please expand or give an example?
Jacques: for example, for guidance application, someone is outside, blind person, and you are looking in VR on a map, and you want to change some audio POI
... so you need to know when the audio POI can be changed
Alex: there's just me
Jacques: the expert is remote
the person in teh field
Jacques: you can change the content of a POI
Alex: there's a POI, and we want a way to indicate that the user (remote person changed the POI) that the content has changed
the browser needs to know that the content has changed
Alex: the POI has changed, how does the browser find out about it?
Thomas: this is a pull or push thing. This is web page expiration.
... if you are using a different protocol, it is not for us to decide which protocol i sused.
<JonathanJ> I think it seems like POI trigger, or POI pushing
Thomas: any additional downloads are the result, not the ....
Matt: the information about the delivery of the POI goes OUTSIDE of the POI itself
... It's in the envelope
Thomas: if can is virtual. and the person decides to move it. Change the POI location. It would not change the mesh of the can.
... So therefore the client would not be redownloading it, it would download the POI data but not the attached model
Ronald: we are talking aout the modificaiton time
Alex: we have the POI. The model has changed teh same. Location has been updated. Does the POI modification time change?
... the POI is in the local agent. Either I need to poll it or it needs to be pushed to me
Which?
Thomas: you don't need to transmit the update time
... just needs to communicate that the .... has been updated
Alex: look at a POI and knowing when it was updated sounds fine, but...
Thomas: The header may be a way to do this.
... the client may need to check to make sure if it has been updated
Alex: isn't that what happens already?
... in the web browser?
Thomas: the server gives recommendations about when to refresh
Martin: there are metatags
Alex: there's a big image, already local (cache) is it not pretty much the case that you have to tell the browser, hey that changed
... the image doesn't have meta, no header, we don't have a mechanism for that
... that's a problem, but it is not clear that it is our problem (yet)
<martinL> +1 for alex
Thomas: if it can't be done in the header, there's not another solution than to have it in the POI recommendation
Alex: reluctant to shoe horn this into the POI spec
Ronald: do we really want to have changeable mesh models
Thomas: most of these things will be fairly static. Meshes will probably be the same
... update time stamp is a simple solution
Alex: the problem is that it is a Macro, it is global to th POI, but not specific to what part of it changed, so it doesn't really solve the problem
Thomas; you need one orientation per link
Alex: no, I argue that you don't need that
... if there are multiple link, and oriented differently, but the base the frame of reference from which they are, that's what a single orientation accomplishes
... it sets down a frame of reference. It's not the billboarding
... it is that a single point in space... arbirtarily given is not adequate
<Luca> etag or any metatagit's better to understand i something has changed instead of timestamp that can't be unique for all the client
Alex: a discussion about time for POI, needs to be very specific. What is it about POI that need time?
... what is inherent to POI?
<Luca> http://en.wikipedia.org/wiki/HTTP_ETag
Alex: a time that this POI applies, whatever that means, that time period is really the need for the POI
... In agreement that we should at least have that one
... this is where have to decide what we do now. Do we hunt around for time specs?
Thomas: time span.... what time zone is it specified in?
<matt> XML Schema 2 time section
Thomas: do we need to explicitly tell the client the explicity time frame
<matt> KML time primitive
Alex: KML uses time stamp, they use datatypes Second edition
<ahill> http://www.w3.org/TR/xmlschema-2/#isoformats
Alex: ISO 8601 convention
... this time stamp assumes UTC. If it is not, you can add + or - something
... that's a reasonable place to go
... does this spec have a beginning and end
... KML has that, is that a wrapper.
Matt: looking at XML schema spec
... they have lower level primitive
... no recurrence
Thomas: suggestion would be that if year is not included it repeats annually
... what about something that repeats weekly? where do you draw the line
Alex: Other people who have sat around tables, have addressed frequency.
<danbri> matt, could you do a quick followup to my sysreq mail saying "agreed - with staff contact hat on" or similar? in case it bounces due to need for officialrequestness
Thomas: what do you mean the time span to mean in terms of repetition
... we are illeminating the possibility of any recurrence?
Alex: no, I don't have a problem with idea of recurrence, but we don't need a time stamp
Thomas: do not specify a year or a day.
Alex: but I don't know it includes something like Friday
Ronald if you goes to GDAY. It is a Gregorian day that recurs
Dan: really wished that we have the use cases
... the use cases is approach that if a user wants
... can we get 5 POI in english
<matt> scribe: matt
danbri: Let's get some use cases
Thomas: 1. A hot dog stand that is occasionally there, but also has open/closed hours.
danbri: What else might you want to know? Health inspections? Kosher?
ahill: Yes, sure, let's throw it into our examples.
Thomas: 2. A historical church that used to exist and is now destroyed.
ahill: 3. A congregation that was at a church for a period of time. The physical building may have it's own POI, but the type of church might only be there for a period of time.
danbri: Maybe people are exploring their roots.
cperey: Maybe a timestamp around when a member of the congregation can be trusted or not.
Thomas: This might be linked data from the POI to the person, rather than inline.
ahill: Agree on that.
... Is a person a POI? It's really hard for me to make a good argument that people are not points of interest.
Ronald: If that cup of coffee is a POI and I'm not, I'll be offended!
[[general agreement]]
cperey: The congregant, the congregation and the space in which they all may be are all distinct.
ahill: In the last f2f the major concern about these things were that if we do this we'll have to describes everything and anything.
martinL: 4. Football stadium that is open on Mondays and sometimes Wednesdays.
Thomas: I think at some level of complexity it becomes a manual process.
<danbri> for recurring events, see http://en.wikipedia.org/wiki/ICalendar#Events_.28VEVENT.29
martinL: I wouldn't say we want to get too complex, but we then need to have multiple time elements.
Ronald: If we can multiple POI times then we're there.
cperey: What about a church that adds wings?
Thomas: I'd argue that's a different POI.
martinL: I think it should be one of the examples, you might have one POI with a time slider.
ahill: If I am driving down the street, I see the church, not the sub POIs, the altar, toilet, etc. I'm interested in the church, now and I'm sliding through time and these things become obvious and apparent.
<danbri> ronald, re calendar/rdf stuff also http://www.w3.org/TR/rdfcal/
<danbri> ...and microformat markup for events http://microformats.org/wiki/hcalendar-brainstorming
Thomas: The specs for times seem pretty good.
ahill: We don't have the spec for it yet from us.
Ronald: If we're talking about existence then a single time span is sufficient. The other use cases where it's opening hours and things that change, then that's different.
cperey: Should it be in the spec?
ahill: In practical use for these things a time span is something you can include then if you don't include it it's right now and permanent.
... If you have one time span, then you could imagine that being a situation where you could see two of them.
... If two time spans get delivered with a POI, there's just two time spans, what would it break? There's not a parent/child relationship.
Thomas: So you'd treat them as an or relationship?
ahill: Talk of "will that hot dog stand be there?" is really about future things and not real time.
Thomas: Do we have a proposed format?
ahill: I think we can look at what's here and figure it out.
cperey: And then apply it to the use cases.
ahill: We're going to have a POI time, we've got a fundamental unit of time. It doesn't describe a duration.
... I think it just says a duration of two hours, rather than a start/end time.
... I think if the spec we looked at had a begin/end time then KML would have used it.
<danbri> re times, for content http://en.wikipedia.org/wiki/List_of_time_periods http://en.wikipedia.org/wiki/History_by_period
[[caldav seems to have a time-range defined]]
cperey: We had a discussion about location changing over time. We talked about having locations good for specific durations.
... The side of the bus is only valid while it's moving through this geo location.
martinL: That would be a property animation?
Thomas: We talked about having an ad appear at this location.
-> http://www.w3schools.com/Schema/schema_dtypes_date.asp W3C Schools (no relation) sample elements for a date range.
<JonathanJ> 1. present condition (periodical) 2. historical condition (duration), 3. acting condition (irregularity)
Ronald: I remember this discussion and don't remember the outcome. Do we store the entire history, or not?
ahill: I think we can say we don't store the history in the POI.
... KML breaks some of these apart too. Not necessarily embedded.
Thomas: Merely having a date span then you have the possibility of history through multiple POIs. Assign them to different dates with same location.
ahill: You can use a POI to do that, or not. Or you could have metadata to do it in one POI. You don't have to use it either way.
Thomas: Then you have to be very precise in the metadata itself. It becomes not metadata but data.
... The metadata should be describing the content, not the content.
<danbri> http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ "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."
Thomas: A building that has different shapes at different dates and times.
ahill: This strikes me as different representations.
Thomas: Not really.
<danbri> http://en.wikipedia.org/wiki/London_Bridge_(Lake_Havasu_City)
<danbri> :)
ahill: The London Bridge is now in Arizona.
... If I remodel my house, it's still my house. Some people are not going to like the idea that it's a different POI.
... If POIs have URIs, then people are going to want to have a stable URI to describe the building.
... Your proposed solution does not solve everything.
Thomas: Yours would have multiple time stamps that seems more complex than new POIs.
matt: I think there are use cases for both. If you want a historical slider, you include multiple time stamps, and if you want a canonical representation of the house now, then you don't put in multiple timestamps.
ahill: Thomas you're also assuming that the model has to be tied to the POI. There could be a separation, could be from a different database, different metadata.
Thomas: They'd be different POIs then.
ahill: I think this is semantics.
danbri: What are we talking about?
ahill: There are two constituencies, one that wants historical and one that wants permanence.
Thomas: If you don't want the history then you could have it be on POI, but if you want history then you want multiple POIs.
<danbri> matt, good question
ahill: There was some convention for mutation of points.
martinL: Essentially we're talking about the visualization changes over time.
... We have the data and the visualizations are different.
Thomas: No. I see this as the same as CSS and HTML. DIfferent things sent to different clients based on specs or whatever criteria.
... If you've got data associated with it, that too is a piece of data.
... My instinct is different POIs with different time spans.
ahill: The spec will let both work.
Thomas: Then you have to be prepared to spec out multiple timespans. Is that ok?
ahill: Yes.
Ronald: Didn't we agree that the history is outside of the spec?
ahill: Yes, but we're using different history means here.
matt: We've been talking about these primitives as a building block that can be used in different ways.
ahill: So we've been saying that the POI might have a time and the location may have a time.
... It's a bit of a can of worms.
-> http://www.galdosinc.com/archives/151 GML begin/end
ahill: If in the end we get something that's very close to GML, I think that's OK.
... This could be very similar to what we did with KHARML and KML. We had things we needed to add.
PROPOSED RESOLUTION: The world is complicated.
<JonathanJ> +1
+1
<danbri> oh, http://danbri.org/words/2005/07/26/110 'Profiling GML for RSS/Atom, RDF and Web developers' finally relevant ;)
-> http://en.wikipedia.org/wiki/Geography_Markup_Language#Subset_tool GML subset tools
<scribe> scribe: Ronald
<danbri> discussing http://danbri.org/words/2005/07/26/110 ... GML subset tool
ahill: we need to move on, but we also need to capture our discussion
... are the notes ok, or do we need to write the document
martin: we might be able to make focus groups to write it out
matt: we might not have to do it today, but I like the fact of teaming up people
martin: I volunteer for the timespan
thomas: I can help
<matt> ACTION: martinL to work on time spans with Thomas [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action06]
<trackbot> Sorry, couldn't find user - martinL
<matt> ACTION: martin to work on time spans with Thomas [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action07]
<trackbot> Created ACTION-43 - Work on time spans with Thomas [on Martin Lechner - due 2011-04-06].
ahill: I remember that someone said openstreetmap has a time definition as well
jacques: for opening hours for shopping centers, not XML, but in text
... it is very easy and compact
luca: we should prepare some use case to define the timestamp to check whether each language is good or not
... for example, for movie show times, we need to decide what is in scope or out of scope
ahill: talking to dan and we were looking into creating some examples in mercurial
<matt> ACTION: Alex to place some examples in mercurial [recorded in http://www.w3.org/2011/03/30-poiwg-minutes.html#action08]
<trackbot> Created ACTION-44 - Place some examples in mercurial [on Alex Hill - due 2011-04-06].
luca: my question was because the discussion was very wide regarding the POI we can describe, but we should start with something easy to get started
... and maybe in the second draft add other use cases
<danbri> we have to start simple for starters, maybe with a bias towards re-using nearby related specs (like icalendar)
luca: this can be applied to any primitive. Just to move forward and make decisions
matt: thinking of creating an issue for time and spans
<matt> POI tracker
ronald: but are all the primitives issues?
matt: yes, we should be closing them one by one
<Luca> icalendar
<matt> some notes on time primitive
matt: where do we want to gather requirements for the time primitive?
<danbri> (re terminology: icalendar is the ietf data format spec; caldev is a web-dav based protocol for managing a calendar, ... and 'ical' used to be a nickname for it, until Apple named their icalendar-compatible app 'ical' too)
<JonathanJ> icalendar spec - http://tools.ietf.org/html/rfc5545
thomas: we also need to pick a name for the field. 'time' or 'timerange'
ahill: if anyone else already has a spec for time, what do we do with it. Reuse it directly, or renaming things and embed it in our spec?
thomas: we can include it. I don't think it is copyrighted
ahill: but things are namespaces. Are we ok to combining different kinds of namespaces?
<matt> trackbot, close action-3232
<trackbot> Sorry... closing ACTION-3232 failed, please let sysreq know about it
<matt> trackbot, close action-32
<trackbot> ACTION-32 Invite Henning after Matt has put ID requirements in the wiki closed
bertine: we need to be careful there is not any slight difference in meaning
thomas: we should not make something different, just to make something different
ahill: GML, KML refer to ISO for timestamps, but it is a more fundamental concept
... in KML, there is a time primitive, which is an abstract class of which timestamp and timespan extend
thomas: does their timespan combine two time primitives?
ahill: in their context not really
martin: what would be the desired outcome of a focus group
matt: for editorial stuff, I am going to be a gatekeeper
... we will propose text on the mailing list, and I will put it in the wiki
... please include the text ISSUE-7 in the subject or body of the message for tracking
martin: ISSUE-7 or ACTION-43
matt: there are multiple actions to an issue, so discussion on the issue without closing an action
thomas: are we ready to move to the next item
alex: let's talk about categories
<matt> Category Primitive
christine: we talked about categories before, and the general thinking was
cperey: IETF and ? have done a lot of work on documenting not just places of interest
... they have their own structure for categories
... governments and international bodies have their own category systems, hierarchical systems, beautiful systems
<ahill> http://datatracker.ietf.org/wg/geopriv/charter/
cperey: it is unlikely that we as an organization pick one system
... we are insufficient domain experts
... there are experts out there, but not at our table. Henning has not replied and does not seem interested
thomas: is category going to be a required field
ahill: no
... it is not required, but in most cases it is valueable
<matt> PROPOSED RESOLUTION: Category primitive is NOT required
ahill: I can imagine a character string "category", but it is not going to solve the problem. For example we might need to support multiple categories
... we might need to make our own category, and people can choose to ignore
cperey: but it is better to reuse existing category systems
thomas: it could just be a link
cperey: exactly
thomas: a POI needs to be able to have multiple categories and these categories should be URIs
<matt> PROPOSED RESOLUTION: Category primitive is NOT required. Category can be identified by a URI. POIs can have more than one category.
cperey: if we just specify it this way, we don't need to invite an expert to come talk to us... it is an implementation detail
ahill: at some stage we need to work out the meaning
<matt> Good Relations categories
thomas: there are also simple formatting issues, e.g. comma seperated list or multiple entries
ahill: how about an action item of finding an example of a system using different category systems
<danbri> http://stores.bestbuy.com/153/
thomas: we should just focus on allowing linking, and not go into the meaning. that is up to the systems
<danbri> hot dog stand: http://en.wikipedia.org/wiki/Hot_dog_stand
matt: can you walk me through the bestbuy example
<matt> [[<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"><html xmlns="http://www.w3.org/1999/xhtml"
danbri: it is a particular store, if you view source and search for "property="
<matt> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
<matt> xmlns:dc="http://purl.org/dc/elements/1.1/"
<matt> xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
<matt> xmlns:foaf="http://xmlns.com/foaf/0.1/"
<matt> xmlns:gr="http://purl.org/goodrelations/v1#"
<matt> xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
<matt> xmlns:v="http://www.w3.org/2006/vcard/ns#"
danbri: you find lat lon, twitter account
<matt> xmlns:r="http://rdf.data-vocabulary.org/#"><head profile="http://gmpg.org/xfn/11"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /]]
danbri: they also have it on products they sell
ahill: should we go to a product page
danbri: would not bother now, but we can expect that data to be on the web and there should be links from the POI information
<matt> [[<div class="column right"><div class="hours" rel="gr:hasOpeningHoursSpecification"><h3>Store Hours</h3><ul><li class="day0" typeof="gr:OpeningHoursSpecification" about="#storehours_sun"> <span rel="gr:hasOpeningHoursDayOfWeek" resource="http://purl.org/goodrelations/v1#Sunday" class="day">Sun</span>]]
ahill: I want to look at an implementation that uses categories
matt: I see they are using opening hours from the good relations
thomas: but we are not looking at opening hours yet from the time primitive
ahill: when I went here, the website shows a category, but in the source I can't see any link to categories
... I need an example. I have the feeling we need a dictionary or a schema to define what the category is and where it is in the category hierarchy
<matt> [[I suggest we install the RDFa bookmarklet and use that instead of view source: http://www.w3.org/2006/07/SWD/RDFa/impl/js/ ]]
danbri: library classification schemes don't work that well as category scheme
... it is not really a thing in a category. it is a bit fuzzy
... it is thesaurus type stuff
... scos
<danbri> http://www.w3.org/TR/skos-ucr/
<matt> Best Buy example
danbri: if the POI is art related, the category will be using skos
<JonathanJ> +1
<danbri> http://www.w3.org/2004/02/skos/intro
danbri: if it is representing things, rdf uses different mechanics
<danbri> http://en.wikipedia.org/wiki/Hot_dog_stand
<danbri> http://dbpedia.org/page/Hot_dog_stand
<bertine> http://www.geonames.org/ontology/documentation.html
<matt> scribe: matt
danbri: The resource itself is: http://dbpedia.org/resource/Hot_dog_stand
... But the page is http://dbpedia.org/page/Hot_dog_stand
<scribe> scribe: Ronald
danbri: yaga is a organization on top of wikipedia
... is explaining dbpedia
thomas: is a broader term a parent type?
danbri: it is not really hierarchical
cperey: librarians have their own standardisation systems
<danbri> http://www.lexvo.org/page/wordnet/30/noun/frank_1_13_00
<danbri> a smooth-textured sausage of minced beef or pork usually smoked; often served on a bread roll ('en' language string)
<matt> Linked Data Cloud diagram
<danbri> http://richard.cyganiak.de/2007/10/lod/
danbri: most of the data sets are sturctured similarly
<danbri> http://dbpedia.org/page/Hot_dog_stand
danbri: we don't need to choose
<danbri> try sindice.com
<danbri> http://code.google.com/apis/socialgraph/
<cperey> NFAIS Standards
thomas: can I ask yahoo for green fruit. the linked data is not really used fully yet
ahill: until I feel that google is doing something other than proprietary mapping, I did not think the web is linked
matt: we are talking about categorization, right?
<matt> categorization primitive
thomas: there is potentially infinite categories, so using URIs seems a reasonable solution
<matt> Thread on cat primitive
<danbri> (you can probly use http://wiki.freebase.com/wiki/MQL to define a query for green fruit)
thomas: do we need to create an action point to decide what form to use.
ahill: if someone else has figured out time, and someone else categories... do we add a wrapper around it or recommend to use these specs
... do we need a wrapper that says this is a POI
<matt> Karl's document on categories
ahill: is it some sort of key-value pair?
thomas: there needs to be an identifying string saying this is a POI
... it may be the nature of the transmission that assumes it is a POI, but it depends on how it is used
... if an AR browser gets information from a server, it can assume it is a POI, but if it is on the web, we need to know it is a POI
<matt> [[This category description does not replace existing industry classification models, rather it enables reference to such standards and local domain derivations from such standards as:...]] -- Karl's document
<danbri> proposal: "The WG agrees that 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 integra
<danbri> tes existing deployed practice, as well as describing how to use Linked Data (skos, dbpedia etc.) for such tasks.
ahill: if all we end up with is a bunch of existing standards, do we need to invent something around it
thomas: do we need a version of it, or is it implicit?
<JonathanJ> +1
thomas: do we include the fact that a POI can have more than one category?
danbri: I see that as something implicit
cperey: does this mean that we do not need a core primitive?
<matt> PROPOSED 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 practic
<matt> well as describing how to use Linked Data (skos, dbpedia etc.) for such tasks.
ahill: we may not need to have a structure
cperey: how do we decide it is expressed like that?
ahill: by convention
cperey: is there an action to decide what the convention is?
<danbri> I could write <dbpedia:HotDogStand name="Dan's Eateria" lat="123" long="456"/> ...
<matt> 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> describing how to use Linked Data (skos, dbpedia etc.) for such tasks.
matt: let's go back to an earlier resolution that I wrote a while ago
<matt> RESOLUTION: Category primitive is not required.
danbri: if a POI is a category, it is a boring category. so category is optional
<jacques> amenitie=stand cuisine=hotdog in OSM
<matt> Karl's doc
matt: let's look at the examples
... using URIs makes it easy to refer to categories from dbpedia
cperey: the proposal says one or more, but we just backed of and said none required
... we could have one... a useless one
danbri: that would be just "POI"
cperey: not sure what is the right way of treating it
martin: if you don't want to specify, you should be able to leave i