Group 3 Sticky Notes - Githubissues

arquicanedo commented 2 years ago

Sticky notes taken by Group 3

Business Validation

Do use case development because it validates the value of a KG
Do persuade management about the value of KG efforts
Because the KG have a (?) to every business every additional requirements (?) but it should meet the business ROI & priorities

Requirements

Don't boil the ocean because use cases can be composed and reconciled in KGs
Requirement is key because we need to have the understanding of every silo of the business that propose (?) the knowledge
Do capture concept descriptions in non-formal representation so all stakeholders can contribute
Do identify all life cycles you need to manage to develop the KG

Design

Don't mix application logic in with the domain model because app logic may change or become invalid
Do have domain experts define the ontology because they know best the domain
Do establish what ontology model enhancements we need to support the use-case, develop each as its own defined story
Don't think of creating the most theoretically perfect ontology. Why: it can't work in production.
Do modularize your models. Why: to better maintain them and make them reusable
Because we need to identify the components of delivery (resource, time, technology and tools, cost) based on that the scoping can be done
Make ontology content visible to domain experts so they can validate models
Do separate TBox (ontology) and CBox( term sets, name with, taxonomy) because different stakeholders can manage each
Do follow design patterns. Why: will help with simplifying downstream codes that use the models (reusability).
Do find simple means of communicating your models with SMEs (i.e,. graphical views). Why: save them from the complexity of the technology
Don't make modeling decisions based on current application limitations/behavior. Because the app will evolve faster than the model.
Do include business goals in the knowledge artifact because it makes their influence explicit to stakeholders
Do start simple and let it grow iteratively because it helps complexity.

Development

Do visualize because it helps understanding
Do ETL with data scientist because of efficiency
Pain point: version control
Pain point: encapsulation
Pain point: conflict resolution (merge)
Do manage ontologies with software version control such as git
Don't let used ontologies remain unlinked because they will diverse and be a headache to reconcile
Focus on one model at a time
Break down into multiple story lines (?)
Create ontology
Prepare R2RML
RDF store
Prepare front end for semantic search
Do use RDF for formal specification because you are going to reimplement half of it, and poorly, anyway
Don't insist on structured-file interfaces to ontology management because important stakeholders may not effectively curate (?)
Don't track dependencies using a tool such as kanban
Check in to version control. Post unit testing and validation.
Don't prematurely imperative (?) because declarative representations are more (?) for evolution

Test

Do have no-code visual data display/summary because some stakeholders can only give feedback that way
Write good class definitions as tests and run reasoner regularly to ensure coherency
Do use standards for developing KG and ontology unit tests, integration tests (e.g., SHACL)
Do testing on both the ontology and the instance data (SHACL)
Validate the end to end (?) to ensure all the components are still valid

Deployment

Do version control KG and ontology and app separately because each has its own lifecycle
Do have a concrete plan for communicating version changes downstream + backward compatibly. Why: downstream users need to be aware of changes to models their data adheres to
Do use globally unique persistent resolvable identifiers because people should opt-in to concept equivalence and relations.
Do embrace the FAIR principles because you don't wan to re-do work

Team Composition

Do have multi-disciplinary dev teams, ontologists, SMEs, software developers because you need all 3 to apply the KG to applications
Include domain experts, product owners to ensure requirements are clear/aligned to user needs for KG strengths