Comments (3)
Okay, we (@sofie-kemper, @Roger1995, @hechtlC, @bockthom) talked about it and here are the results: We should definitely support this, while the default setting is that the directedness of the networks still is identical with the edge-construction methodology.
Important note
The edge-construction mechanism is referred to as the temporal ordering of the data (or temporally ordered): who answers to whom? or: shall we respect the temporal order of events/data causing edges?
The directedness of the network is referred to directedness (or directed): is the author indicated who caused the event resulting in an edge?
Reasoning and example
When analyzing preferential attachment, we need to consider the in-degree of each node. For this, we need a directed network! Otherwise, the work of oneself would be added to the in-degree, which is definitely not intended. The question is whether temporal ordering and directedness should be the same here. Our impression is: No!
Consider following order/list of e-mails in the same thread to construct a directed network:
Author | Date (Year) | Artifact |
---|---|---|
Alice | 1999 | 1 |
Bob | 2000 | 1 |
Alice | 2001 | 1 |
Charly | 2002 | 1 |
Current result
As we do not distinguish the directedness and the temporal order at the moment, both logical values are identical. As a result, we get a temporally ordered and directed network. The edgelist is the following:
From | To | Date (Year) |
---|---|---|
Bob | Alice | 2000 |
Alice | Bob | 2001 |
Alice | Alice | 2001 |
Charly | Alice | 2002 |
Charly | Bob | 2002 |
When analyzing in-degrees, Charly does not have a good value (it's 0, to be exact), although this does not cover the story of this thread. Charly's contribution may have been huge, but nobody gets that from the current edgelist.
Wanted result
We need to create a temporally unordered, but directed network instead, so that we are able to look at the network of collaborating developers/authors, while we are still able to know who is the source of which edge or caused the event encoded as an edge. This way, Charly's contribution is better respected than before.
The edgelist for such a network is the following, including respecting From
and To
carefully:
From | To | Date (Year) |
---|---|---|
Alice | Bob | 1999 |
Alice | Bob | 2001 |
Bob | Alice | 2000 |
Alice | Charly | 1999 |
Alice | Charly | 2001 |
Charly | Alice | 2002 |
Bob | Charly | 2000 |
Charly | Bob | 2002 |
Schema
In the following, we show the schema defining the edge construction for all combinations of temporally (un-)ordered respect of data and (un-)directed networks.
Raw data
Author | Date (Year) | Artifact/Thread |
---|---|---|
A | 1999 | 1 |
B | 2000 | 1 |
Networks
temporally ordered | temporally unordered | |
---|---|---|
network directed | A ←(2000)– B | A –(1999)→ B A ←(2000)– B |
network undirected | A –(2000)– B | A –(1999)– B A –(2000)– B |
Implementation
The idea is to add two network-configuration parameters, temporally.ordered
and directed
, as a substitute for the current parameters for directedness.
directed.temporal
In the function construct.dependency.network.from.list
, we can remove the argument directed
, which controls the edge-construction mechanism. This can be determined then by getting the temporally.ordered
from the network configuration which is also an argument for the function.
directed.network
When network directedness is enabled, we need to distinguish for each pair/combination of developers (say, A
and B
) under consideration who is the source of an edge.
So, basically, we extract the data items for each developer independently first. Then, we construct edges for each pair (A
, B
), once with all data items from A
and A
as source of the edge, and, finally, the analogous step for B
.
Important: In the end, the directed
parameter determines the directedness of the igraph
object! (see here and here)
Open questions
- Does this approach apply for all kinds of networks or only for author networks? If no, should we enforce the right configuration?
- ...
from coronet.
As already discussed some time ago, we definitively should support all the different combinations of temporal order and directedness. As it recently became apparent that we need the combinations which are currently not supported yet, I started to work on this.
I've already well thought out how to implement this. I plan to implement it in a different way than suggested in the previous comment. The general idea is to change as few parts of the code as possible. Therefore, I will only slightly change several code parts and will make use of the function igraph::as.undirected
at several places.
For the network-configuration parameters, I suggest to keep the name directed
for configuring whether to construct directed or undirected networks. This parameter will behave as hitherto. Moreover, I suggest to name the second parameter respect.temporal.order
, as this might be more comprehensive and less ambiguous as this parameter does not have anything to do with the directedness of a network. The default value of respect.temporal.order
will be TRUE
in the case of directed=TRUE
and FALSE
if directed=FALSE
, so that we keep the former behavior.
I will work on the implementation probably tomorrow. Stay tuned!
from coronet.
Fixed with PR #137.
from coronet.
Related Issues (20)
- Add input validation for setter functions
- Handle empty user correctly
- Filter "deleted user" correctly
- Missing data in `get.first.activity.data` leads to an error
- Tidy-up and optimize source-code inconsistencies
- Enhance `metrics.vertex.degrees` to also be able to compute in-degrees and out-degrees
- Simplified artifact networks have double of their intended edge weights HOT 1
- Test suite fails when using "igraph" versions >= 1.4.0 HOT 1
- Create edges for `artifact relation` `issue` HOT 2
- Tests for functionality in util-networks-misc.R
- Generate coverage reports for our test suite and integrate it into our CI HOT 2
- Error message logging in `metrics.smallwordness` is broken
- Fix edge-attribute handling when simpliyfing networks HOT 8
- Make warnings more uniform HOT 1
- Allow to specify `split.basis` by stating multiple data sources and start splitting according to the earliest data source HOT 4
- Wrong bins attribute after sliding-window-based network splitting & inconsistent behavior of `construct.ranges` HOT 6
- Update deprecated function calls from other packages HOT 10
- `construct.ranges` for cumulative ranges
- Handle mail data of projects that use multiple mailing lists correctly
- Splitting behavior: What to do with elements that occurred before the predefined splitting bins? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coronet.