Phil 7.24.17

I seem to be making $800 mistakes these days. Got the flight information wrong on the flights to HCIC, and this past Saturday I crashed my bike on wet roads, which destroyed the camera I was carrying and my front brake. Here’s hoping that these things don’t happen in threes…

7:00 – 8:00 Research

  • Codev2 by Lawrence Lessig:Lessig’s “Code and Other Laws of Cyberspace” was published in 1999. The book quickly began to define a certain vocabulary for thinking about the regulation of cyberspace. More than any other social space, cyberspace would be controlled or not depending upon the architecture, or “code,” of that space. And that meant regulators, and those seeking to protect cyberspace from at least some forms of regulation, needed to focus not just upon the work of legislators, but also the work of technologists.Code v2 updates the original work. It is not, as Lessig writes in the preface, a “new work.” Written in part collectively, through a Wiki hosted by JotSpot, the aim of the update was to recast the argument in the current context, and to clarify the argument where necessary.
  • More C&C
  • This is tantamount to stating that the social universe resembles the organic universe of Aristotle, in which there can be distinguished a centre and a periphery, a top and a bottom, and a high and a low, rather than the mechanical universe of Newton, homogeneous and lacking any one favoured direction. Without wasting words, we may state that in decision making there is no tabula rasa, any more than there are many decisions that are disputed once they have been taken. [p 113]
  • …consensus polarized in the direction of emerging norms [p 114]
    • Are norms poles that have a position and velocity in belief space? Or are they a manifestation of the group behavior, sort of the position of the average future center (position and variance?) of the group. In other words, do norms have an attraction or are they an implicitly agreed on, emergent, set of beliefs that exist at a certain time? And along these lines, are there patterns that persist over different time spans? I would bet that a circling flock has a centroid of (persistent beliefs), while a stampede doesn’t. This ties back to Arednt’s description of totalitarianism and terror where change is the only constant.
  • On the whole here we are looking at, broadly sketched out, the picture of what must occur when a problem evokes a large-scale movement of opinion. People participate in the debate frequently and with intensity. The series of decisions leading to consensus polarizes towards the norm that is emerging and, by this very fact, emphasizes it. Thus these decisions cause the norm to crystallize and facilitate its being embraced fully by each individual, who feels himself a little its creator. Therefore no coercion or forced consensus should enter into it. [p 117]
    • Support for the idea that the norms are not a pole, but a projection of the future?
  • Attitude polarization, familiarization and group process
  • What happened where a feminist or anti-feminist confederate was present? Of course both were confronting an attitude that had crystallized, had become solidly fixed, and was almost a cultural cliche. The feminist confederate was no longer proposing anything new, but was defending what had become a norm and his or her influence was reinforcing conformity, whereas the anti-feminist confederate seemed to be utterly conservative, a reactionary deviant. Upon examining the data, it was found that their influence had little room in which to be exerted, and that it was weak. Thus the feminist confederates succeeded in polarizing somewhat during the discussion, but to a significant degree (F = 6.56;p < .01), the consensus. On the other hand, the confederate defending an anti-feminist position brought about no reaction, as if this was already ruled out (see Table 5.4). This is why one can no longer observe the former bi-polarization, when the discussions on the status of women set pro-feminists against their adversaries. At any rate the heated atmosphere had cooled down. The researchers noted that there were fewer arguments, and that the discussions were flat and unenthusiastic. An air of nostalgia hung over the groups, who seemed to be asking themselves, ‘But where are the debates of yesteryear?’, just as the poet Villon had once asked, ‘Where are the snows of yesteryear?’ They knew they were waging a fight that had been won by others quite a time ago. [p 120]
    • This would be the old study, where norms are emerging (beliefs in collision): UnstableFlockFormation This would be stable, evolving norms: StableFlock And this would be something like a fixed ideology FixedIdeologyStampede
    • Here’s some charts of ideology in Congress. Picture links to article. The variance is interesting – it implies in the chart on the left that democrats are becoming less diverse, while republicans seem to be breaking into sub-populations(?). polarization

