OntoWiki

You have no permissions to edit this model.

Saving has been disabled.

# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt

@base <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ns0: <http://archimind.nl/archimind/index.php/view/> .
@prefix ns1: <http://www.archimind.nl/archimind/index.php/resource/properties/> .
@prefix ns2: <http://www.archimind.nl/archimind/index.php/> .
@prefix ns3: <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix ontology1288790966584: <http://www.semanticweb.org/ontologies/2010/10/Ontology1288790966584.owl#> .
@prefix ontowiki_wikipage: <http://localhost/ontowiki_WikiPage/> .
@prefix owl2xml: <http://www.w3.org/2006/12/owl2-xml#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sadocontology1: <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix sioct: <http://rdfs.org/sioc/types#> .
@prefix sysconf: <http://localhost/OntoWiki/Config/> .
@prefix uva-sa-ontology: <http://www.archimind.org/archimind/UvA-SA-ontology.owl#> .
@prefix view: <http://localhost/ontowiki/view/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:9_logical_and_implementation_view_-_background_-_rationale_-_receiving_pulling_data> ontowiki_wikipage:content """
	Receiving/pulling data to process 
	 
	

	The application consists of three layers, in which the first and second layer mutate the data delivered to them in order to pass it along to the second layer and the third layer exposes this data to the outside world (if authenticated).

	 

	Thus a method must be chosen to get data from one layer to another. This can roughly be done in two ways: push or pull.

	 

	Push data 

	 

	The first solution we had considered was pushing data from one layer to another when ready up to the data storage at the end. If performed very puristicly, the data extractors wouldn’t so much be extractors but API’s that are able to receive data from the appropriate sources.

	 

	This puristic approach immediately poses problems; though some systems support operations after finishing their usual tasks (version control, creation of a bug tracking issue, etc.) not all do. This would mean that not all applications can be integrated into the system.

	 

	If we would pick the less puristic approach, it would mean we only push the data that was processed by the transformers in both the data and business layer to the next module in line. Since the module after the business layer is a database, this is a requirement. Which means the only “pushing” of data would be from the data to the processing layer. A further explained list of advantages and disadvantages is listed in the appendix under section: Push & pull data from databases.

	 

	Pull data from databases

	 

	Another option is to store the data abstracted by the transformation module in the data layer and the data processed in the business layer in their own databases. The data can in this case periodically be retrieved from the databases and processed. A further explained list of advantages and disadvantages is listed in the appendix under section: Push pull data from database

	 

	Conclusion

	After weighing the options, it appears that pushing the data only as a single major advantage: the fact that the critical systems can decide when they have sufficient resources available for pushing their code to the application.

	 

	The biggest disadvantage however, the fact that not all systems are compatible with this solution is reason enough to discard the idea. The stakeholders have said that they’re always looking for new tools that can do a better job. If an application turns out to be incompatible with this system, not all necessary data can be used to draw conclusions regarding communication, etc. This should not be allowed to happen.

	 

	Though non-trivial, it is possible to use monitoring software to measure when to pull data from an external source. Since the problem can be overcome this way, there is really no argument left why not to choose for a pull-strategy.

	 """ ;
 sadocontology1:contains_knowledge_about sadocontology1:Business_Logic_Layer, sadocontology1:Extensibility_of_data_sources, sadocontology1:Extractor, sadocontology1:Performance, sadocontology1:Pull_data, sadocontology1:Push_data, sadocontology1:Transformer, <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:Transformer_(business)>, sadocontology1:data_extraction_technique_-_push_or_pull, sadocontology1:data_layer, <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:extractor_(business)> ;
 a sadocontology1:WikiPage, owl:NamedIndividual ;
 rdfs:label "10 logical and implementation view - background - rationale - receiving pulling data" .

# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt

@base <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ns0: <http://archimind.nl/archimind/index.php/view/> .
@prefix ns1: <http://www.archimind.nl/archimind/index.php/resource/properties/> .
@prefix ns2: <http://www.archimind.nl/archimind/index.php/> .
@prefix ns3: <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix ontology1288790966584: <http://www.semanticweb.org/ontologies/2010/10/Ontology1288790966584.owl#> .
@prefix ontowiki_wikipage: <http://localhost/ontowiki_WikiPage/> .
@prefix owl2xml: <http://www.w3.org/2006/12/owl2-xml#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sadocontology1: <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix sioct: <http://rdfs.org/sioc/types#> .
@prefix sysconf: <http://localhost/OntoWiki/Config/> .
@prefix uva-sa-ontology: <http://www.archimind.org/archimind/UvA-SA-ontology.owl#> .
@prefix view: <http://localhost/ontowiki/view/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:9_logical_and_implementation_view_-_background_-_rationale_-_receiving_pulling_data> ontowiki_wikipage:content """<p>
	<strong>Receiving/pulling data to process<br />
	<br />
	</strong></p>
