See also: IRC log
<trackbot> Date: 19 September 2011
<scribe> Meeting: POI F2F 2011 #2
<scribe> Meeting: POI F2F 2011 #2 Day 1
[[morning spent refreshing ourselves on status, thoughts on changes, etc]]
<scribe> scribe: Matt
-> http://microformats.org/wiki/existing-rel-values rel value registry (not IANA)
-> http://www.iana.org/assignments/link-relations/link-relations.xml IANA rel types
Karl: When we get into discussions about links and attributions, and then we talk about what's a label, etc, we're too much mixing data types and primitives.
... So, all of our high level attributes are made up of these primitives, and we assemble them in certain ways. A location might have a type of a property/value pair and a label for instance.
... The domain of POI is: ID, Name, Location, Category, Contact… but there is this "other" stuff. We will assemble our stuff out of our data types, but other things we'll tell them to use an link triple, or whatever assembly we have.
... Alex suggests we explicate the assembly, and leave the 'others' to others.
matt: I think what lead to confusion was that 'label' was both a primitive and a data type. In my head it was clear we had data types, primitives and then serialization that represents these in XML, RDF, whatever.
Raj: I think we can take these primitives, do the ones that are core to us, and do them in the Core.
Alex: How does the work that Raj and Matt have done, where they reworked some GML into the spec, can that be reworked into primitives?
Raj: The five that are in there, Point, String, Line, Polygon and Box, are in our mindset very primitive. We've got arcs, holes in polys, etc.
Karl: for instance, a location can contain a point, which to us is a primitive, and is defined elsewhere (OGC).
Raj: Let's look at a use case: emergency stuff: I've got use cases of "these people are in need of water", what is the assembly for that?
Karl: Those assemblies would be in a profile. Say you want to get them to a camp, that'd be a POI.
Raj: I'm thinking someone in need of help is a POI, say in a rescue center.
Alex: I'm not understanding the assembly.
Karl: Using the camp as an example -- it's a collection of POIs. There's an owner POI that has a relationship to children POIs -- e.g. where do I get food, water, whatever. All of those have locations that can be a position, address, relative offset ('around the corner from the entry'), and then descriptors contain what services can be provided at this POI.
Raj: So the descriptors are the assembly.
Karl: Yes. In our case we're going to provide an assembly for a set of common triples within our domains.
-> http://poi.womer.org:9000/JD76tkjA1z Editing notes
Alex: The notion of place and POI being different has changed within the group, let's merge some of the semantics of place into the POI definition and drop places.
RESOLUTION: Remove notion of place, merge concepts into POI
Karl: Can POI's change locations? We say "rarely changes".
Alex: We can make it into "locations change: technologies enable better resolution, places move, etc"
Christine: Let's just say POIs may move.
Alex: How do we render routes?
Matt: What about the route being a POI with a location line string, and a bunch of relationships to POIs that are the stops.
Karl: COuld do that or have them just as a directed list of POIs.
Alex: When are we using lines?
Karl: Routes.
Raj: And it mirrors GeoRSS.
Karl: Traffic.
Alex: Aren't they polys in some sense?
Karl: Usually a list of POI road segments augmented with the reason or level of impediment, etc.
<scribe> ACTION: matt to move OGC terminology suggestions into references section or appendix [recorded in http://www.w3.org/2011/09/19-poiwg-irc]
<trackbot> Created ACTION-103 - Move OGC terminology suggestions into references section or appendix [on Matt Womer - due 2011-09-26].
matt: We should always be able to scale in lots of ways: city vs national, small datasets vs large, etc.
Karl: Thinking about the list of POI parts, contact is weak compared to the rest, but things like every parking meter, has a contact.
Christine: Shouldn't it be a relationship? It's various types of data, phone, email, name, etc.
... Perhaps another term? admin unit or something?
Karl: The most common contacts will be a phone or URL.
Alex: Perhaps attribution?
... "This POI was made by this person", "This POI was generated by this org", "If need to contact someone about a POI, contact here". I think there is attribution stuff, but contact is in the 'other' section rather than attribution.
Raj: I'm interested in this, but we should table it. I'm very interested in working on provenance.
Alex: Do we agree that there is a distinction between provenance/attribution and contact information?
... It's easy to envision a future of no phone numbers.
Karl: Addresses are the same way.
Alex: I suggest that phone number information is extra data.
ISSUE: How do we handle provenance and other attribution type data?
<trackbot> Created ISSUE-48 - How do we handle provenance and other attribution type data? ; please complete additional details at http://www.w3.org/2010/POI/track/issues/48/edit .
<scribe> ACTION: Raj to work on ISSUE-48 and propose some answers [recorded in http://www.w3.org/2011/09/19-poiwg-irc]
<trackbot> Created ACTION-104 - Work on ISSUE-48 and propose some answers [on Raj Singh - due 2011-09-26].
Raj: Let me make a case for having update information in the required core.
... If you don't know how it's updated, you have to query frequently.
matt: Would we cram it into the XML, or in the HTTP envelop?
Raj: If you're doing HTTP you should put it in the headers, rather than in the body, but if you're offline, you need it in the XML.
Matt: Agreed.
-> http://tools.ietf.org/html/rfc4287#section-4.2.15 Atom updated element
Alex: What are we talking about being updated? The whole POI? Matt once brought up this attribute on every element.
... What mechanism can we construct that will let one know when it was updated and the individual parts? Meta tags?
Karl: Right, you want change tracking on the element level. That goes on a lot right now. You don't want to be information lossy. Say, something changes a category, that's a huge change that could force complete reprocessing, while cutting off the "Inc." in a name might not.
matt: I was thinking we should make it simple to keep it from having to have an "updated" attribute required on every element. Use HTTP for the whole doc, updated on the <pois> itself means everything is updated, start from scratch, and if it isn't there, follow lexical parsing of XML to have reasonable defaults if specified, e.g. if <pois> has an updated attribute, it applies to all sub elements. That way you can put an attribute of updated on *just* a name, or
a whole doc or a single POI.
Alex: RIght now we just have it at the POI level, but we should have it on everything.
Matt: Right.
Karl: Take something like a name: you have alternative names, you can declare the language and last change/update and the source/provenance.
Martin: We said POIs might contain multiple POIs, but maybe we shouldn't.
Matt: That was a decision made long ago. It wasn't intended to imply a relationship between the POIs contained within, it's just a container.
Martin: If we have this collection, say a house changes it's label, how do we update that and somehow notify the parent?
... Is it important to the POI Denver that the house's POI changed?
Alex: In general, I think it doesn't need to bubble up to the parent POI.
Karl: We're talking as a relationship really. And that deals with inheritance.
Alex: If we resolve that we can add update and provenance like stuff to any element, we don't have to resolve how that inheritance.
matt: This very much reminds me of the arguments at the origin of the Web with the hypertext folks, who found a one way link abhorrent. Turns out 404's aren't the end of the world. We can make parent/children links, but it shouldn't be the end of the world if it breaks.
Martin: If the house changes, Colorado shouldn't.
Karl: When we create these types of relationships we should declare how it inherits.
... e.g. I'm a Starbucks linking to data from Starbucks corporate. If we're looking for the 800 number for them, we want it updated.
Alex: We touch on this a bit: in the draft we propose IANA registry for parent/child relationships.
... It's murky, and it's something I hope we'll touch on here. Let's try to do some use cases while we're here.
Karl: Let's talk about building blocks. Language, updated...
Alex: href...
Matt: link semantics
Alex: Rob's link proposal, I was thinking all of our elements may have an href. location could have an href for the source. I'm agreeing that we need to figure out how we're going to do all that. We have a lot of attributes we want to attach to these things.
RESOLVE: A POI is a specific point location that someone may find useful or interesting
Karl: We're thinking we're going to cherry pick some relationship predicates from RDF.
... e.g. memberOf, brand associations, etc.
Alex: Why is relationship moved out of location?
... and why is reference added?
Karl: It's a bit of a journey. The relationships for locations should be spatial, the relationships in categories are categorical.
... Can't a location just be a reference?
Alex: That was going to be one of my suggestions, a location that is nothing but an href, that could handle the moving case for instance.
Karl: If a POI and a category can have an ID, shouldn't a location also have it.
Alex: Trying to get my head around some of the related terms we have.
... Category for instance has a scheme. As long as we can get that terminology down we can get closer to a meta model. It seems like there are a lot of places we need this (href, ids), and it seems like it's what the link element is intended to handle for instance.
... We're coming at it from two ends.
Matt: We sort of want to location types be primitives too that are assembled out of data types, e.g. a poly is a GML Poly plus an href and an updated attribute.
Alex: I'm coming around to this, I think we can still get it down to something pithy.
Raj: We have to make sure it can devolve easily. It can have an href, but you should be able to do the offline thing, so a location has a value, with an href that can be used or not.
Alex: Yes, we're trying to get the best of both worlds, and I think we can.
Matt: I think we need to get on the same page with terminology, instead of getting confused every time.
Alex: I think that's a good goal of this f2f.
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/attribute/element/ Found Scribe: Matt Inferring ScribeNick: matt Present: Christine_Perey Matt_Womer Alex_Hill Martin_Lechner Karl_Seiler WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 19 Sep 2011 People with action items: matt raj WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]