Points of Interest Working Group Teleconference

21 Sep 2011

See also: IRC log


Alex, Matt, Raj, Rob, Christine


trackbot, start meeting

<trackbot> Date: 21 September 2011

<robman> evening all

<robman> i'll use skype either way

<ahill2> call me at alexshill1

<ahill2> Yes, I am too close to the trees to ever see that forest

<ahill2> http://www.w3.org/2010/POI/wiki/Data_Model

<scribe> scribe: Matt


ahill2: We've got a new data model UML. Nothing has change drastically.
... We've added a lot of things like term and scheme to lots of bits. Cleaned up some of the geometry stuff.
... Added terms and schemes to times, and did a bit with time.
... Not terribly important to what we are discussing though.
... Big topics on our mind is how to we get href into the mix.


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

robman: That's a great use case for address, we use that a lot to update moving users.

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.
... We could similarly tack an href in there.

ahill: How do you build links into the model as the critical path to getting things done.
... 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?

robman: I think the idea of using the href on some of the primitive elements was a good half-way step.
... Serialize it inline, and have the href.
... href is like provenance to me.
... It would be good to have a canonical source, which is usually href. And having IANA (mime?) types on all of those things.

<robman> http://www.iana.org/assignments/link-relations/link-relations.xml

ahill: With link we have the authoritative IANA stuff.
... 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?

robman: Other browsers would recognize them. They're really designed as a link rel type.

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.

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.

ahill: What happens if we start using something?

robman: You can request IANA to make a new one.

matt: You can make stuff up and it won't choke, it's just it won't make sense of it.

ahill: If, some day, we could make small changes to our spec to make it work in browsers.
... Without serializing in line, we end up almost with two sort of approaches:
... 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.

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.

<rsingh2> plus a type (MIME type) attribute?

<robman> http://www.w3.org/TR/html5/links.html#link-type-author

ahill: Can you talk about how atom and html link work together?

robman: I think they've done their own implementation in their own namespace.

<robman> http://tools.ietf.org/html/rfc4287#section-4.2.11

<robman> poi:link

robman: We could make our own link element that has our own rules.

matt: We could just make a new serialization to our stuff into HTML 5.

robman: Make it CDATA or something parseable inside HTML 5. It doesn't mean we have to break our whole model to do that.

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.

robman: Like an alternate relation. Rather than trying to put a POI in the HTML 5 DOM.

ahill: We're creating a barrier, but not shoe horning it in.

robman: A question about the data model...

-> http://www.w3.org/2010/POI/wiki/images/b/bb/W3c_poi_model_v1.png UML Data model

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.

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?

-> http://poi.womer.org:9001/p/poi-scratch scratch pad

<robman> html5 DOM -> pois -> poi -> link rel=alternate [3d|image]

ahill: So within the data model we might have links to the model for the POI.

robman: If we use just a link in HTML5, the POI itself won't be in the HTML DOM, it's a separate document.

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.

robman: Similar to KARML, you've written a bridge that takes the KML and transforms them into DOM elements.
... If we do this, then that's the only way we could do that.

rsingh2: I thought using links was going to help us go to RDF triplets.

robman: Yes, a separate conversation, links are similar to RDF basically.

rsingh2: I was hoping link would get us closer to RDF.

ahill: Let's push that down a bit.

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?

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.
... 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.

matt: We could also consider how to embed the POI XML directly into HTML itself. Namespaces, ick.

ahill: You could have the link at the POI level that was to JavaScript that was the execution environment, similar to KARMA?

robman: That's feasible.

<robman> http://tools.ietf.org/html/rfc4287#section-3.1

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.

robman: So, if we had a link tag we could do something similar.

ahill: If we say it's the same link element, then we don't need this work around, right?

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.
... 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.

ahill: If you have a link element in your POI, then you'd --

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.

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?
... 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?
... If it's just POI processors, they're going to have to figure out what to do with it like anything else.
... What do we get?

rsingh2: It's something that others have thought about and we can reuse.

ahill2: If POIs are just link elements, I need justification for that.

robman: By using just link itself, then we don't have to define all of those different primitives.
... link keeps the data model extensible too.

-> http://poi.womer.org:9001/p/poi-scratch POI Scratchpad

<robman> http://www.google.com/support/webmasters/bin/answer.py?answer=139394

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.

robman: A location without a point is meaningless to me, but a polygon isn't a location.

ahill: Take the poly and find a centroid.
... 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.
... I agree that polygon doesn't sound like a location.

robman: Say there was a representation, you don't want to move all points when you move, but move them relative to the origin.
... I think we should have a point required.

rsingh2: It's unintuitive from a geo point of view. Points are less of a good attempt at describing a place than a polygon.