<p>
	The application consists of three layers, in which the first and second layer mutate the data delivered to them in order to pass it along to the second layer and the third layer exposes this data to the outside world (if authenticated).</p>
<p>
	 </p>
<p>
	Thus a method must be chosen to get data from one layer to another. This can roughly be done in two ways: push or pull.</p>
<p>
	 </p>
<p>
	<strong>Push data </strong></p>
<p>
	 </p>
<p>
	The first solution we had considered was pushing data from one layer to another when ready up to the data storage at the end. If performed very puristicly, the data extractors wouldn’t so much be extractors but API’s that are able to receive data from the appropriate sources.</p>
<p>
	 </p>
<p>
	This puristic approach immediately poses problems; though some systems support operations after finishing their usual tasks (version control, creation of a bug tracking issue, etc.) not all do. This would mean that not all applications can be integrated into the system.</p>
<p>
	 </p>
<p>
	If we would pick the less puristic approach, it would mean we only push the data that was processed by the transformers in both the data and business layer to the next module in line. Since the module after the business layer is a database, this is a requirement. Which means the only “pushing” of data would be from the data to the processing layer. A further explained list of advantages and disadvantages is listed in the appendix under section: Push & pull data from databases.</p>
<p>
	 </p>
<p>
	<strong>Pull data from databases</strong></p>
<p>
	 </p>
<p>
	Another option is to store the data abstracted by the transformation module in the data layer and the data processed in the business layer in their own databases. The data can in this case periodically be retrieved from the databases and processed. A further explained list of advantages and disadvantages is listed in the appendix under section: Push pull data from database</p>
<p>
	 </p>
<p>
	<strong>Conclusion</strong></p>
<p>
	After weighing the options, it appears that pushing the data only as a single major advantage: the fact that the critical systems can decide when they have sufficient resources available for pushing their code to the application.</p>
<p>
	 </p>
<p>
	The biggest disadvantage however, the fact that not all systems are compatible with this solution is reason enough to discard the idea. The stakeholders have said that they’re always looking for new tools that can do a better job. If an application turns out to be incompatible with this system, not all necessary data can be used to draw conclusions regarding communication, etc. This should not be allowed to happen.</p>
<p>
	 </p>
<p>
	Though non-trivial, it is possible to use monitoring software to measure when to pull data from an external source. Since the problem can be overcome this way, there is really no argument left why not to choose for a pull-strategy.</p>
<p>
	 </p>""" ;
                                                                                                                                                               sadocontology1:contains_knowledge_about sadocontology1:Business_Logic_Layer, sadocontology1:Extensibility_of_data_sources, sadocontology1:Extractor, sadocontology1:Performance, sadocontology1:Pull_data, sadocontology1:Push_data, sadocontology1:Transformer, <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:Transformer_(business)>, sadocontology1:data_extraction_technique_-_push_or_pull, sadocontology1:data_layer, <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:extractor_(business)> ;
                                                                                                                                                               a sadocontology1:WikiPage, owl:NamedIndividual ;
                                                                                                                                                               rdfs:label "10 logical and implementation view - background - rationale - receiving pulling data" .

Source of Statements about 10 logical and implementation view - background - rationale - receiving pulling data (without imported statements)

Knowledge Bases

Navigation

Source of Statements about 10 logical and implementation view - background - rationale - receiving pulling data (without imported statements)

OntoWiki

Knowledge Bases

Navigation

Login