--- pl:miw:miw08_ruleruntimej [2008/05/30 08:44]
miw
+++ pl:miw:miw08_ruleruntimej [2019/06/27 15:50] (aktualna)
@@ Linia 1: / Linia 1: @@
 ====== Opis ======
+__**Projekt zakończony**__
 Realizujący:
 **Marcin Gadamer** <marcin.gadamer@gmail.com>
@@ Linia 13: / Linia 15: @@
   * output
 How to integrate Prolog and Java in the best way regarding performance, and coding easiness + examples.
 [[pl:miw:miw2008_tematy#ruleruntimej|MIW temat]]
-====== Spotkania ======
-===== 08.03.04 =====
+====== Sprawozdanie ======
-===== 080401 =====
+===== What is Jena =====
-  * Porównanie API Jeny i RDF SWI Prologu
+Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.
-  * jak zapisywać //reguły// w Jenie?
-  * jaka jest różnica w sile ekspresji reguł jeny i Prologu?
-  * opis dostarczonych z Jeną mechanizmów wnioskujących (reasoners)
+Jena is open source and grown out of work with the HP Labs Semantic Web Programme.
-===== 080415 =====
+The Jena Framework includes:
-  * przykład [[hekate:hekate_case_thermostat|termostatu]] w RDF w Jenie
+    * A RDF API
+    * Reading and writing RDF in RDF/XML, N3 and N-Triples
+    * An OWL API
+    * In-memory and persistent storage
+    * SPARQL query engine
-===== 080429 =====
+[[http://jena.sourceforge.net/ | Źródło]]
-  * warunki, pobieranie param od użytkow, pobranie z systemu
-  * akcje, odpalanie metod?
-  * [[hekatedev:xtt_minicases|minicases]]
+===== RDF =====
+The Resource Description Framework (RDF) is a standard (technically a W3C Recommendation) for describing resources. Resource is anything we can identify.
-===== 080520 =====
+RDF is best thought of in the form of node.
-  * spisywanie sprawozd.: opis jeny, repr reguł w rdf, realizacja therm w jenie,
-  * [[http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=node/15|translacja]] [[pl:miw:miw08_xtt_r2ml|therm w r2ml]] do jena (production rules)
-  * próba translacji [[hekate:hekate_markup_language#xttml|XTTML]] do Jena?
-===== 080527 =====
+**Resources have properties**. The name of resources and properties are also a URI, but as URI's are rather long and cumbersome, the diagram shows it in XML qname form. The part before the ':' is called a namespace prefix and represents a namespace. The part after the ':' is called a local name and represents a name in that namespace. Properties are usually represented in this qname form when written as RDF XML and it is a convenient shorthand for representing them in diagrams and in text. Strictly, however, properties are identified by a URI. The nsprefix:localname form is a shorthand for the URI of the namespace concatenated with the localname. There is no requirement that the URI of a property resolve to anything when accessed by a browser.
-  * beta sprawozd
-====== Projekt ======
+Each **property has a value**.
-  * "implementacja" jsr94 w prologu
-  * możliwość/sensowność jess/prolog
-===== Jena wstęp na przykładzie rodziny=====
-Ponieważ Jess można używać jedynie przez 30 dni, wykorzystuję do integracji framework Jena.
+[[http://jena.sourceforge.net/tutorial/RDF_API/index.html | Źródło]]
-  * Jednym z zalet Jeny jest czytanie/zapisywanie RDF w RDF/XML, N3 oraz N-Triples. Stąd słuszne wydaje się podejście
- Prolog <-przedstawienie wiedzy-> RDF <-przedstawienie wiedzy-> Java
-  * Mały program w Java, który pokazuje relacje pomiędzy tatą (Jan), mamą (Krystyna), córką (Kasia), synem (Jasiu)
+===== Building model in Jena =====
+Jena is a Java API which can be used to create and manipulate RDF graphs. Jena has object classes to represent graphs, resources, properties and literals. The interfaces representing resources, properties and literals are called Resource, Property and Literal respectively. In Jena, a graph is called a model and is represented by the Model interface.
+The code to create a graph, or model, is simple:
+<code java>
+    // some definitions
+    static String personURI    = "http://somewhere/JohnSmith";
+    static String fullName     = "John Smith";
+    // create an empty Model
+    Model model = ModelFactory.createDefaultModel();
+    // create the resource
+    Resource johnSmith = model.createResource(personURI);
+    // add the property
+     johnSmith.addProperty(VCARD.FN, fullName);
+</code>
+It begins with some constant definitions and then creates an empty Model or model, using the ModelFactory method createDefaultModel() to create a memory-based model. Jena contains other implementations of the Model interface, e.g one which uses a relational database: these types of Model are also available from ModelFactory.
+The John Smith resource is then created and a property added to it. The property is provided by a "constant" class VCARD which holds objects representing all the definitions in the VCARD schema. Jena provides constant classes for other well known schemas, such as RDF and RDF schema themselves, Dublin Core and DAML.
+The code to create the resource and add the property, can be more compactly written in a cascading style:
+<code java>
+    Resource johnSmith =
+            model.createResource(personURI)
+                 .addProperty(VCARD.FN, fullName);
+</code>
+Now let's add some more detail to the vcard, exploring some more features of RDF and Jena.
+RDF properties can also take other resources as their value.
+Let's add a new property, vcard:N, to represent the structure of John Smith's name. There are several things of interest about this Model. Note that the vcard:N property takes a resource as its value. Note also that the ellipse representing the compound name has no URI. It is known as an blank Node.
+The Jena code to construct this example, is again very simple. First some declarations and the creation of the empty model.
+<code java>
+    // some definitions
+    String personURI    = "http://somewhere/JohnSmith";
+    String givenName    = "John";
+    String familyName   = "Smith";
+    String fullName     = givenName + " " + familyName;
+    // create an empty Model
+    Model model = ModelFactory.createDefaultModel();
+    // create the resource
+    //   and add the properties cascading style
+    Resource johnSmith
+      = model.createResource(personURI)
+             .addProperty(VCARD.FN, fullName)
+             .addProperty(VCARD.N,
+                          model.createResource()
+                               .addProperty(VCARD.Given, givenName)
+                               .addProperty(VCARD.Family, familyName));
+</code>
+[[http://jena.sourceforge.net/tutorial/RDF_API/index.html | Źródło]]
+===== Overview of the rule engine(s) =====
+Jena2 includes a general purpose rule-based reasoner which is used to implement both the RDFS and OWL reasoners but is also available for general use. This reasoner supports rule-based inference over RDF graphs and provides forward chaining, backward chaining and a hybrid execution model. To be more exact, there are two internal rule engines one forward chaining RETE engine and one tabled datalog engine - they can be run separately or the forward engine can be used to prime the backward engine which in turn will be used to answer queries.
+The various engine configurations are all accessible through a single parameterized reasoner GenericRuleReasoner. At a minimum a GenericRuleReasoner requires a ruleset to define its behaviour. A GenericRuleReasoner instance with a ruleset can be used like any of the other reasoners described above - that is it can be bound to a data model and used to answer queries to the resulting inference model.
+The rule reasoner can also be extended by registering new procedural primitives. The current release includes a starting set of primitives which are sufficient for the RDFS and OWL implementations but is easily extensible.
+[[http://jena.sourceforge.net/inference/#rules | Źródło]]
+===== Rule syntax and structure =====
+A rule for the rule-based reasoner is defined by a Java Rule object with a list of body terms (premises), a list of head terms (conclusions) and an optional name and optional direction. Each term or ClauseEntry is either a triple pattern, an extended triple pattern or a call to a builtin primitive. A rule set is simply a List of Rules.
+For convenience a rather simple parser is included with Rule which allows rules to be specified in reasonably compact form in text source files. However, it would be perfectly possible to define alternative parsers which handle rules encoded using, say, XML or RDF and generate Rule objects as output. It would also be possible to build a real parser for the current text file syntax which offered better error recovery and diagnostics.
+An informal description of the simplified text rule syntax is:
+<code>
+Rule      :=   bare-rule .
+          or   [ bare-rule ]
+	      or   [ ruleName : bare-rule ]
+bare-rule :=   term, ... term -> hterm, ... hterm    // forward rule
+          or   term, ... term <- term, ... term    // backward rule
+hterm     :=   term
+          or   [ bare-rule ]
+term      :=   (node, node, node)           // triple pattern
+          or   (node, node, functor)        // extended triple pattern
+          or   builtin(node, ... node)      // invoke procedural primitive
+functor   :=   functorName(node, ... node)  // structured literal
+node      :=   uri-ref		               // e.g. http://foo.com/eg
+          or   prefix:localname		       // e.g. rdf:type
+          or   <uri-ref>		       // e.g. <myscheme:myuri>
+          or   ?varname                    // variable
+          or   'a literal'                 // a plain string literal
+          or   'lex'^^typeURI              // a typed literal, xsd:* type names supported
+          or   number                      // e.g. 42 or 25.5
+</code>
+The "," separators are optional.
+The difference between the forward and backward rule syntax is only relevant for the hybrid execution strategy, see below.
+The functor in an extended triple pattern is used to create and access structured literal values. The functorName can be any simple identifier and is not related to the execution of builtin procedural primitives, it is just a datastructure. It is useful when a single semantic structure is defined across multiple triples and allows a rule to collect those triples together in one place.
+To keep rules readable qname syntax is supported for URI refs. The set of known prefixes is those registered with the PrintUtil object. This initially knows about rdf, rdfs, owl, daml, xsd and a test namespace eg, but more mappings can be registered in java code. In addition it is possible to define additional prefix mappings in the rule file, see below.
+Here are some example rules which illustrate most of these constructs:
+<code>
+[allID: (?C rdf:type owl:Restriction), (?C owl:onProperty ?P),
+     (?C owl:allValuesFrom ?D)  -> (?C owl:equivalentClass all(?P, ?D)) ]
+[all2: (?C rdfs:subClassOf all(?P, ?D)) -> print('Rule for ', ?C)
+		[all1b: (?Y rdf:type ?D) <- (?X ?P ?Y), (?X rdf:type ?C) ] ]
+[max1: (?A rdf:type max(?P, 1)), (?A ?P ?B), (?A ?P ?C)
+      -> (?B owl:sameAs ?C) ]
+</code>
+Rule allID illustrates the functor use for collecting the components of an OWL restriction into a single datastructure which can then fire further rules. Rule all2 illustrates a forward rule which creates a new backward rule and also calls the print procedural primitive. Rule max1 illustrates use of numeric literals.
+Rule files may be loaded and parsed using:
+<code>
+List rules = Rule.rulesFromURL("file:myfile.rules");
+</code>
+or
+<code>
+BufferedReader br = /* open reader */ ;
+List rules = Rule.parseRules( Rule.rulesParserFromReader(br) );
+</code>
+or
+<code>
+String ruleSrc = /* list of rules in line */
+List rules = Rule.parseRules( rulesSrc );
+</code>
+@prefix pre: <http://domain/url#>.
+    Defines a prefix pre which can be used in the rules. The prefix is local to the rule file.
+@include <urlToRuleFile>.
+    Includes the rules defined in the given file in this file. The included rules will appear before the user defined rules, irrespective of where in the file the @include directive appears. A set of special cases is supported to allow a rule file to include the predefined rules for RDFS and OWL - in place of a real URL for a rule file use one of the keywords RDFS OWL OWLMicro OWLMini (case insensitive).
+So an example complete rule file which includes the RDFS rules and defines a single extra rule is:
+<code>
+# Example rule file
+@prefix pre: <http://jena.hpl.hp.com/prefix#>.
+@include <RDFS>.
+[rule1: (?f pre:father ?a) (?u pre:brother ?f) -> (?u pre:uncle ?a)]
+</code>
+[[http://jena.sourceforge.net/inference/#rules | Źródło]]
+===== Model rodziny =====
+Pierwszy model jaki utworzyłem w Javie z wykorzystaniem frameworku Jena był model rodziny. Pokazywał on proste relacje pomiędzy tatą (Jan), mamą (Krystyna), córką (Kasia), synem (Jasiu)
 Zostały zapisane następujące dane:
@@ Linia 112: / Linia 278: @@
     http://Family/KowalskiJasiu
-=====SPARQL=====
- Zapytania buduje się podobnie jak w języku zapytań SQL z tą różnicą, że podaje się całą trójkę.
+===== SPARQL =====
+Następnym etapem mojej pracy było poznanie reguł budowania zapytań językiem SPARQL.
+SPARQL (ang. SPARQL Protocol And RDF Query Language) jest językiem zapytań i protokołem dla plików RDF. SPARQL pozwala wyciągać z nich dane zawężone według kryteriów określonych poprzez predykaty RDF. Jest opisany przez kilka specyfikacji W3C. W tej chwili wszystkie specyfikacje mają status szkicu. [[http://pl.wikipedia.org/wiki/SPARQL | Źródło]]
+Zapytania buduje się podobnie jak w języku zapytań SQL z tą różnicą, że podaje się całą trójkę.
 Zapytanie SPARQL dla podanego powyżej przykładu może wyglądać tak:
@@ Linia 122: / Linia 294: @@
 Oznacza to podgląd całej wiedzy, która jest zawarta w modelu.
-Na takie zapytanie uzyskałem taką odpowiedź:
+Ponieważ posłużyłem się językiem SPARQL na modelu rodziny, który został wcześniej już utworzony, wszelkie rezultaty będą przedstawione dla tych relacji. Na zapytanie takie uzyskałem odpowiedź:
 <code>
 Jasiu dziecko Jan
@@ Linia 135: / Linia 307: @@
 </code>
-Jak widać są to wszytkie informacje, które zawarłem w modelu. (Dla czytelności zostały usunięte URI, aby odpowiedź nie wygdlądała np. tak     http://Family/KowalskiJan)
+Jak widać są to wszytkie informacje, które zawarłem w modelu. (Dla czytelności zostały usunięte URI, aby odpowiedź nie wyglądała np. tak     http://Family/KowalskiJan)
 Znając zasadę tworzenia zapytania, można otrzymać odpowiedź na "skomplikowane" zapytanie.
 =====Termostat - RDF=====
-Aby stworzyć plik RDF reprezentujący model termostatu, najpierw utworzyłem model termostatu wg. reguł.
+Aby stworzyć plik RDF reprezentujący model [[hekate:hekate_case_thermostat| termostatu]], najpierw utworzyłem model termostatu wg wszystkich reguł. Podczas tworzenia modelu zapisywałem w komentarzu, której reguły dotyczą tworzone resource'y oraz propertis'y
 Aby plik taki został wygenerowany ścieżki do resoure'ów oraz propertis'ów muszą być unikalne stąd musiałem stworzyć dwa Stringi, którymi poprzedzałem każdy z nich.
@@ Linia 226: / Linia 399: @@
 		//11 12 13
 		Resource operation = model.createResource(resourceUri + "operation");
@@ Linia 308: / Linia 483: @@
 </code>
@@ Linia 340: / Linia 512: @@
 </code>
-  * Następnie tworzony jest model (na którym będziemy przeprowadzać wnioskowanie). Ponieważ musimy uwzględnić podane wcześniej informacje, dodajemy je (i tylko je) do modelu.
+  * Następnie tworzony jest model (na którym będziemy przeprowadzać wnioskowanie). Ponieważ musimy uwzględnić podane wcześniej informacje, dodajemy je (i tylko je) do modelu. W poprzednim punkcie został zapisany cały model termostatu, jednak reguły wnioskowania obejmują cały model, więc nie uzyskalibyśmy spodziewanego efektu gdyby wszystko w modelu było już zapisane. Do stworzonego na początku modelu musimy podać tylko niezbędne informacje, a następnie uruchomić wszelkie reguły.
+Model zapisałem tak:
 <code java>
     //creating new model
@@ Linia 588: / Linia 762: @@
 </code>
 ===== Translacja r2ml do reguł Jeny =====
@@ Linia 796: / Linia 968: @@
-====== Sprawozdanie ======
-===== What is Jena =====
-Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.
-Jena is open source and grown out of work with the HP Labs Semantic Web Programme.
-The Jena Framework includes:
-    * A RDF API
-    * Reading and writing RDF in RDF/XML, N3 and N-Triples
-    * An OWL API
-    * In-memory and persistent storage
-    * SPARQL query engine
-===== RDF =====
-The Resource Description Framework (RDF) is a standard (technically a W3C Recommendation) for describing resources. Resource is anything we can identify.
-RDF is best thought of in the form of node.
-**Resources have properties**. The name of resources and properties are also a URI, but as URI's are rather long and cumbersome, the diagram shows it in XML qname form. The part before the ':' is called a namespace prefix and represents a namespace. The part after the ':' is called a local name and represents a name in that namespace. Properties are usually represented in this qname form when written as RDF XML and it is a convenient shorthand for representing them in diagrams and in text. Strictly, however, properties are identified by a URI. The nsprefix:localname form is a shorthand for the URI of the namespace concatenated with the localname. There is no requirement that the URI of a property resolve to anything when accessed by a browser.
-Each **property has a value**.
-===== Building model in Jena =====
-Jena is a Java API which can be used to create and manipulate RDF graphs. Jena has object classes to represent graphs, resources, properties and literals. The interfaces representing resources, properties and literals are called Resource, Property and Literal respectively. In Jena, a graph is called a model and is represented by the Model interface.
-The code to create a graph, or model, is simple:
-<code java>
-    // some definitions
-    static String personURI    = "http://somewhere/JohnSmith";
-    static String fullName     = "John Smith";
-    // create an empty Model
-    Model model = ModelFactory.createDefaultModel();
-    // create the resource
-    Resource johnSmith = model.createResource(personURI);
-    // add the property
-     johnSmith.addProperty(VCARD.FN, fullName);
-</code>
-It begins with some constant definitions and then creates an empty Model or model, using the ModelFactory method createDefaultModel() to create a memory-based model. Jena contains other implementations of the Model interface, e.g one which uses a relational database: these types of Model are also available from ModelFactory.
-The John Smith resource is then created and a property added to it. The property is provided by a "constant" class VCARD which holds objects representing all the definitions in the VCARD schema. Jena provides constant classes for other well known schemas, such as RDF and RDF schema themselves, Dublin Core and DAML.
-The code to create the resource and add the property, can be more compactly written in a cascading style:
-<code java>
-    Resource johnSmith =
-            model.createResource(personURI)
-                 .addProperty(VCARD.FN, fullName);
-</code>
-Now let's add some more detail to the vcard, exploring some more features of RDF and Jena.
-RDF properties can also take other resources as their value.
-Let's add a new property, vcard:N, to represent the structure of John Smith's name. There are several things of interest about this Model. Note that the vcard:N property takes a resource as its value. Note also that the ellipse representing the compound name has no URI. It is known as an blank Node.
-The Jena code to construct this example, is again very simple. First some declarations and the creation of the empty model.
-<code java>
-    // some definitions
-    String personURI    = "http://somewhere/JohnSmith";
-    String givenName    = "John";
-    String familyName   = "Smith";
-    String fullName     = givenName + " " + familyName;
-    // create an empty Model
-    Model model = ModelFactory.createDefaultModel();
-    // create the resource
-    //   and add the properties cascading style
-    Resource johnSmith
-      = model.createResource(personURI)
-             .addProperty(VCARD.FN, fullName)
-             .addProperty(VCARD.N,
-                          model.createResource()
-                               .addProperty(VCARD.Given, givenName)
-                               .addProperty(VCARD.Family, familyName));
-</code>
-===== Overview of the rule engine(s) =====
-Jena2 includes a general purpose rule-based reasoner which is used to implement both the RDFS and OWL reasoners but is also available for general use. This reasoner supports rule-based inference over RDF graphs and provides forward chaining, backward chaining and a hybrid execution model. To be more exact, there are two internal rule engines one forward chaining RETE engine and one tabled datalog engine - they can be run separately or the forward engine can be used to prime the backward engine which in turn will be used to answer queries.
-The various engine configurations are all accessible through a single parameterized reasoner GenericRuleReasoner. At a minimum a GenericRuleReasoner requires a ruleset to define its behaviour. A GenericRuleReasoner instance with a ruleset can be used like any of the other reasoners described above - that is it can be bound to a data model and used to answer queries to the resulting inference model.
-The rule reasoner can also be extended by registering new procedural primitives. The current release includes a starting set of primitives which are sufficient for the RDFS and OWL implementations but is easily extensible.
-===== Rule syntax and structure =====
-A rule for the rule-based reasoner is defined by a Java Rule object with a list of body terms (premises), a list of head terms (conclusions) and an optional name and optional direction. Each term or ClauseEntry is either a triple pattern, an extended triple pattern or a call to a builtin primitive. A rule set is simply a List of Rules.
-For convenience a rather simple parser is included with Rule which allows rules to be specified in reasonably compact form in text source files. However, it would be perfectly possible to define alternative parsers which handle rules encoded using, say, XML or RDF and generate Rule objects as output. It would also be possible to build a real parser for the current text file syntax which offered better error recovery and diagnostics.
-An informal description of the simplified text rule syntax is:
-<code>
-Rule      :=   bare-rule .
-          or   [ bare-rule ]
-	      or   [ ruleName : bare-rule ]
-bare-rule :=   term, ... term -> hterm, ... hterm    // forward rule
-          or   term, ... term <- term, ... term    // backward rule
-hterm     :=   term
-          or   [ bare-rule ]
-term      :=   (node, node, node)           // triple pattern
-          or   (node, node, functor)        // extended triple pattern
-          or   builtin(node, ... node)      // invoke procedural primitive
-functor   :=   functorName(node, ... node)  // structured literal
-node      :=   uri-ref		               // e.g. http://foo.com/eg
-          or   prefix:localname		       // e.g. rdf:type
-          or   <uri-ref>		       // e.g. <myscheme:myuri>
-          or   ?varname                    // variable
-          or   'a literal'                 // a plain string literal
-          or   'lex'^^typeURI              // a typed literal, xsd:* type names supported
-          or   number                      // e.g. 42 or 25.5
-</code>
-The "," separators are optional.
-The difference between the forward and backward rule syntax is only relevant for the hybrid execution strategy, see below.
-The functor in an extended triple pattern is used to create and access structured literal values. The functorName can be any simple identifier and is not related to the execution of builtin procedural primitives, it is just a datastructure. It is useful when a single semantic structure is defined across multiple triples and allows a rule to collect those triples together in one place.
-To keep rules readable qname syntax is supported for URI refs. The set of known prefixes is those registered with the PrintUtil object. This initially knows about rdf, rdfs, owl, daml, xsd and a test namespace eg, but more mappings can be registered in java code. In addition it is possible to define additional prefix mappings in the rule file, see below.
-Here are some example rules which illustrate most of these constructs:
-<code>
-[allID: (?C rdf:type owl:Restriction), (?C owl:onProperty ?P),
-     (?C owl:allValuesFrom ?D)  -> (?C owl:equivalentClass all(?P, ?D)) ]
-[all2: (?C rdfs:subClassOf all(?P, ?D)) -> print('Rule for ', ?C)
-		[all1b: (?Y rdf:type ?D) <- (?X ?P ?Y), (?X rdf:type ?C) ] ]
-[max1: (?A rdf:type max(?P, 1)), (?A ?P ?B), (?A ?P ?C)
-      -> (?B owl:sameAs ?C) ]
-</code>
-Rule allID illustrates the functor use for collecting the components of an OWL restriction into a single datastructure which can then fire further rules. Rule all2 illustrates a forward rule which creates a new backward rule and also calls the print procedural primitive. Rule max1 illustrates use of numeric literals.
-Rule files may be loaded and parsed using:
-<code>
-List rules = Rule.rulesFromURL("file:myfile.rules");
-</code>
-or
-<code>
-BufferedReader br = /* open reader */ ;
-List rules = Rule.parseRules( Rule.rulesParserFromReader(br) );
-</code>
-or
-<code>
-String ruleSrc = /* list of rules in line */
-List rules = Rule.parseRules( rulesSrc );
-</code>
-In the first two cases (reading from a URL or a BufferedReader) the rule file is preprocessed by a simple processor which strips comments and supports some additional macro commands:
-# ...
-    A comment line.
-// ...
-    A comment line.
-@prefix pre: <http://domain/url#>.
-    Defines a prefix pre which can be used in the rules. The prefix is local to the rule file.
-@include <urlToRuleFile>.
-    Includes the rules defined in the given file in this file. The included rules will appear before the user defined rules, irrespective of where in the file the @include directive appears. A set of special cases is supported to allow a rule file to include the predefined rules for RDFS and OWL - in place of a real URL for a rule file use one of the keywords RDFS OWL OWLMicro OWLMini (case insensitive).
-So an example complete rule file which includes the RDFS rules and defines a single extra rule is:
-<code>
-# Example rule file
-@prefix pre: <http://jena.hpl.hp.com/prefix#>.
-@include <RDFS>.
-[rule1: (?f pre:father ?a) (?u pre:brother ?f) -> (?u pre:uncle ?a)]
-</code>
 ====== Dotychczasowy przebieg pracy ======
 Szcegóły pracy nad tym tematem można znaleźć [[pl:miw:miw08_ruleruntimej:przebieg_pracy| tutaj]]
-====== Materiały ======
-===== Basic =====
-[[http://jena.sourceforge.net/documentation.html| Dokumentacja]] - Dokumentacja do frameworka Jena
-[[http://www.ibm.com/developerworks/xml/library/j-jena/index.html| IBM]] - Wprowadzenie do Jena wykonane przez IBMa
-[[http://www.oreilly.com/catalog/pracrdf/chapter/ch08.pdf|RDF]] - wszytstko o RDF - PDF wykonany przez wydawnictwo O'Reilly
-[[http://pl.wikipedia.org/wiki/System_ekspertowy| System ekspertowy]] - Wikipedia
-[[http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html| Java Rule Engine API]] - Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications (Sun)
-[[http://javaboutique.internet.com/tutorials/rules_engine/| Java Rules Engine API (JSR 94)]] - Java Rules Engine API (JSR 94) in javaboutique
-===== Jena + SPARQL =====
-[[http://www.ibm.com/developerworks/xml/library/j-sparql/| RDF in SPARQL]] - Search RDF data with SPARQL
-[[http://jena.sourceforge.net/ARQ/| AQR]] - Query engine for Jena
-[[http://2006.ruleml.org/slides/tutorial-holger.pdf| Rules Example]] - Rules example using Jena + Pellet (pdf file!)
-===== Jena rules =====
-[[http://jena.sourceforge.net/inference/index.html#rules| Jena rules page]] - Jena rules documentation
-[[http://www.ldodds.com/blog/archives/000219.html| Example]] -  Rules in Jena example
-[[http://jena.hpl.hp.com/juc2006/proceedings/reynolds/rules-slides.ppt| Examlpe2]] - HP Example of using Jena Rules (ppt file!)
-===== Prolog =====
-[[http://www.swi-prolog.org/packages/rdf2pl.html| Prolog parser]] - SWI-Prolog RDF parser
-[[http://www.swi-prolog.org/packages/semweb.html| Semantic Web Library]] - SWI-Prolog Semantic Web Library
-[[http://www.xml.com/pub/a/2001/07/25/prologrdf.html| RDF in Prolog]] - RDF Applications with Prolog

pl/miw/miw08_ruleruntimej.1212129898.txt.gz · ostatnio zmienione: 2019/06/27 15:58 (edycja zewnętrzna)

Pokaż stronę Poprzednie wersje

Menadżer multimediów Do góry

AIwiki

Menu

Dla Studentów

Old specialized AI courses

SMaDA/SMaIDA/AIDA

Informatyka (EAIiIB)

Studia Dr

Inne materialy dydaktyczne

Archiwum

Dyplomanci

Geist Season of Code

HeKatE

Public

Różnice