Django's internal ORM system allows us to isolate data models of our application from data vendors. In other words, as a programmer, we need to care as less as possible about which data vendor(mysql, postgresql etc.) is used. And django helps us by requiring only the definitions of data models.

Elasticsearch will be very suitable because, in this project, we are going to work on advanced searching and flexible data models.

Django models seem to be tailored for relational databases. However, it is possible to use them with nosql databases such as mongodb etc. So, we need to research the feasibility of using django model system with elasticsearch.

users should be able to search heritage items in full-text style, that is, user's keyword needs to be searched all the information of heritages and there should be a score value for each matching heritage item.

For this purpose, we are going to use elasticsaerch. #39

Prepare html template regarding to mockups

complete template using byrushan as we spoke in meeting.
Template should be designed regarging to mockups

As we are working in a team, it is important that we standardize the tools that we use, so that any output we create is easily interchangeable between each other.

In general , following is a list of categories for which we should find tools for:

• Code Quality
• Time Tracking
• Continuous Integration
• Update Notifications
• Versioning (GitHub as the repository, but what should we use locally? GitHub Desktop? Cmd?)
• Dependency Management
• Documentation
• Project Planning
• Task Management
• UML Editor
• Mockup Editor
• IDE
• Intra-Team Communication

Please reply with possible candidates for each category, and we can decide upon the tool to be used by voting.

We need Django models that cover all the annotation data models proposed in #16

It is possible to create a single django model for all the annotations, or we come up with separated models derived from a base model class. But note that in django, single table inheritance is not possible.

In addition, if necessary, serializers for these models are also be done.

depends on #39

For the backend side, we are going to use Django framework. First, we need to create the project skeleton. For this purpose, we need, at least, a Django project and a Django app.

All the dependencies of Django application will be listed in requirements.txt file which can be found in the Django project folder.

• create requirements.tx
• start project
• start application
• prepare base docker-compose.yml
• update contribution guide

We could use separated GANTTPRO accounts for scheduling and planning ourselves individually as in below example.

That image is my performed schedule. We would add future schedule plan under performed schedule or separate future schedule plan and performed schedule.

We should prepare mockups that capture our understanding of the system and present them to the customer. Getting feedbacks from the customer this way is important as it materializes out abstract image of the system, allowing each team member as well as the customer to have the same idea about the system. If we are able to prepare well designed mockups, we can agree on the system with least iterations possible and deliver an end product that meets the customer's requirements closely.

Regarding to mockups

Please write your attractive naming ideas to name our group. We should vote them using likes. Do not edit existing name comments. Start a new comment for any name you could find. We should like them. Unlikes would be exciting :)

It is crucial to build a prototype using a blank page, an image at first and implementing necessary frameworks to understand how we will enable users to interact with the images. While interacting with images for annotation purposes, it is vital to have selectors for regions, point, different geometrical shapes such as polygon, triangle, circle, ellips, rectangle. Assigned to @sanal-cem

Naming is the most challenging issue that a software engineer can face ;)

I remember sometimes deciding a name for a C# method could take much more time than coding its body.

So, please write down your nominees. We can make a poll to elect one of them.

finding open source libraries that will help with the specific tasks will make the development faster and easier

Regarding to mockups

• The Annotation Protocol provides a simple RESTful HTTP API for communicating among annotation clients and servers, and builds upon the Linked Data Platform specification. link

• This document provides best practices and guidelines for implementing Linked Data Platform [LDP] servers and clients.

• To avoid the confusion about which datatypes could be used, LDPR representations should use only the following standard datatypes. RDF does not by itself define datatypes to be used for literal property values, therefore a set of standard datatypes based on [XMLSCHEMA11-2] and [RDF-PRIMER11] should be used.

Useful links

https://www.w3.org/TR/2015/REC-ldp-20150226/
https://www.w3.org/TR/2015/NOTE-ldpatch-20150728/
https://www.w3.org/TR/2014/NOTE-ldp-bp-20140828/

It would be nice to have a docker preparation to make the development environment the same for all the contributors. Developers should only to issue the docker preparation, without installing any 3rd party systems on local systems.

At the moment, docker should include:

• redis
• elasticsearch
• mysql

To make it more understandable and concrete, we need to create example data models for each annotation case which will be available in our user interfaces. For instance, as it can be seen on the mockups, authenticated users can annotate an image of a cultural heritage item. Annotations can contain text, image, video, or location.

