SIOC Post profile for "AI3:::Adaptive Information"
type: Document
description: A SIOC profile describes the structure and contents of a weblog in a machine readable form. For more information please refer to http://sioc-project.org/.
primary topic: CWPK #39: I/O and Structural Ingest
generator agent: http://rdfs.org/sioc/wp-sioc.php

CWPK #39: I/O and Structural Ingest
type: Post
has container: weblog
has creator: Mike Bergman
maker: Mike Bergman
created: 2020-09-21T15:16:59Z
content: Builds Are a More Complicated Workflow than Extractions In installment CWPK #37 to this Cooking with Python and KBpedia series, we looked at roundtripping information flows and their relation to versions and broad directory structure. From a strict order-of-execution basis, one of the first steps in the build process is to check and vet the input files to make sure they are clean and conformant. Let's keep that thought in mind, and it is a topic we will address in CWPK #45. But we are going to skip over that topic for now so that we do not add complexity to figuring out the basis of what we need from a backbone standpoint of a build. By "build" I have been using a single term to skirt around a number of issues (or options). We can "build" our system from scratch at all times, which is the simplest conceptual one in that we go from A to Z, processing every necessary point in between. But, sometimes a "build" is not a wholesale replacement, but an incremental one. It might be incremental because we are simply adding, say, a single new typology or doing other interim updates. The routines or methods we need to write should accommodate these real-world use cases. We also have the question of vetting our builds to ensure they are syntactically and logically coherent. The actual process of completing a vetted, 'successful' build may require multiple iterations and successively more refined tweaks to the input specifications in order to get our knowledge graphs to a point of 'acceptance'. These last iterating steps of successive refinements all follow the same "build" steps, but ones which involve fewer and fewer fixes until 'acceptance' when the knowledge graph is deemed ready for public release. In my own experience following these general build steps over nearly a decade now, there may be tens or more "builds" necessary to bring a new version to public release. These steps may not be needed in your own circumstance, but a useful generic build process should anticipate t…
encoded: Builds Are a More Complicated Workflow than Extractions In installment CWPK #37 to this Cooking with Python and KBpedia series, we looked at roundtripping information flows and their relation to versions and broad directory structure. From a strict order-of-execution basis, one of the first steps in the build process is to check and vet the input files to make sure they are clean and conformant. Let’s keep that thought in mind, and it is a topic we will address in CWPK #45. But we are going to skip over that topic for now so that we do not add complexity to figuring out the basis of what we need from a backbone standpoint of a build. By “build” I have been using a single term to skirt around a number of issues (or options). We can “build” our system from scratch at all times, which is the simplest conceptual one in that we go from A to Z, processing every necessary point in between. But, sometimes a “build” is not a wholesale replacement, but an incremental one. It might be incremental because we are simply adding, say, a single new typology or doing other interim updates. The routines or methods we need to write should accommodate these real-world use cases. We also have the question of vetting our builds to ensure they are syntactically and logically coherent. The actual process of completing a vetted, ‘successful’ build may require multiple iterations and successively more refined tweaks to the input specifications in order to get our knowledge graphs to a point of ‘acceptance’. These last iterating steps of successive refinements all follow the same “build” steps, but ones which involve fewer and fewer fixes until ‘acceptance’ when the knowledge graph is deemed ready for public release. In my own experience following these general build steps over nearly a decade now, there may be tens or more “builds” necessary to bring a new version to public release. These steps may not be needed in your own circumstance, but a useful generic build process should anticipate t…
topic: CWPK
topic: KBpedia
topic: Semantic Web Tools
has reply: comment-507587
links to: CWPK #37
links to: Cooking with Python and KBpedia
links to: roundtripping
links to: CWPK #29
links to: CWPK #35
links to: KKO
links to: KBpedia
links to: SKOS
links to: cb1-1
links to: cb1-2
links to: cb1-3
links to: cb1-4
links to: cb1-5
links to: cb1-6
links to: cb1-7
links to: cb1-8
links to: cb1-9
links to: cb1-10
links to: cb1-11
links to: cb1-12
links to: cb1-13
links to: cb1-14
links to: cb1-15
links to: cb1-16
links to: cb1-17
links to: cb1-18
links to: cb1-19
links to: cb1-20
links to: cb1-21
links to: cb1-22
links to: cb1-23
links to: cb1-24
links to: cb1-25
links to: cb1-26
links to: cb1-27
links to: cb1-28
links to: cb1-29
links to: CWPK #21
links to: LEGB
links to: owlready2
links to: cb2-1
links to: cb2-2
links to: cb2-3
links to: cb2-4
links to: cb2-5
links to: cb2-6
links to: cb2-7
links to: cb2-8
links to: cb2-9
links to: cb2-10
links to: cb3-1
links to: cb3-2
links to: cb3-3
links to: cb3-4
links to: cb3-5
links to: cb3-6
links to: cb3-7
links to: cb3-8
links to: cb3-9
links to: cb3-10
links to: cb3-11
links to: cb3-12
links to: cb3-13
links to: cb3-14
links to: cb3-15
links to: cb3-16
links to: cb3-17
links to: cb3-18

Mike Bergman
type: User

Mike Bergman
type: Person

Cooking with Python and KBpedia
label: CWPK listing

Protégé

CWPK #28

owlready2 mailing list

CSV file Import with DictReader

Traps for the Unwary in Python’s Import System

Scope of Variables in Python

CSV File Reading and Writing

KBpedia

direct download

notify me