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:11_logical_and_implementation_view_-_background_-_rationale_-_coupling_persising_presen> ontowiki_wikipage:content """
	Coupling and persisting/presenting the data

	 

	After the data has been abstracted and gathered, it still needs to be processed. It is useful to have already assigned some properties to users (such as: “is expert on”) and to have made connections between users.

	 

	Making connections between users is relatively simple, for example in an email the sender and recipient can be connected, but deciding when a user is an expert for example is a lot different. There is no obvious way to decide when a user is an expert, there is some sort of rule required to decide when this is the case.

	 

	Thus, to achieve this goal some sort of rule handling is required. In this chapter we will discuss two methods to do this, one in which the rules are hard-coded into the business logic layer and one which uses a business rules engine.

	 

	Hard-coded rules 
	 
	

	The simplest way to achieve this goal is by hard-coding the rules in some service in the business logic layer. When data is being processed, the service is called to decide what properties to give the user. Advantages and disadvantages are listed in the appendix under section:Hard Coded rules

	 

	Business rules engine

	 

	Another possible solution is the implementation of a business rules engine, which according to the Wikipedia page about it (<a href=\"http://en.wikipedia.org/wiki/Business_rules_engine\">http://en.wikipedia.org/wiki/Business_rules_engine</a>) “executes one or more business rules in a runtime production environment”. Advantages and disadvantages are listed in the appendix under section:Business rules engine

	 

	Data storage 
	 
	

	After coupling the data and drawing some conclusions from it, the data needs to be stored in some sort of database.

	 

	After storing this data in the database, we will be able to query it in order to ask questions such as: “Which developers communicate with each other?” or “Who operates as a bridge for communication?” or “Is anyone completely isolated?”. Answering these types of questions is the main goal of the application. In order to conform to the one of the key quality attributes the stakeholders requested, performance, these types of queries need to be able to answer such questions as rapidly as possible.

	 

	A database type that is by far the most popular one around is the relational database. These types of databases have been around since the 1970s and are proven technology with a large community.

	 

	Another option is graph databases, which are relatively new in the field though the graph theory that preceded it is quite a bit older. These are more oriented towards objects and their inter-relationships. This is interesting as getting insight in relations between entities is basically what this application is required to do.

	 

	Therefore we researched these two possibilities for storing the data processed in the Business Layer. First we’ll briefly explain how both the relational database and the graph database work. Next, we’ll discuss its advantages and disadvantages and finally conclude by saying how well fit either approach is for this problem and which solution we recommend.

	 """ ;
 sadocontology1:contains_knowledge_about sadocontology1:Analsyis_data_in_graph_database, sadocontology1:Analsyis_database_is_relational, sadocontology1:Analysis_database_type, sadocontology1:Business_Logic_Layer, sadocontology1:Business_rules_engine, sadocontology1:Performance, sadocontology1:Rule_handling, sadocontology1:Use_of_business_rules_engine, sadocontology1:Use_of_hard-coded_rules, sadocontology1:user ;
 a sadocontology1:WikiPage, owl:NamedIndividual ;
 rdfs:label "11 logical and implementation view - background - rationale - coupling_persising_presenting 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:11_logical_and_implementation_view_-_background_-_rationale_-_coupling_persising_presen> ontowiki_wikipage:content """<p>
	<strong>Coupling and persisting/presenting the data</strong></p>
<p>
	 </p>
<p>
	After the data has been abstracted and gathered, it still needs to be processed. It is useful to have already assigned some properties to users (such as: “is expert on”) and to have made connections between users.</p>
<p>
	 </p>
<p>
	Making connections between users is relatively simple, for example in an email the sender and recipient can be connected, but deciding when a user is an expert for example is a lot different. There is no obvious way to decide when a user is an expert, there is some sort of rule required to decide when this is the case.</p>
<p>
	 </p>
<p>
	Thus, to achieve this goal some sort of rule handling is required. In this chapter we will discuss two methods to do this, one in which the rules are hard-coded into the business logic layer and one which uses a business rules engine.</p>
<p>
	 </p>
<p>
	<strong>Hard-coded rules<br />
	<br />
	</strong></p>
<p>
	The simplest way to achieve this goal is by hard-coding the rules in some service in the business logic layer. When data is being processed, the service is called to decide what properties to give the user. Advantages and disadvantages are listed in the appendix under section:Hard Coded rules</p>
<p>
	 </p>
<p>
	<strong>Business rules engine</strong></p>
<p>
	 </p>
<p>
	Another possible solution is the implementation of a business rules engine, which according to the Wikipedia page about it (<a href=\"http://en.wikipedia.org/wiki/Business_rules_engine\"><em>http://en.wikipedia.org/wiki/Business_rules_engine</em></a><em>)</em> “executes one or more business rules in a runtime production environment”. Advantages and disadvantages are listed in the appendix under section:Business rules engine</p>
<p>
	 </p>
<p>
	<strong>Data storage<br />
	<br />
	</strong></p>
<p>
	After coupling the data and drawing some conclusions from it, the data needs to be stored in some sort of database.</p>
<p>
	 </p>
<p>
	After storing this data in the database, we will be able to query it in order to ask questions such as: “Which developers communicate with each other?” or “Who operates as a bridge for communication?” or “Is anyone completely isolated?”. Answering these types of questions is the main goal of the application. In order to conform to the one of the key quality attributes the stakeholders requested, performance, these types of queries need to be able to answer such questions as rapidly as possible.</p>
<p>
	 </p>
<p>
	A database type that is by far the most popular one around is the relational database. These types of databases have been around since the 1970s and are proven technology with a large community.</p>
<p>
	 </p>
<p>
	Another option is graph databases, which are relatively new in the field though the graph theory that preceded it is quite a bit older. These are more oriented towards objects and their inter-relationships. This is interesting as getting insight in relations between entities is basically what this application is required to do.</p>
<p>
	 </p>
<p>
	Therefore we researched these two possibilities for storing the data processed in the Business Layer. First we’ll briefly explain how both the relational database and the graph database work. Next, we’ll discuss its advantages and disadvantages and finally conclude by saying how well fit either approach is for this problem and which solution we recommend.</p>
<p>
	 </p>""" ;
                                                                                                                                                                   sadocontology1:contains_knowledge_about sadocontology1:Analsyis_data_in_graph_database, sadocontology1:Analsyis_database_is_relational, sadocontology1:Analysis_database_type, sadocontology1:Business_Logic_Layer, sadocontology1:Business_rules_engine, sadocontology1:Performance, sadocontology1:Rule_handling, sadocontology1:Use_of_business_rules_engine, sadocontology1:Use_of_hard-coded_rules, sadocontology1:user ;
                                                                                                                                                                   a sadocontology1:WikiPage, owl:NamedIndividual ;
                                                                                                                                                                   rdfs:label "11 logical and implementation view - background - rationale - coupling_persising_presenting data" .

Source of Statements about 11 logical and implementation view - background - rationale - coupling_persising_presenting data (without imported statements)

Knowledge Bases

Navigation

Source of Statements about 11 logical and implementation view - background - rationale - coupling_persising_presenting data (without imported statements)

OntoWiki

Knowledge Bases

Navigation

Login