robman: I've had lots of discussions with surveyors, and they find too much detail difficult.

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.
... 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: <link rel="canonical" could update that, <link rel="author" is the author of this location, and <link rel="last updated" would be...

ahill: Do we have that?

matt: We made time a term/scheme thing.

rsingh2: We wanted time on everything but we only have it on POI.

matt: That's just where we happened to leave it when we left.

rsingh2: I think this might end up incredibly messy to have links and times everywhere.

ahill: There's an argument for it being easier actually, the data model ends up simpler.
... 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.

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.
... I guess there are already lots of implied values in XML, etc.

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.

[[<?xml version="1.0" encoding="UTF-8"?>


<poi id="StataCenter" xml:lang="en-US" >


[[discussion of id as an element, implied from base, set from link rel="canonical", etc ]]

<robman> A "canonical" URI is the preferred version of a set of URIs

<robman> with highly similar content. It is intended to help search

<robman> engines when the same or highly similar similar content is

<robman> available at different URIs.

<robman> *R*

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.

-> http://www.w3.org/2010/POI/wiki/Face_to_Face_Meetings/September_2011/Notes Unformatted notes from link/id discussion

<robman> hey matt/ahill2 are you guys still there?

<robman> i just had a duh! moment 8)

<robman> id's make perfect sense when the entity is part of a collection

<robman> e.g. it allows you to dereference one item within a list

<robman> e.g. poi within a pois collection


<robman> href is perfect for when you want to point to a network source

<robman> like Location, Auther

<robman> no worries

Yep. I was unconvinced that <pois href=""> was a good idea.

<robman> just wanted to write that down while it was clear 8)

Roger that. ttyl!

<robman> boi


-> http://en.wikipedia.org/wiki/Decorator_pattern Decorator Pattern

-> http://tools.ietf.org/html/rfc4287#section-4.2.7 atom:link

-> http://dublincore.org/documents/dcq-html/ Dublin Core in HTML

-> http://www.opengeospatial.org/standards/requests/79 GML 3.3 request for comments

Things that need to be done to draft

ahill2: 1. Make the UML proper UML that reflects our intentions
... 2. Figure out href on location for representing moving POIs?

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.
... e.g. the POI name might be represented as a label in UML, and in XML that might be <label value="poi name"/> -- that doesn't' mean that address, which is also a UML label, will be "<address value='…'"/>
... In fact, in address we likely want to preserve whitespace, and thus have the label's value as cdata.
... But, the distinction between the abstract data model and the serializations has been a huge source of confusion.
... I'll work on massaging the UML into the prose text that follows.

<scribe> ACTION: Matt to update data model description to be in sync with UML diagram developed at f2f [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action01]

<trackbot> Created ACTION-105 - Update data model description to be in sync with UML diagram developed at f2f [on Matt Womer - due 2011-09-28].

<scribe> ACTION: Matt to update POI home page [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action02]

<trackbot> Created ACTION-106 - Update POI home page [on Matt Womer - due 2011-09-28].

<scribe> ACTION: Matt to setup/teach w3c CVS to Alex [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action03]

<trackbot> Created ACTION-107 - Setup/teach w3c CVS to Alex [on Matt Womer - due 2011-09-28].

<scribe> ACTION: Alex to cleanup ether pad notes (discussion on links, time, embedding in HTML, alternate representations, etc) and post a blog entry [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action04]

<trackbot> Created ACTION-108 - Cleanup ether pad notes (discussion on links, time, embedding in HTML, alternate representations, etc) and post a blog entry [on Alex Hill - due 2011-09-28].

<scribe> ACTION: matt to paste ether pad notes into wiki and turn to wiki format [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action05]

<trackbot> Created ACTION-109 - Paste ether pad notes into wiki and turn to wiki format [on Matt Womer - due 2011-09-28].

Summary of Action Items

[NEW] ACTION: Alex to cleanup ether pad notes (discussion on links, time, embedding in HTML, alternate representations, etc) and post a blog entry [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action04]
[NEW] ACTION: matt to paste ether pad notes into wiki and turn to wiki format [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action05]
[NEW] ACTION: Matt to setup/teach w3c CVS to Alex [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action03]
[NEW] ACTION: Matt to update data model description to be in sync with UML diagram developed at f2f [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action01]
[NEW] ACTION: Matt to update POI home page [recorded in http://www.w3.org/2011/09/21-poiwg-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2012/08/02 15:47:02 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_HTML_Format (score 1.00)

Succeeded: s/ahill/robman/
Found Scribe: Matt
Inferring ScribeNick: matt
Present: Alex Matt Raj Rob Christine
Found Date: 21 Sep 2011
Guessing minutes URL: http://www.w3.org/2011/09/21-poiwg-minutes.html
People with action items: alex matt

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]