====== APIs for graph manipulation ====== [[start|Link to API4KB Main Page]] The terminology and requirements are derived from the CTS2 specification. ===== 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. * **Assertion** - a "triple" consisting of a named predicate, a subject and an object where: * **Subject** - the name of a resource * **Predicate** - a binary relation * **Target** - one of: - the name of a resource - string, number, date or other structured data type - A collection of one or more predicate/target tuples (referred to as a "BNODE" in the RDF world) - an unordered set or ordered sequence of targets 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: ===== ==== Return the URI of a graph given the URI of a source file (RDF / OWL / ...) ==== * Inputs: URI of source file * Return: URI of graph * Notes: * Provenance needs to be maintained in the resulting graph. Assertions from resources that referenced in the source file (i.e. imports) need to be traceable to the graph from which they were imported. * 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. ==== Create a new graph that contains the union of two or more existing graphs ==== * Inputs: List of graph URIs * 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 ==== Apply one or more constraints to a graph producing a new graph ==== * Inputs: A set of constraints that includes: * 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).