Group 2 Sticky Notes

[arquicanedo]

Demos

• Start small building ontologies with few concepts and presents the first results
• Do invite positive stakeholders to keep business value focus
• Start with subset of data/ontology concepts
• Visualize

Retrospectives

• Team understanding of ontology
• Get feedback from the user experts while building the ontology
• Simulate query retrieval

Development

• Use JIT (Just-in-time) modeling
• Do generate graph from source tables (OTTR templates) to scale lifting knowledge into graph and to enable refactoring (just use new templates)
• Do RDF as code in Git to share with engineering
• Automated or human-aided verification of best practices. For example "ensure one pref label per language"
• Do have explicit design principles because drives consistent designs without so much iteration
• Do switch up the words (?) on which prob(?) of ontology. Because: drives consistency,... (?)

Requirements

• Do review designs early because avoids late breaking(?) shocks due to misaligned expectations
• Do ask about future use-cases even if not needed yet because it avoids boxing yourself into a corner with a design that can't extend
• Do identify starting point - narrow down your use case
• Involve all team members

Other

• Prototype with visual results to test assumptions
• Do build-up(?) to grow analogy(?) in spark(?)
• Governance is key (keep changelog, lineage, ...)
• Do agree clear change management process because avoids breaking other teams(?)

Use-cases / User stories

• Competency questions ~= User stories
• Do one use-case end-to-end with little semantics

Metrics

• Do have guiding questions (competency questions) in order to not model useless stuff

Planning

• Do agree roles and responsibilities if you have multiple people because it avoids confusion and key tasks being dropped
• Use competency questions for DoD
• Look at the current way the data is retrieved. What are the common requests.

Testing / Validation

• Do use SHACL
• Do test driven development. SPARQL queries
• Do create regression tests because otherwise when you build the next use-case, the old (?) can break
• Do mock-up RDF to test SPARQL end-to-end
• Search for unusual values to recognize a possible issue in the system or in the KG building process
• How to find anomalies? Reporting of non-sensical interfaces
• Do use QSKOS
• Test for negatives
• Test modeling A/B with customers to validate it

[bolerio]

[bolerio]

[bolerio]

[bolerio]

[bolerio]

[bolerio]

[bolerio]

[bolerio]