graph_manipulation
====== Differences ====== This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
graph_manipulation [2012/11/25 19:53] hsolbrig |
graph_manipulation [2012/11/25 21:35] hsolbrig |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | APIs for graph manipulation (derived from CTS2 specification) [[start|Link to API4KB Main Page]] | + | ====== APIs for graph manipulation ====== |
| + | [[start|Link to API4KB Main Page]] | ||
| The terminology and requirements are derived from the CTS2 specification. | The terminology and requirements are derived from the CTS2 specification. | ||
| - | A note on the terminology used below: | + | ===== A note on the terminology used below: ===== |
| * **Graph** - A named collection of assertions. Graphs are assumed to be immutable - if the set of assertions changes in a graph, the graph is given a different name. Graphs implicitly include any logical conclusions that can be drawn from the application of one or more sound, monotonic reasoning algorithms to the assertions in the graph. | * **Graph** - A named collection of assertions. Graphs are assumed to be immutable - if the set of assertions changes in a graph, the graph is given a different name. Graphs implicitly include any logical conclusions that can be drawn from the application of one or more sound, monotonic reasoning algorithms to the assertions in the graph. | ||
| * **Assertion** - a "triple" consisting of a named predicate, a subject and an object where: | * **Assertion** - a "triple" consisting of a named predicate, a subject and an object where: | ||
| Line 16: | Line 17: | ||
| The key distinction between the terminology used above and that used in classic RDF is that the subject of an assertion must be the name of a persistent resource - not a BNODE. | The key distinction between the terminology used above and that used in classic RDF is that the subject of an assertion must be the name of a persistent resource - not a BNODE. | ||
| - | * Requirements: | + | ===== Requirements: ===== |
| - | * Return the URI of a graph given the URI of a source file (RDF / OWL / ...). | + | ==== Return the URI of a graph given the URI of a source file (RDF / OWL / ...) ==== |
| * Inputs: URI of source file | * Inputs: URI of source file | ||
| * Return: URI of graph | * Return: URI of graph | ||
| Line 24: | Line 25: | ||
| * Assertions that are are derived from the application of one or more sound, monotonic reasoning algorithms need to be identified as "derived" (vs. "asserted") and it should be possible to determine which algorithm(s) were used to reach the conclusion | * Assertions that are are derived from the application of one or more sound, monotonic reasoning algorithms need to be identified as "derived" (vs. "asserted") and it should be possible to determine which algorithm(s) were used to reach the conclusion | ||
| * Assertions that are both asserted //and// derived should be marked as asserted. | * Assertions that are both asserted //and// derived should be marked as asserted. | ||
| - | * Create a new graph that contains the union of two or more existing graphs | + | ==== Create a new graph that contains the union of two or more existing graphs ==== |
| * Inputs: List of graph URIs | * Inputs: List of graph URIs | ||
| * Return: URI of new graph | * Return: URI of new graph | ||
| * Notes: Assertion provenance must be maintained - every assertion must include the name of the graph(s) from which it was derived | * Notes: Assertion provenance must be maintained - every assertion must include the name of the graph(s) from which it was derived | ||
| - | * Return a graph that contains the intersection of two or more existing graphs | + | ==== Apply one or more constraints to a graph producing a new graph ==== |
| - | * Inputs: List of graph URIs | + | * Inputs: A set of constraints that includes: |
| - | * Return: | + | * Subject constraints - the ability to restrict the set of assertions in a graph to those whose subject is a member of the list |
| + | * Predicate constraints - the ability to restrict the set of assertions in the graph to those whose predicate is a member of the list. | ||
| + | * Target constraints - the ability to restrict the set of assertions in the graph to those whose target: | ||
| + | * Is a member of a list of named uri's | ||
| + | * Matches or approximately matches (via. Regular Expressions and other data matching techniques) a supplied data pattern | ||
| + | * Meets a pattern that matches sub-expressions | ||
| + | * Meets a supplied classifier rule (is a subClass of or is a parent class of a named or resolved graph) | ||
| + | ==== Resolve a graph ==== | ||
| + | * Inputs: URI of a Graph, desired output notation and format (e.g. owl/rdf+xml) | ||
| + | * Output: Resolved graph | ||
| + | * Notes: | ||
| + | - The resolved output graph has to support iterators - there has to be some mechanism to retrieve the results in chunks | ||
| + | - The order of the output graph (sort order) should be specifiable | ||
| + | - The output graph should be able to be constrained to either just asserted or asserted and inferred assertions. The output inferences in the output graph should be based on the entire source graph(s) - not the constraints. (i.e. a R b, b R c, c R d, d R e transitive(R) constrained to "subject a or target e" should yield (a R b, b R d, d R e). | ||
graph_manipulation.txt · Last modified: 2012/11/25 21:35 by hsolbrig
Page Tools