However, at this point, we do not know what the data models for these annotations will be, or exactly what attributes they will include/require, which attributes are optional etc.

In short, we need to create example data models for each case. To setup example cases, we can use the following resource definitions.

Resources

Let's say we have a heritage item whose id is 3, and the URI is:

• http://574heritago.com/heritages/3/

The heritage item has two images whose IDs are 124 and 110

• http://574heritago.com/heritages/3/images/124/
• http://574heritago.com/heritages/3/images/110/

The heritage item has a video attachment whose id is 12

• http://574heritago.com/heritages/3/videos/12/

The heritage item has a location information whose id is 8

• http://574heritago.com/heritages/3/locations/8/

According to this URIs, we can create example web annotation data models.

Data model

If I annotate the image(id=124) by uploading a video; then the annotation data model may be similar to this:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://574heritago.com/annotations/1/",
  "type": "Annotation",
  "body": {
    "id": "http://574heritago.com/resources/videos/4/",
    "type": "Video"
  },
  "target": {
    "id": "http://574heritago.com/heritages/3/images/124/",
    "type": "Image"
  }
}

We should share this task.

project plan should be updated based on the new issues

First of all, we need to decide how we are going to use git. There are many ways, the most simple one is that everybody has a clone of this repo, with only one branch named master. And all work is done on this branch, and the changes are sent as a pull request to the organization repo. However, there are other models.

For instance, one of the most used models is the feature-branching model. http://nvie.com/posts/a-successful-git-branching-model/ I suggest following this model. Let's discuss.

if you accept this model thumbs up, please.

Ms. Uskudarli has presented us with two options to be used as the programming language for our project:

• Python
• Java

Which one do you think we should use?

Lets vote!

activity diagram of the system based on requirements should be added to wiki page.

We need to create django views for the django models defined in #41 #40

All these views have to be able to satisfy the designed api #26 That means, having the views completed, we have to be able to serve the api.

In accordance with the views, url mappers need to be created.

depends on #40 #41

For heritage items, appropriate django models should be created. For each field, inline comments are required. In addition, related serializer/s needs to be created.

depends on #39 , #41

prepare and complete requirement document.

• first draft
• peer review
• team review

We (along with @sanal-cem and @yaseminalpay ) have already started by adding title, description and google maps integration for landing page. Now, I will complete the rest of the page by adding annotation option on text, basic information, adding other multimedia such as video, image and audio. Lastly, I am planning to implement intro.js on this page for guidance on how to annotate.

Our initial plan draft should be created.

A logo is one of the most important artifacts that define an asset; just as a nation needs a flag, a team needs a logo. We should design a logo for our team and our project that would summarize our mission and vision, in a format that is usable both in the wiki and the application itself.

Please comment below your questions so that we can create a list of probing questions and document the final version of the list to its related Wiki page.

1. World Heritage in India, World Heritage in Iran, China, France, Japan etc. applications seems very proper for my software development technique. We would add different ideas to that application and develop a more usable and intriguing application. I documented World Heritage in India.

Main Page

Information Page

Information Page 2

Photo Page

Example Photo

Countries Page

That page is like an advertisement, user should download each countries heritage application one by one. There are 25 countries!

Buggy map page

Advertisements

These small advertisements above would be enough to gain some profit from our future application. Moreover, we would find better and more attractive advertisements for our future application.

Prepare html template regarding to mockups

There is a need for an API to get a heritage item's annotations. The details are explained in REST API wiki page.

https://github.com/SWE574-Groupago/heritago/wiki/REST-API
GET /heritage/{ID}/annotations

However, we should omit the votes field for now because it will be implemented later.

