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 #35: A Python Module, Part III: Custom Extractions and Finish Packaging
generator agent: http://rdfs.org/sioc/wp-sioc.php

CWPK #35: A Python Module, Part III: Custom Extractions and Finish Packaging
type: Post
has container: weblog
has creator: Mike Bergman
maker: Mike Bergman
created: 2020-09-14T15:11:18Z
content: Completing the Extraction Methods and Formal Packaging This last installment in our mini-series of packaging our Cooking with Python and KBpedia project will add one more flexible extraction routine, and complete packaging the cowpoke extraction module. This completion will set the template for how we will add additional clusters of functionality as we progress through the CWPK series. The new extraction routine is geared more to later analysis and use of KBpedia than our current extraction routines. The routines we have developed so far are intended for nearly complete bulk extractions of KBpedia. We would like to add more fine-grained ways to extract various 'slices' from KBpedia, especially those that may arise from individual typology changes or SPARQL queries. We could benefit from having an intermediate specification for extractions that could be used for directing results from other functions or analyses. Steps to Package a Project so Far To summarize, here are the major steps we have discovered so far to transition from prototype code in the notebook to a Python package: Generalize the prototype routines in the notebook Find the appropriate .. Lib/site-packages directory and define a new directory with your package name, short lowercase best Create an __init__.py file in that same directory (and any subsequent sub-package directories should you define the project deeper); add basic statements similar to above Create a __main__.py file for your shared functions; it is a toss-up whether shared variables should also go here or in __init__.py If you want a single point of editing for changing inputs for a given run via a 'record' metaphor, follow something akin to what I began with the config.py Create a my_new_functions.py module where the bulk of your new work resides (extraction in our current instance). The approach I found helpful was to NOT wrap my prototype functions in a function definition at first. Only in the next step, once the interpreter is able to…
encoded: Completing the Extraction Methods and Formal Packaging This last installment in our mini-series of packaging our Cooking with Python and KBpedia project will add one more flexible extraction routine, and complete packaging the cowpoke extraction module. This completion will set the template for how we will add additional clusters of functionality as we progress through the CWPK series. The new extraction routine is geared more to later analysis and use of KBpedia than our current extraction routines. The routines we have developed so far are intended for nearly complete bulk extractions of KBpedia. We would like to add more fine-grained ways to extract various ‘slices’ from KBpedia, especially those that may arise from individual typology changes or SPARQL queries. We could benefit from having an intermediate specification for extractions that could be used for directing results from other functions or analyses. Steps to Package a Project so Far To summarize, here are the major steps we have discovered so far to transition from prototype code in the notebook to a Python package: Generalize the prototype routines in the notebook Find the appropriate .. Lib/site-packages directory and define a new directory with your package name, short lowercase best Create an __init__.py file in that same directory (and any subsequent sub-package directories should you define the project deeper); add basic statements similar to above Create a __main__.py file for your shared functions; it is a toss-up whether shared variables should also go here or in __init__.py If you want a single point of editing for changing inputs for a given run via a ‘record’ metaphor, follow something akin to what I began with the config.py Create a my_new_functions.py module where the bulk of your new work resides (extraction in our current instance). The approach I found helpful was to NOT wrap my prototype functions in a function definition at first. Only in the next step, once the interpreter is able to…
topic: CWPK
topic: KBpedia
topic: Semantic Web Tools
has reply: comment-507581
has reply: comment-507582
links to: Cooking with Python and KBpedia
links to: KBpedia
links to: SPARQL
links to: CWPK #29
links to: owlready2
links to: semantic triple
links to: IRI
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: cb1-30
links to: cb1-31
links to: cb1-32
links to: cb1-33
links to: cb1-34
links to: cb1-35
links to: cb1-36
links to: cb1-37
links to: cb1-38
links to: cb1-39
links to: cb1-40
links to: cb1-41
links to: cb1-42
links to: cb1-43
links to: cb1-44
links to: cb1-45
links to: cb1-46
links to: cb1-47
links to: cb1-48
links to: cb1-49
links to: cb1-50
links to: cb1-51
links to: cb1-52
links to: cb1-53
links to: cb1-54
links to: cb1-55
links to: cb1-56
links to: cb1-57
links to: cb1-58
links to: cb1-59
links to: cb1-60
links to: cb1-61
links to: cb1-62
links to: cb1-63
links to: cb1-64
links to: cb1-65
links to: cb1-66
links to: cb1-67

Mike Bergman
type: User

Mike Bergman
type: Person

Cooking with Python and KBpedia
label: CWPK listing

Protégé

roundtrip

KBpedia

direct download

notify me