{"action":"created","issue":{"url":"https://api.github.com/repos/johnwunder/twigs/issues/6","labels_url":"https://api.github.com/repos/johnwunder/twigs/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/johnwunder/twigs/issues/6/comments","events_url":"https://api.github.com/repos/johnwunder/twigs/issues/6/events","html_url":"https://github.com/johnwunder/twigs/issues/6","id":119831277,"number":6,"title":"Aggregation Object?","user":{"login":"terrymacdonald","id":5721772,"avatar_url":"https://avatars.githubusercontent.com/u/5721772?v=3","gravatar_id":"","url":"https://api.github.com/users/terrymacdonald","html_url":"https://github.com/terrymacdonald","followers_url":"https://api.github.com/users/terrymacdonald/followers","following_url":"https://api.github.com/users/terrymacdonald/following{/other_user}","gists_url":"https://api.github.com/users/terrymacdonald/gists{/gist_id}","starred_url":"https://api.github.com/users/terrymacdonald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/terrymacdonald/subscriptions","organizations_url":"https://api.github.com/users/terrymacdonald/orgs","repos_url":"https://api.github.com/users/terrymacdonald/repos","events_url":"https://api.github.com/users/terrymacdonald/events{/privacy}","received_events_url":"https://api.github.com/users/terrymacdonald/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-12-01T23:20:03Z","updated_at":"2015-12-01T23:45:19Z","closed_at":null,"body":"This text below was part of a conversation regarding the need for Organizations to share the number of Observations they have for an Indicator (lets call it sightings_count) without actually sharing the Observables.\r\n\r\nOr to get a little bit crazier, what if we defined an “Aggregation” object to handle the counts?\r\n\r\n* Aggregation\r\n  * id\r\n  * timestamp\r\n  * producer\r\n  * aggregation-type = observation\r\n  * count\r\n  * produced-time\r\n    * from\r\n    * to\r\n* Relationship\r\n  * Id\r\n  * producer\r\n  * timestamp\r\n  * value = matched\r\n  * from_ref = aggregation\r\n  * to-ref = indicator\r\n\r\nAggregation would basically be a stand-in for the aggregation-type. You could also have an “aggregation-detail” relationship maybe to fill in details (actual object details, or when aggregating an incident the incident details).\r\n"},"comment":{"url":"https://api.github.com/repos/johnwunder/twigs/issues/comments/161133477","html_url":"https://github.com/johnwunder/twigs/issues/6#issuecomment-161133477","issue_url":"https://api.github.com/repos/johnwunder/twigs/issues/6","id":161133477,"user":{"login":"terrymacdonald","id":5721772,"avatar_url":"https://avatars.githubusercontent.com/u/5721772?v=3","gravatar_id":"","url":"https://api.github.com/users/terrymacdonald","html_url":"https://github.com/terrymacdonald","followers_url":"https://api.github.com/users/terrymacdonald/followers","following_url":"https://api.github.com/users/terrymacdonald/following{/other_user}","gists_url":"https://api.github.com/users/terrymacdonald/gists{/gist_id}","starred_url":"https://api.github.com/users/terrymacdonald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/terrymacdonald/subscriptions","organizations_url":"https://api.github.com/users/terrymacdonald/orgs","repos_url":"https://api.github.com/users/terrymacdonald/repos","events_url":"https://api.github.com/users/terrymacdonald/events{/privacy}","received_events_url":"https://api.github.com/users/terrymacdonald/received_events","type":"User","site_admin":false},"created_at":"2015-12-01T23:45:19Z","updated_at":"2015-12-01T23:45:19Z","body":"An Aggregation Object is an interesting idea. It could effectively just act as a 'stand-in' for other objects, and allow someone to quickly count up how many times something has been seen without much work or space.\r\n\r\nI wonder though if it adds a bit too much complication. An implementer now needs to maintain these links, in order for someone to properly walk the tree and get the data if they want it. The Aggregation object seems to me to complicate the ability to walk the graph quickly and easily.\r\n\r\nIndicator -----> Aggregation (type Observation) -------> Observation 1\r\n                                             | -------> Observation 2\r\n                                             | -------> Observation 3\r\n                                             | -------> Observation 4\r\n\r\nAlso, what happens if there are different data marking applied to different Observations? Will the producer need to distribute one object for all TLP levels? Or multiple Aggregation objects - one for each TLP level?  How will a recipient find out more about an object they want more info about?\r\n\r\nMaybe, another solution would be to allow Orgs to just send the relationship objects themselves (still fully completed) with no actual Observation object. By fully populating the ID of the Observation the sighting refers to, we allow the receiving Org to know who has the information about the Observation, and they can then request access to the information if they care about it (and it allows the producer to say no). Only sending the relationships keeps the amount of data sent small, and it allows the recipients of the data to create their own internal summary counts of the data they've received.\r\n\r\nPart of the problem that I see is that any summarizing (i.e. count totals) are reliant on the fact that has to be based on the count that the producer knows about, or it can't be done. \r\n\r\n"}}