9:00 – 5:00 BRI

  • Need to write up stories
  • Need to discuss refactoring GeocoderService
  • Stories
    • Mock tests for the interface 3 points (fix unit tests)
    • Modify GeoIngestService for document-centric storage of GEM Facts – 5 points
    • Refactor GeoMesaIngestService to GeoMesaDatabaseService – 5 points
    • Business logic for publicly accessible methods
      • Store (produce stunt GEM Json) – 5 points
      • Queries (8 points)
        • By geo coordinate
        • By document and geo coordinate
        • By location name and geo coordinate
      • Deploy – 3 points
  • Wrote teh above up as an email and sent off to Matt
  • Working on getting the json assembled but the serializer is choking on a null elevation. There is a way to get elevation data from Google, but it requires a separate call. Stuffing in zeros for the time being. Oops:
  • private double latitude;
    private double longitude;
    private Double elevation;
  • No, that’s a feature, but the serializer chokes. Not sure what to do and it looks like everyone has left?
  • {
     "name": "elevation",
     "type": ["null", "double"], <- serializer does not like this
     "default": null,
     "doc": "The elevation in meters. May be negative, 0, positive, or null, if unknown."
     }
  • Conversation with Gerard:
    • pfeldman 10:38 AM
      Ok – here’s the issues:
    • Currently Ingest stores people. It can’t NLP provides location information with associated document ID in the GEM message
    • That means that GeoMesaIngest needs to store document and entity information associated with lat/long
    • This can be in GEM format, but that’s a more in-depth discussion
    • The other question is retreival
    • Within the current design, the Threat Assessment Service (TAS) will make a request of the geographic database about information ssociated with a person of interest.
    • The TAS (and the MDS) is where all the information is stored, so the TAS knows how to connect people and documents
    • So for a Geofence request about a person might be “give me all the location names that you have associated with this document” or “give me all the documents that are associated with this location name” or give me everything within this square
    • Is this the sort of query that the IngestService should respond to? Or is this handled somewhere else (GeoServer?)
    • gbriones 10:45 AM

      ingestservice should only worry about ingesting data, nothing else
    • the query should be handled elsewhere
    • pfeldman 10:46 AM

      Then stories need to be written to describe this interaction
    • So then my stories are as follows:
    • 1) Fix GeoCoder and Ingest so that they follow the EIP pattern of interface/implementation that allows for proper unit testing
    • 2) Fix GeoIngest so that it no longer takes in a person Json, but some variant of document/location name/lat-long
    • I think the refactoring is about 3 points, but the second is a good deal of work. I’ll probably need to ask some questions about the best way to store the data to get an idea of how much work it will actually be
    • And then you need the heads up that there is no person information in the GeoDB, just what I listed above.
    • Thoughts?
    • gbriones 10:51 AM

      that makes sense, i’m hoping you’ll have better leverage on getting this working
    • pfeldman 10:53 AM

      leverage?
    • gbriones 10:54 AM

      i am not knowledgeable enough of the architecture to be able to do much of anything for hooking into it
    • james didn’t have the knowledge either, which is apparent lol
    • i find it strange that the code passed review though
    • sean took a look at it a while ago, but i never heard back from him
    • pfeldman 10:55 AM

      Sean doesn’t know the architecture. Matt is the guy for that.
    • gbriones 10:55 AM

      ah, i see
    • pfeldman 10:56 AM

      Yeah, sorry, lots of hidden knowledge
    • If you take a look through confluence, the people who are the authors of the documents tend to be the owners of that knowledge, so that’s a way of figuring out who is responsible/knows what
    • So I would propose changing GeoMesaIngest to a more general service that handles ingest and query response. They are related, and Ingest is a very lightweight thing, even for a microservice
    • gbriones 11:00 AM

      ok, what do you mean by query response? just for clarification
    • pfeldman 11:00 AM

      The TAS will need to make queries of the geographic database
    • By geo coordinate
      By document and geo coordinate
      By location name and geo coordinate
    • something like a LL/UR area
    • gbriones 11:01 AM

      ok
    • pfeldman 11:03 AM

      I think it always returns a list of geolocation/location name/document ID tuples(?), though in reality it may put everything into GEM format
    • But the query has geocoordinate (LL/UR) plus one optional item
    • document or location name
    • maybe wild cards?
    • San F* is the example I was thinking, but that implies a more interactive interface. Is that more of a GeoServer thing?
    • gbriones 11:07 AM

      yeah, i believe it would be
    • pfeldman 11:08 AM

      So how is it thought that GeoServer will work? What are teh scenarios that have been discussed? Is anything written down?
    • gbriones 11:09 AM

      no, i think there will be talks for it, but nothing is currently planned or written down
    • we currently have geoserver up in dev as a way to look at the data on a super simple map
    • pfeldman 11:09 AM

      Can you send a screenshot? Curious
    • gbriones 11:10 AM

      no real ideas of how to integrate the visual aspect into the product right now though
    • let me see if it’s up, i can send you a link if it is
    • pfeldman 11:10 AM

      I am pretty sure that the customer wants to see maps, but there is no requirement *at all*
    • Soooo, back to stories
    • gbriones 11:11 AM

      yes, maps are part of the end goal, but the way of putting the map there is not fleshed out
    • we can use geoserver as a backend (with geomesa) to power the mapping
    • pfeldman 11:11 AM

      But how does it get data that is *only* in the MDS?
    • gbriones 11:12 AM

      the data will have to be ingested into geomesa
    • there’s a geomesa plugin for geoserver that will allow geoserver to look into that data and display it in layers
    • pfeldman 11:12 AM

      Nope. Not going to happen. Duplicate data will break
    • gbriones 11:12 AM

      that’s an issue that we brought up a long time ago
    • pfeldman 11:12 AM

      To who? What was the answer?
    • gbriones 11:13 AM

      here’s the integration document that matt drew up a couple months ago
    • we had a TEM with him about it around the time it was posted and discussed the issues with the approach outlined
    • i agree with you, duplicate data isn’t what we want here
    • but with the current architecture, i’m not sure if there’s a cleaner way of doing it
    • pfeldman 11:14 AM

      Yeah, I’m working from Phase 2 of this doc
    • Note the connection of GeoMesa to MDS in Phase 3
    • gbriones 11:14 AM

      yeah, we brought up the concerns then as well
    • pfeldman 11:16 AM

      So, knowing very little about GeoServer, could it handle a federated query from GeoMesa and MDS?
    • gbriones 11:17 AM

      geoserver should be able to handle that
    • pfeldman 11:18 AM

      Ok, then that’s not a Thing To Worry About Now
    • And back ones more to stories

       

      pfeldman 11:21 AM

      Wow! That’s INCREDIBLE! I’ve never seen such a collection of red dots
    • gbriones 11:22 AM

      tis a beautiful sight
    • pfeldman 11:22 AM

      Transcendental
    • ok, back to stories and points
    • Mock tests for the interface 3 points
      Modify GeoIngestService for document-centric storage of GEM Facts – 5 points
      Refactor GeoMesaIngestService to GeoMesaDatabaseService – 5 points
      Business logic for publicly accessible methodsStore (produce stunt GEM Json) – 5 points
      Queries (8 points)
      By geo coordinate
      By document and geo coordinate
      By location name and geo coordinateDeploy – 3 points
    • thoughts?
    • gbriones 11:25 AM

      that sounds good
    • where are you working on this? machine wise?
    • pfeldman 11:26 AM

      All right, I’ll write those up and submit them on the backlog. I think I’m only going to be able to do the initial refactor to support the EIP pattern before I leave for Oregon. I’ll be back on the 13th, having forgotten *everything*
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: