segunda-feira, 4 de novembro de 2019

istar/MREBA Joint Keynote@ER 2019 - Inter-Organizational Data Sharing: From Goals to Policies to Code - By Matthias Jarke

Inter-Organizational Data Sharing: From Goals to Policies to Code
By Matthias Jarke
iStar - MREBA Joint Keynote @ER2019


He presented a very interesting table showing the business ecosystems issues that the IDS initiative aims at addressing:



----


He presented some requirements w.r.t data sharing in business ecosystems (Otto/Jarke 2019).



----


Dependency Structure in Collaborative Data Sharing generate some obstacles:
- hierarchical or competitive behavior drive people to deny sharing data.
- sometimes, data may be only used for some processes (e.g. for management, but not for purchasing and sales)
- sometimes, data must be deleted within a certain period of time.

----

From Access Control to Data Usage Control - The data usage goals are not achievable by Access Control alone.

These goals are:
Secrecy
Integrity
Time to live
Anonymize (aggregation)
Anonymize (replacement)
Separation of duties
Usage scope (application)

He showed a model called XACML - Access Control Data Flow Model
*it seems very interesting
----

There must be a gradual automation and regulation and contracts for Data Sharing. This is the only way to guarantee that it is going to work effectively.

----

Different kinds of technologies may be used to alleviate the delays of the different policies (e.g. secrecy, integrity etc.). These may really slow down the database system. Thus, technologies like annotation-based systems that will provide quick response instead of delays may be used, so as to optimize the process of data access.

----

Elaborated Role-Dependency Structure in the International Data Spaces (IDS) Reference Architecture Model (Otto 2019)
This work is based on a more elaborate kind of i* model.

----

Semantic Interoperability 

Mapping Specification
- Metamodeling approach - deductive database formalisms enhanced by (second-order) TGDS (CLIO), or Telos multi-level language enhanced by SO-TGDS and factored by roles (GeRoMe)
 The first metamodeling techniques were not so sophisticated as the modern ones. You must be careful not to get to undecidable scenarios, as the model gets more complex.

- Ontology-based mapping - DL based approaches (Lenzerini et al.) or RDF-based probabilistic knowledge graph schemes.

Mapping Creation and Analysis
- Mapping Discovery (see talk by Rihan Hai at ER 2019)
- Analysis (consistency, completeness)
- Model-managed



---

Semantic Perspective on Data Sharing (Lenzerini 2019): Mapping Between (Pre-defined or Mined) Schemes.
*This is a must-read reference

---

Outline of work in this topic

Requirements

  • Trust among members
  • Data sovereignty - who owns the data? 
  • Shared governance
  • Interoperability
  • Compliance with antitrust legislation
  • Data economics - money sharing while data is shared.


Recently a number of alliance driven platforms developed in contrast to typical keystone driven platform.
Companies feel they must collaborate in these ecosystems and they develop joint platforms that put them in the center of the ecosystem to which they belong.

The IDS initiative may also contribute to a digital infrastructure by addressing its data layer.

Virtual Hyperscaler for Obtaining Performance in Alliance-driven Data Ecosystems.

----

Q&A

Eric: in which areas can iStar contribute more?
Answer: This area includes an agent dependency point of view, which may be an opportunity for the use of i*; Frank Pillar, partner in the project, is interested in conceptual modeling to solve some of the IDS problems.

Giancarlo: are there connections from IDS with Fair Data project, since these projects share some commonalities and goals?
Answer: yes. He sees that IDS is focused on general data, but some of the data is research data and thus, he has a couple of PhD students working on Fair Data related stuff.

Wolfgang: How can users feel better about sending their data, and avoid the feeling of loosing control over the data?
Answer: The idea is to distribute only part of the data (e.g. anonymizing it). Other requirements, such as separation of duties may also contribute to this; avoiding hierarchical structures

iStar@ER 2019 - Discussion

iStar Workshop Discussion Session

