Define schemas and basic Graph based on user stories

[jurra]

Schemas should follow user stories

Please add if something is missing 🙏

Basic fields:

Check the npm package registry for instance Design node:

• Auhtor
• Github repository (Optional)
• Design image
• Stars (Likes?)
• Comments
• Status
• Date
• Version (Released)
• License

User (Designer) node

• Image
• Name
• Description
• Keywords

Post (Equipment request, Need driven) (Not considered the basic fields like ids, etc.)

• Comments
• Createdby

[DNature]

How do you plan on archiving this. Like the author field, stars, comments ...?. Do you plan on scrapping out the data or is there any GitHub API for this?

[jurra]

Thats right @DNature some data will be scrapped from the github API. Similar to what npm does. Beside this the metadata about the project that we are currently using will be pused as well, very similar again to what you do when you publish an npm package. The only difference is that instead of pushin raw json, we will provide a form interface that allows to better document project/design data: This is the current yaml we are currently puting in projects:

---
# basis test for remote pickup of metadata by both client app and 
# the essential repo updates system to come. 
# *todo* ground rules for yaml lines of this file, to be written 

# note carefully that this is the title that will show 
# in the Finder-Viewer app, and so _must_ be short enough to fit
# the longTitle below lets such be in meta; no place to use it at present
shortTitle: MIT Emergency Ventilator (E-Vent)
# these names are fixed labels as must be used on repo by GitHub API, for our access
name: mit-emergency-ventilator
nameWithOwner: CombatCovid/mit-emergency-ventilator

# markdown titles too long for Finder to show especially, we hold for any uses
# the same for long descriptions in the languages
# when text may fit, then they are the same in topic and longTopic yaml items
longTitle: MIT Emergency Ventilator (E-Vent) Project

languages:
  EN:
    description: A low-cost ventilator, based on the collective wisdom of many clinicians
    keywords: [patient,recovery,critical care,intensive care,icu,equipment,
      emergency room,helper,treatment,hospital,operating room]
    longDescription: >
      A ventilator is a machine that provides mechanical ventilation 
      by moving breathable air into and out of the lungs, to deliver breaths
      to a patient who is physically unable to breathe, 
      or breathing insufficiently.

  ES:
    description: Un ventilador de bajo costo, basado en la sabiduría colectiva de muchos médicos.
    keywords: [ paciente,recuperación,Cuidado crítico,
      cuidados intensivos,icu,equipo,sala de emergencias,
      ayudante,tratamiento,hospital,sala de operaciones ]
    longDescription: >
      Un ventilador es una máquina que proporciona ventilación mecánica.
      moviendo aire respirable dentro y fuera de los pulmones, 
      para entregar respiraciones a un paciente que es físicamente 
      incapaz de respirar, o respirando insuficientemente.

  KR:
    keywords: [ 환자,회복,중요한 치료,집중 치료,아이쿠,장비,
      응급실,돕는 사람,치료,병원,수술실 ]
    description: 많은 임상의의 집단적 지혜에 기반한 저렴한 인공 호흡기
    longDescription: >
      인공 호흡기는 기계적 환기를 제공하는 기계입니다
      통기성 공기를 폐 안팎으로 이동시켜 호흡
      신체적으로 숨을 쉴 수없는 환자에게
      또는 호흡이 불충분합니다.

project-link: https://e-vent.mit.edu/
intended-use: >-
    tbd
made: true
made-independently: false
license:
  hardware: undefined
okh-manifest-version: 1.0.0
date-updated: 2020-03-31
manifest-author:
  name: MiT people
  affiliation: MIT
contributors:
  undefined
sub-parts:
  undefined
  undefined

---

[jurra]

Another important reference is the open know how specification, which is interesting, but I would adapt, adopt to our context: https://app.standardsrepo.com/MakerNetAlliance/OpenKnowHow/src/branch/master/1

[DNature]

There's gonna be some conflicts with determining the authenticity of the data provided by a user. I understand the concept of the project a little bit. However, I'll list out some caveats of importing some days manually and handling the files with file system vs database.

• A user can provide malicious codes in the yml file
• Existing data/files can be accessed and erased easily when an unauthorized use gains access to the servers root folder. Whereas a database can have password
• its easier to store and retrieve data in the database than for system
• False credentials can be provided by users.

I'm also a huge fan of yml/markdown syntax/methods because that's what I'm using for my blog

[DNature]

It's better for a user to enter the URL of their GitHub repo that contains a readme then we can retrieve data from the GitHub page that contains a readme, stars, username, etc, and it might not require a database for the because we'll be making requests for data to that GitHub URL anytime a user visits their projects page. I just taught about this now

[jurra]

Hey @DNature, you are right, about all these things.

1. We have this simple system more for a matter of simplicity and minimum viable solution than because it is ideal.
2. We can use the same concept of package publishing (like npm, I don't if you have made a package, but if you have it is pretty straight foward). You can only publish a new version of the package, and increment x,y,z semantic values. v2.1.3 ->> v2.1.4 etc. I am not entirely convinced that semantic versioning should be enforced for every case in hardware, but you can kind of get an idea of a simple system.

[jurra]

With regard to generation of data and so on, I am currently working on the form I mentioned with vuex. An interesting part of this is that I would like to generate the forms dynamically based on schemas. Why? because the spec of the metadata can change. I have been looking for sometime, even before this project, json-schemas and schema.org, maybe you have heard of this.