{
  "heritageId": 1,
  "votes": {
    "http://example.org/anno11": {
      "up": 9,
      "down": 4,
      "you": -1
    },
    "http://example.org/anno12": {
      "up": 5,
      "down": 7,
      "you": 0
    },
    "http://example.org/anno13": {
      "up": 9,
      "down": 5,
      "you": 1
    }
  },
  "annotations": [
    {
      "@context": "http://www.w3.org/ns/anno.jsonld",
      "id": "http://example.org/anno11",
      "type": "Annotation",
      "creator": "http://574heritago.com/users/25/",
      "created": "2017-01-02T17:00:00Z",
      "body": {
        "type": "Text",
        "value": "The gate was built in 1829.",
        "format": "text/plain"
      },
      "target": {
        "id": "http://574heritago.com/heritages/3#description",
        "type": "Text",
        "format": "text/plain",
        "selector": {
          "type": "substring",
          "value": {
            "starts": 10,
            "length": 30
          }
        }
      }
    },
    {
      "@context": "http://www.w3.org/ns/anno.jsonld",
      "id": "http://example.org/anno11",
      "type": "Annotation",
      "creator": "http://574heritago.com/users/25/",
      "created": "2017-01-02T17:00:00Z",
      "body": {
        "type": "Image",
        "format": "image/png",
        "source": "http://574heritago.com/resources/images/2/"
      },
      "target": {
        "id": "http://574heritago.com/heritages/3#description",
        "type": "Text",
        "format": "text/plain",
        "selector": {
          "type": "substring",
          "value": {
            "starts": 10,
            "length": 30
          }
        }
      }
    },
    {
      "@context": "http://www.w3.org/ns/anno.jsonld",
      "id": "http://example.org/anno11",
      "type": "Annotation",
      "creator": "http://574heritago.com/users/25/",
      "created": "2017-01-02T17:00:00Z",
      "body": {
        "type": "Video",
        "format": "audio/mpeg",
        "source": "http://574heritago.com/resources/videos/2/"
      },
      "target": {
        "id": "http://574heritago.com/heritages/3#description",
        "type": "Text",
        "format": "text/plain",
        "selector": {
          "type": "substring",
          "value": {
            "starts": 10,
            "length": 30
          }
        }
      }
    },
    {
      "@context": "http://www.w3.org/ns/anno.jsonld",
      "id": "http://example.org/anno11",
      "type": "Annotation",
      "creator": "http://574heritago.com/users/25/",
      "created": "2017-01-02T17:00:00Z",
      "body": {
        "type": "Location",
        "format": "text/plain",
        "source": "http://map.com/?someselection"
      },
      "target": {
        "id": "http://574heritago.com/heritages/3#description",
        "type": "Text",
        "format": "text/plain",
        "selector": {
          "type": "substring",
          "value": {
            "starts": 10,
            "length": 30
          }
        }
      }
    },
    {
      "@context": "http://www.w3.org/ns/anno.jsonld",
      "id": "http://example.org/anno11",
      "type": "Annotation",
      "creator": "http://574heritago.com/users/25/",
      "created": "2017-01-02T17:00:00Z",
      "body": {
        "type": "Audio",
        "format": "audio/mp3",
        "source": "http://574heritago.com/resources/90/"
      },
      "target": {
        "id": "http://574heritago.com/heritages/3#description",
        "type": "Text",
        "format": "text/plain",
        "selector": {
          "type": "substring",
          "value": {
            "starts": 10,
            "length": 30
          }
        }
      }
    }
  ]
}

depends on #41

Create necessary labels, remove redundant ones

Do we really want others to see or c?py our labour?
Please like whichever you want.

We need unit tests for each django models and views. Because most of the work is carried out by the framework, we only need tests for custom model functions and behaviors. However, we need to test views/endpoints to make sure they do not accept invalid data types etc. This is integration testing rather than unit testing

• Copying a website using browser mostly could not succeed. As all resources can't be downloaded via browser.
• Example: Material design framework copied from link via HTTrack software.

• first draft is prepared
• team review is done
• final draft is prepared
• final team review is done
• report is submitted for Milestone: "Complete system design"

We need to prepare a development environment for the native android application.

We can create another repository for it or only create a folder named android in this repository. There are some trade-offs. But to keep it simple, I suggest going on to create a folder. @tokonu what do you think?

Front-end, back-end, and mobile applications will work and be developed independently. For FE and mobile clients, the back-end app will expose a REST API.

This API should be designed according to the best practices. That is, it should be stateless and resourceful.

How to design an API, how to work with the API-FIRST principle

1. https://www.ckl.io/blog/api-design-think-first-code-later/
2. https://blog.qmo.io/ultimate-guide-to-api-design/
3. https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9#.fduz2pa6i
4. https://www.infoq.com/articles/paypal-api-first-part2

We will go through all the mockup pages and design APIs that are required to implement each of the mockup pages.

Documentation

API documentation should be available on Wiki pages. Each API request needs to be clearly defined and needs to have at least one request and response example.

• Design
• Document

We need to specify our own rules for code review and add it to the wiki page. Let's discuss.