John:
- Ethical Requirements: it is important to develop work on ethics, especially connected to AI systems.
- Coping with Uncertainties - we must deal in smarter ways with the uncertainties: fulfilling a goal a percentage of the way; also, having a way to make more flexible for which situations it is important to fulfil them in different degrees.

Eric:
- i* was inspired on AI, which at the time had mostly to do with Planing: goals & plans. One important question is: is there another version of i* for the new kinds of AI systems, more tuned with Data.
- another important area that we should target is argumentation, and this is connected to the ethics, already mentioned by John. This needs to include Belief, which is already present at some dialects of i*
- we also need transparency to help explain the decisions and keep the systems ethical.

Xavi:
- i* 2.0 - there is a strong diversity regarding how we work, and this hampers the way we can interact, and develop tools. Today, we have seen many works that target clarification and unification of the different views. This is a problem we have not solved yet and I am affraid that we will go to i* 3.0 without actually finishing up i* 2.0.
- lack of empirical evidence. We must target this problem! We cannot be guided by gut feeling. We really need to be stronger in providing scientific evidence.

Renata:
- In order to cope with the first topic raised by Xavi, se need a plan. After we released the i* 2.0 standard, the work on the standard stopped. We should get back to it with a set of well-defined steps. And perhaps, we should start small. I guess this is one of the messages of today's presentations here. If we are able to precisely define what a goal is and what actors are, we will be taking good steps towards providing a subset of usable concepts to i* users, and we will be able to relate and interoperate with other communities as well.

Jaelson:
- I would like to undsrstand why we are not attracting so much users anymore. In the past, we had two-day workshops. Today, I was already happy that we had a full day one. I think we should provide resources to the users. The i* wiki seems not to be enough and we should provide ways for people to take what the i* community produces and use. Moreover, we must provide ways for people to understand what are the trends, before coming to the next i* workshop.

Vítor:
- I would like to know what kind of use it has been done in industry. Perhaps understanding how they use it will provide us with new input to make it better.


MREBA@ER 2019 - Creation of Multiple Conceptual Models from User Stories: A NLP Approach - By Abhimanyu Gupta, Geert Poels, and Palash Bera

Creation of Multiple Conceptual Models from User Stories: A NLP Approach
By Abhimanyu Gupta, Geert Poels, and Palash Bera

From User Story, this works proposes the generation of four different types of conceptual models: two structural ones (Class Diagram and Use Cases) and two Behavioral ones (Sequence Diagram and BPMN).

He presented a Metamodel modeling User Story elements.

He made a Demo during the presentation, showing the generation of these models from a set of 6 user stories.

Then, he explained the NLP approach he used, composed of different rules for each type of element from the Metamodel.

*There are still a lot of limitations to be overcome in this work. In particular, it was mentioned that it is not possible to go from user stories to complete conceptual models of any kind.



MREBA@ER 2019 - Towards a Catalog of Goals for Strategic Coopetition - By Vik Pant and Eric Yu

Towards a Catalog of Goals for Strategic Coopetition - By Vik Pant and Eric Yu

Coopetition - Cooperation and Competition.
This is already a reality in the business market. Companies need Win-Win Models 

They propose catalogues of goals for this context: one goal tree of competition; one goal tree of cooperation.

Source information in online bibliography: they link their catalogue goals to the available bibliography to provide context and examples.

Top level goals are similar in both competition and cooperation goal catalogues. As much as you go to the leaves, the goals become very different.

To build the catalogues, they followed a exploratory research protocol.
*A good idea for the future is to approach it with systematic review.

They published in another paper the action research methodology they used in the case study. In this paper, they focus on the what, rather than the how, thus publishing another perspective of the same case study.

Limitations: deal with conditionals; temporal aspect. They dealt with that by etending the language.
*Why not combining i* with other languages that are more adequate for that kind of modeling.

Other limitations pointed out during Q&A:
- having either green or red (achieve/not achieve)
- having a case study where different actors compete and cooperate. It is not a real coopetition case.





quinta-feira, 10 de outubro de 2019

