13:59:11 RRSAgent has joined #poiwg 13:59:11 logging to http://www.w3.org/2011/09/21-poiwg-irc 14:01:07 trackbot, start meeting 14:01:09 RRSAgent, make logs public 14:01:09 Zakim has joined #poiwg 14:01:11 Zakim, this will be UW_POI 14:01:11 I do not see a conference matching that name scheduled within the next hour, trackbot 14:01:12 Meeting: Points of Interest Working Group Teleconference 14:01:12 Date: 21 September 2011 14:03:14 ahill2 has joined #poiwg 14:07:01 zakim, room for 5? 14:07:03 ok, matt; conference Team_(poiwg)14:07Z scheduled with code 26633 (CONF3) for 60 minutes until 1507Z 14:07:21 zakim, code? 14:07:21 the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), matt 14:07:37 Team_(poiwg)14:07Z has now started 14:07:44 +??P1 14:15:17 evening all 14:15:58 i'll use skype either way 14:17:13 call me at alexshill1 14:18:25 Yes, I am too close to the trees to ever see that forest 14:19:25 http://www.w3.org/2010/POI/wiki/Data_Model 14:20:03 scribe: Matt 14:20:08 Topic: Recap 14:20:23 ahill2: We've got a new data model UML. Nothing has change drastically. 14:20:47 ahill2: We've added a lot of things like term and scheme to lots of bits. Cleaned up some of the geometry stuff. 14:21:00 ahill2: Added terms and schemes to times, and did a bit with time. 14:21:13 ahill2: Not terribly important to what we are discussing though. 14:21:35 ahill2: Big topics on our mind is how to we get href into the mix. 14:22:12 Topic: Link 14:22:25 zakim, end meeting 14:22:25 I don't understand 'end meeting', matt 14:22:28 zakim, drop all 14:22:28 sorry, matt, I do not see a party named 'all' 14:22:34 zakim, drop ??p1 14:22:34 ??P1 is being disconnected 14:22:36 Team_(poiwg)14:07Z has ended 14:22:36 Attendees were 14:22:57 rsingh2 has joined #poiwg 14:23:35 ahill2: In my mind, it would be nice if there were hrefs in our data model in places where we could sort of point to the canonical source of something and it'd be neat if we could get the serialized data and then turn around and get the data from a URL for a subpart of the POI, not the whole POI necessarily 14:24:07 robman: That's a great use case for address, we use that a lot to update moving users. 14:24:39 ahill2: The way our discussions are going, we're going to end up tacking on provenance data like source on to a lot of these elements. 14:24:45 ahill2: We could similarly tack an href in there. 14:25:24 ahill: How do you build links into the model as the critical path to getting things done. 14:25:53 ahill: If I make a very basic POI -- we discussed a lot yesterday how easy it should be to write out a POI -- do we have to end up with something that has link everywhere? Highly overloading link? Or can we have an either or? 14:26:08 robman: I think the idea of using the href on some of the primitive elements was a good half-way step. 14:26:17 robman: Serialize it inline, and have the href. 14:26:25 robman: href is like provenance to me. 14:26:54 robman: It would be good to have a canonical source, which is usually href. And having IANA (mime?) types on all of those things. 14:27:19 http://www.iana.org/assignments/link-relations/link-relations.xml 14:27:21 ahill: With link we have the authoritative IANA stuff. 14:27:44 ahill: Do we need a link there? What does it mean if we overload our elements with the properties of link. What are the benefits and tradeoffs of that? 14:28:12 robman: Other browsers would recognize them. They're really designed as a link rel type. 14:28:49 ahill: So what you're saying is we can do what we want, but if we want things that people have actually written in the POI spec to be ingested and handled correctly by something like an HTML5 browser then we have to take a difference approach. 14:29:31 robman: HTML 5 compatibility is a really good goal. I had a discussion about reasons why the inline serialization model is a bad idea, and there is philosophical reason for it being a bad idea, but the current syntax rule for HTML 5 won't allow it for link. 14:30:20 ahill: What happens if we start using something? 14:30:26 robman: You can request IANA to make a new one. 14:31:11 matt: You can make stuff up and it won't choke, it's just it won't make sense of it. 14:31:26 ahill: If, some day, we could make small changes to our spec to make it work in browsers. 14:32:17 ahill: Without serializing in line, we end up almost with two sort of approaches: 14:32:36 ahill: One where we've taken a location element with attributes from link for attribution, src, etc, and I'm wondering if there's a middle ground. 14:33:12 robman: I think adding the href to the primitives give you the concept of a link, and I think that's a good suggestion anyway. And for the relationships that have already been defined such as author, it makes sense to use those that are already defined. 14:33:36 plus a type (MIME type) attribute? 14:33:52 http://www.w3.org/TR/html5/links.html#link-type-author 14:34:50 ahill: Can you talk about how atom and html link work together? 14:34:59 robman: I think they've done their own implementation in their own namespace. 14:35:22 http://tools.ietf.org/html/rfc4287#section-4.2.11 14:36:12 poi:link 14:36:35 robman: We could make our own link element that has our own rules. 14:37:21 matt: We could just make a new serialization to our stuff into HTML 5. 14:37:38 robman: Make it CDATA or something parseable inside HTML 5. It doesn't mean we have to break our whole model to do that. 14:38:42 matt: I think if we establish a link rel for HTML to grab a POI externally, is the base level we should strive for wrt HTML 5. 14:39:00 robman: Like an alternate relation. Rather than trying to put a POI in the HTML 5 DOM. 14:39:14 ahill: We're creating a barrier, but not shoe horning it in. 14:39:20 robman: A question about the data model... 14:39:28 -> http://www.w3.org/2010/POI/wiki/images/b/bb/W3c_poi_model_v1.png UML Data model 14:40:00 robman: One of the ideas for suggesting the link model: the same way an HTML doc can have a rel=alternate, having the POI have the same thing that lets you point to an image, or media that represents POI. 14:40:47 ahill: The question is how do we make a connection between a 3d model and a POI? Do we need those links inside of the POI? 14:41:11 -> http://poi.womer.org:9001/p/poi-scratch scratch pad 14:41:14 html5 DOM -> pois -> poi -> link rel=alternate [3d|image] 14:42:38 ahill: So within the data model we might have links to the model for the POI. 14:43:32 robman: If we use just a link in HTML5, the POI itself won't be in the HTML DOM, it's a separate document. 14:45:37 ahill: We're not really getting much out of talking about HTML5 -- we're not talking about having it interpreted in an HTML context anymore. 14:45:57 robman: Similar to KARML, you've written a bridge that takes the KML and transforms them into DOM elements. 14:46:07 robman: If we do this, then that's the only way we could do that. 14:46:43 rsingh2: I thought using links was going to help us go to RDF triplets. 14:46:52 robman: Yes, a separate conversation, links are similar to RDF basically. 14:47:02 rsingh2: I was hoping link would get us closer to RDF. 14:47:07 ahill: Let's push that down a bit. 14:48:12 ahill2: I want to figure out to the extent that we need to use the term link. Are we just copying it into the POI data model? If we use the exact link element and it's syntax, do we gain something? 14:48:15 robman: If you look at the way atom did that, you benefit from the design intention, history and thought that comes with the link element itself. 14:49:04 robman: If we took the HTML 5 version, it'd be very feasible to just have a javascript bit that loads the documents and transforms them into DOM elements. 14:49:37 matt: We could also consider how to embed the POI XML directly into HTML itself. Namespaces, ick. 14:49:58 ahill: You could have the link at the POI level that was to JavaScript that was the execution environment, similar to KARMA? 14:50:03 robman: That's feasible. 14:52:16 http://tools.ietf.org/html/rfc4287#section-3.1 14:54:55 matt: So you have an atom:title embedded in HTML, but they both have a title tag in it. So, it's an atom:title but with a flag that says it's HTML, so the content is different, it has no child elements, everything has to be escaped, etc. 14:55:04 robman: So, if we had a link tag we could do something similar. 14:55:50 ahill: If we say it's the same link element, then we don't need this work around, right? 14:56:14 robman: We could have this external POI document, consumed by a POI parser, etc. But then you're asking how we get those data structures into the DOM. 14:56:36 robman: Those elements could be manipulated in the DOM. The way atom achieved this was to use an atom:title that could be serialized into HTML. 14:58:12 ahill: If you have a link element in your POI, then you'd -- 14:58:31 matt: I think we've got a bit of a disconnect. We can have both a link element, and hrefs on our primitives. The link could be identical to HTML5. 14:59:01 ahill: Right, so if we had something a bit more verbose because we rely heavily on the link element. What did we gain from that? 14:59:42 ahill: So if we do this link thing identical to HTML5, who is going to do this work to bring it in? Is the answer nobody? 15:00:02 ahill: If it's just POI processors, they're going to have to figure out what to do with it like anything else. 15:00:20 ahill: What do we get? 15:00:32 rsingh2: It's something that others have thought about and we can reuse. 15:00:45 ahill2: If POIs are just link elements, I need justification for that. 15:01:06 ahill: By using just link itself, then we don't have to define all of those different primitives. 15:01:11 s/ahill/robman/ 15:01:21 robman: link keeps the data model extensible too. 15:02:00 -> http://poi.womer.org:9001/p/poi-scratch POI Scratchpad 15:02:22 Present: Alex, Matt, Raj, Rob, Christine 15:03:18 http://www.google.com/support/webmasters/bin/answer.py?answer=139394 15:24:05 ahill: Raj said yesterday that GeoRSS has support for polygons, but no one uses it, so that'd be a case for not having a poly being a location. But, what about things like geofencing? Maybe it's not a location per se, for rendering or directions, but it could be a valuable data structure that people leverage. 15:24:32 robman: A location without a point is meaningless to me, but a polygon isn't a location. 15:24:54 ahill: Take the poly and find a centroid. 15:25:35 ahill: Now if we haven't done you that favor of sending it to you already, then maybe that's a problem for you, but usually, we'll send you that point too. And the UML nicely says "This point is the top of the spire", "This point is where you enter on foot", etc. 15:25:50 ahill: I agree that polygon doesn't sound like a location. 15:26:29 robman: Say there was a representation, you don't want to move all points when you move, but move them relative to the origin. 15:26:53 robman: I think we should have a point required. 15:27:11 rsingh2: It's unintuitive from a geo point of view. Points are less of a good attempt at describing a place than a polygon. 15:27:34 robman: I've had lots of discussions with surveyors, and they find too much detail difficult. 15:28:42 rsingh2: Back to links. We come up with elements or attributes for stuff we really care about, and then links for things that might be more general, things like authorship, etc. 15:29:45 rsingh2: So, one use of link we could have in there is the link that you update. Other uses of links on that element would be very different: ahill: Do we have that? 15:29:56 matt: We made time a term/scheme thing. 15:30:12 rsingh2: We wanted time on everything but we only have it on POI. 15:30:25 matt: That's just where we happened to leave it when we left. 15:30:37 rsingh2: I think this might end up incredibly messy to have links and times everywhere. 15:30:48 ahill: There's an argument for it being easier actually, the data model ends up simpler. 15:31:34 ahill: As it is, we're finding our UML having a lot of complexity, if we can offload that into something people understand and we can reappropriate there are some advantages to that. 15:31:50 rsingh2: If you filled out everything, it would be very messy, but really no one would do that. I guess that's a good pattern. 15:32:31 rsingh2: I guess there are already lots of implied values in XML, etc. 15:32:50 matt: There's also a lot of common attributes that could make HTML documents super ugly too, like style on everything. It's out there, doesn't mean it has to be done. 15:35:13 [[ 15:35:14 15:35:15 15:35:16 ]] 15:36:06 [[discussion of id as an element, implied from base, set from link rel="canonical", etc ]] 15:41:30 A "canonical" URI is the preferred version of a set of URIs 15:41:30 with highly similar content. It is intended to help search 15:41:30 engines when the same or highly similar similar content is 15:41:30 available at different URIs. 15:42:55 *R* 16:16:49 robman: Let's turn these fragments into examples that we can point to, and write a blog post/email about these examples and how these things differs, etc. A lot of the discussions around URIs, we spent a lot of time saying "this one, or that one", but instead having a permalink is good. 16:17:15 danbri has joined #poiwg 16:24:45 -> http://www.w3.org/2010/POI/wiki/Face_to_Face_Meetings/September_2011/Notes Unformatted notes from link/id discussion 16:28:47 hey matt/ahill2 are you guys still there? 16:29:01 i just had a duh! moment 8) 16:29:15 id's make perfect sense when the entity is part of a collection 16:29:26 e.g. it allows you to dereference one item within a list 16:29:35 e.g. poi within a pois collection 16:29:37 Right! 16:29:48 href is perfect for when you want to point to a network source 16:30:00 like Location, Auther 16:30:03 no worries 16:30:07 Yep. I was unconvinced that was a good idea. 16:30:11 just wanted to write that down while it was clear 8) 16:30:15 Roger that. ttyl! 16:30:20 boi 16:49:05 Zakim has left #poiwg 17:17:52 danbri has joined #poiwg 17:41:23 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cpoi%3Apois%3E%0A%3Cpoi%3Apoi%3E%0A%20%20%3Cpoi%3Alocation%3E%0A%20%20%20%20%20%20%3Cpoi%3Apolygon%3E%3C%2Fpoi%3Apolygon%3E%0A%20%20%20%3C%2Fpoi%3Alocation%3E%0A%3C%2Fpoi%3Apoi%3E%0A%3C%2Fpoi%3Apois%3E 21:27:37 RRSAgent has joined #poiwg 21:27:37 logging to http://www.w3.org/2011/09/21-poiwg-irc 21:27:47 rrsagent, draft minutes 21:27:47 I have made the request to generate http://www.w3.org/2011/09/21-poiwg-minutes.html matt 21:28:00 rrsagent, make logs public 21:28:13 Chair: Alex 21:31:31 -> http://en.wikipedia.org/wiki/Decorator_pattern Decorator Pattern 22:07:26 -> http://tools.ietf.org/html/rfc4287#section-4.2.7 atom:link 22:13:31 -> http://dublincore.org/documents/dcq-html/ Dublin Core in HTML 22:14:08 rsingh2 has joined #poiwg 22:48:29 -> http://www.opengeospatial.org/standards/requests/79 GML 3.3 request for comments 22:49:53 ahill2 has joined #poiwg 23:04:58 Topic: Things that need to be done to draft 23:05:33 ahill2: 1. Make the UML proper UML that reflects our intentions 23:08:32 danbri has joined #poiwg 23:12:50 ahill2: 2. Figure out href on location for representing moving POIs? 23:17:55 matt: I'd like someone to help me with text about how the data model is not structurally 1-1 UML member->XML element or attribute per se. 23:18:46 matt: e.g. the POI name might be represented as a label in UML, and in XML that might be