Git Tutorial - Jorge D.R. Medina - Unitn/Ingegneria del Software II


Slides here, show all commands in detail

Interesting online tutorial - Learn Git Branching

Git General Commands:
·      git init – to create a new git repository on your current folder
·      touch <name of the file> – create a file
·      git add <name of the file> - add a file that is already in the folder to the git staging area. If you do not specify which branch, it will add to branch master
·      git status – show the status of your files
·      git stage <name of the file>
·      git commit <name of the file>
·      git diff <name of the file> - shows what has been changed in a particular file. It does not work for staged files.
·      git diff -- staged <name of the file> - shows what has been changed in a particular file. With the --staged parameter, it now works for staged files.
·      git add . – adds everything that changed in the directory to the repository
·      git commit -v – shows what you changed after the commit is executed.
·      Git commit -m <commit message> - add the commit message in the command line and not the editor.
·      git .ignore – creates a text file where you can write the names of files and folders to be ignored by git (you may even write *.eu to ignore files of certain extensions)
·      git rm <name of the file> – removes a file from git repository and physically from the disk.
·      ls -1
·      git rm --cache <name of the file>  - removes a file only from the index, not physically from the disk
·      git log --pretty-=oneline – to view all commits
·      git show – to view the last commit
·      git show <hash> - to view a particular commit
·      git tag -a <name of the commit> -m <message> <hash> – to associate a name and a message to a particular commit. If you do not specify a hash, it will be the last ones.
·      git tag – to view the tags I have
·      git ls-files – to view what is in the git directory



Branching Commands
A branch is just a file with a hash identifier.
The modifications (snapshots) also have a hash identifier. They are more compact “delta files”.

·      git branch – shows the branches you have
·      git branch <name of the branch> - create a new branch. Before doing this, we need at least one commit.
·      git checkout  <name of the branch>- move to a branch
·      git checkout -b <name of the branch> - creates a new branch and moved to it
·      git merge <name of the branch> - merges the branch indicated by <name of the ranch> to the merge where you currently are.
Working with remotes
·      git remote add origin <name of the new repository at GitHub>
·      git push -u origin master – push the content of a repository to your GitHub repository. Then, you should enter your GitHub name and password. In the command line, you will have some statistics about your repository. The “-u” parameter means that next time you make push, you must only use the command git push, and Git already knows that you want to push the whole repository there.
·      After doing git remote and git push (two previous topics), you must refresh the GitHub page to see the modifications.
·      git pull origin master – pulls files from the GitHub directory to your local machine.


Branching model - Gitflow
When you work on teams, the team should have some kind of convention regarding branching among other things.

Gitflow is a development model that defines a strict branching strategy centered around the idea of releases.

The Gitflow model prescribes different types of branches
  • Master: this is a Versions branch
  • Develop: branch created from the Master to contain the stable developed features.
  • Feature: created from the Develop Branch for each feature being developed (not stable). When ready, the feature branch should be merged into the develop branch.
  • Release: when all features for the release are ready, a branch is created from the Develop branch. Then, the Release branch merges into the Master branch.
  • Hotfix: created from the Master branch to fix bugs very quickly. These are critical bugs that should be fixed immediately to guarantee the application to keep operating. Minor bugs can be fixed in the Feature branch. If there is more than one critical bug and they are related, they may be fixed in the same Hotfix branch. Otherwise, you should have distinct Hotfix branches. Hopefully, that will not be common.


Advanced commands:
  • git rebase – a set of commands are executed to prepare the branches for a fast forwarding merge (see slides + simulation on Learn Git Branching
  • git stash - allows us to store half-done work without doing a commit. It is as if it saves a snapshot of what we've done so far and waits for us to come back to it. If we do git status, we see an empty list
  • git stash list - allows us to check the stashes we have
  • git stash apply stash@{0} - get back to the stash identified by "stash@{0}"
  • git rebbase -i - interactive rebasing allows us, among other things, to squash multiple commits into one.