...

1. It has a unique subject URI, and exactly one asserted rdf:type statement.
2. Its rdf:type (possibly an inferred type) is a member of the designated class group indicating embedded instances. In the eagle-i data model the URI of this class group is:

   Code Block
   http://eagle-i.org/ont/app/1.0/ClassGroup_embedded_class

3. It has exactly one parent. There is exactly one instance, which is the subject of statements for which the EI is the object. This is an informal restriction (really an assumption) imposed on all instances of embedded types, although it is enforced by logic in the repository.
4. EIs may not be Orphaned or Shared. Any transaction that would result in an EI left without a parent, in other words it is **{}not{}*  not  the object of any conforming statements, *{}  or* it has multiple parents, is forbidden by logic in the repository. The only way to remove an EI from its parent is to delete all of its statements. You can copy an EI to another parent by creating a new EI under that parent, with a new unique URI for its subject.
5. No Broken Links to EIs. If an EI is removed, an instance cannot retain any statements of which it is the object. These must be removed.
6. EIs do not Have Metadata*.* The repository does not create metadata, Dublin Core, for example, about EIs. Any transactions on the EI are considered transactions on its parent and recorded as such, in the last-modified date in the metadata.
7. Transactional Integrity All transactional operations, such as /update and workflow, operate on the EI statements together with the parent instance's statements. For example, a workflow transition to published moves all the EIs to the published graph along with their parent's statements.
8. EIs reside in the same graph as the parent. Though it seems obvious, it's worth stating formally that the statements describing an EI must reside in the same named graph (workspace) as the statements of its parent.

...

Modification/Deletion: Any modification of an EI must be done as a modification of its parent. The EI's properties, including type, may be changed; it may be deleted. These changes are recorded as a modification of the parent. The changes to the parent and its EIs can be driven by one HTTP request to the update service, and will be performed in a single transaction.

...

The repository only gets involved to mediate this contact process because it is also responsible for hiding all contact information from the agents who would use it. It must therefore implement some means of accepting a contact request or message from the outside agent, and forward it to the determined owner of the resource.

...

1. Ontology---contains ontology descriptions, so reasoning may be required. The name of the graph is the namespace URI. Also implies that the graph is part of the "TBox" for inferencing.
2. Metadata---contains the repository's own metadata; public and private metadata are in separate graphs for easier containment of query results.
3. *Workspace*---holds resource instances still in the process of editing and curation. Not visible to the public, and access to some workspaces is restricted to a subset of users.
4. *Published*--Published resource description data.
5. Internal---Contains data that is only to be used internally by repository code and never exposed.

...

• published---all resource instances and user records visible to the public, and all relevant ontologies and metadata.
• published-resources ---just resource instances visible to the public, and all relevant ontologies and metadata.
• metadata---all named graphs of type Metadata visible to the authenticated user.
• ontology---all named graphs of type Ontology visible to the authenticated user
• metadata+ontology---all named graphs of types Metadata and Ontology visible to the authenticated user
• null ---all statements in the internal RDF database regardless of named graph.
  • Administrators only.
  • NOTE: This is the ONLY way to see any statements that do not belong to any named graph, i.e. the "null context" in Sesame. If we are lucky this will be a small or empty set.
• user ---those graphs which the current user has permission to read.
• user-resources ---the graphs containing or related to eagle-i resources which the current user has permission to read. Note that the graph containing instances of repository users (i.e. of type foaf:Person) is, ironically, NOT part of this datasetdata set, since they are not eagle-i resources.
• public ---all graphs which are visible to the public, i.e. to the anonymous user, plus inferred statements. Note that this is not the same thing as 'published'.
• all ---all named graphs including the ones internal to the repository; administrators only.

Important Note: You may have noticed that according to the definition, the user view is the same as the all view for an administrator user, so why bother creating an all view? It is intended to be specified when you have a query that really must cover all of the named graphs to work properly; if a non-administrator attempts it, it will fail with a permission error, instead of misleadingly returning a subset of the graphs.

...

A workspace is just another way to describe a datasetdata set, by starting with a named graph. It is effectively a special kind of view. The name of a workspace is the URI of its base named graph, which must be of type workspace or published. When you specify that as the workspace, the repository server automatically adds these other graphs to the datasetdata set:

1. All graphs of type Ontology that are readable by the current user.
2. All graphs of type Metadata that are readable by the current user.
3. The graph of inferred statements.
4. The graph of repository user instances (referenced by metadata statements)

...

1. "TBox" inferencing:
   • TBox is the terminology source, i.e. the ontology graphs.
   • It consists of named graphs whose type is ontology.
   • Upon * any change to a TBox graph, inferencing is redone on the entire graph, and on all the ABox graphs.
   • All inferred TBox statements are added as inferred statements directly to their TBox graph.
   • Inference is done independently on every TBox graph they are expected to be completely disjointed. Thus, there should only be one or two TBox graphs.
   • Following entailment rule rdfs11, all inferred rdfs:subClassOf relationships are created as direct statements.
   • Following entailment rule rdfs5, all inferred subPropertyOf relationships are created as direct statements.
   • Following entailment rule rdfs9, all inferred rdf:type properties are added.
2. "ABox" inferencing:
   • ABox is the body of assertions, i.e. the statements about resource instances.
   • All non-TBox named graphs are part of the ABox.
   • All statements created from inference on ABox statements are added to a special named graph, http://eagle-i.org/ont/repo/1.0/NG_Inferred.;
     • This makes it easy to include or exclude the inferred statements in the dataset of SPARQL query
     • You can detect whether or not a statement is inferred by adding a GRAPH keyword to the query and testing its home graph.
   • Any change to a TBox graph only causes re-inferencing of the subject of each statement where a named instance was changed. This is possible because the inferred statements only depend on the asserted rdf:type properties of a a subject and the TBox graphs.
   • Following entailment rule rdfs9, all inferred rdf:type properties are added to the graph for inferred statements.

The TBox graphs are configurable. You can set the configuration property eaglei.repository.tbox.graphs to a comma-separated list of graph URIs. By default, the TBox consists of:

...

URL: /repository/logout (POST only)

*Args: none.

Result:
HTTP status indicates success. Succeeds even if there was no session to destroy.

*Access:
Requires a login and established session.

...

This service either reports on or loads the Data Model Ontology. The GET request returns a report of the version of the ontology loaded, and the version that is available to be automatically loaded from within the repository's codebase. The POST request give a choice of selective update or forcibly replacing the ontology.

URL: /repository{}/admin/model (GET)

Args:
format--- MIME-type of desired output format

...

Manage Internal Graphs (/internal)

URL: /repository{}/internal (GET, POST)

This service manages the internal named graphs which are (usually) automatically initialized by the repository upon bootstrap. Each of these graphs has an initializer data file of seralized RDF that is a versioned part of hte source and gets built into the webapp. This API service lets you get the initializers and read or query them so that e.g. an upgrade procedure can integrate differences into a locally-modified internal graph.

...

Args:
format---optionally override the dissemination format that would be chosen by HTTP content negotiation. Note that choosing text/html results in a special human-readable result.
view---optionally choose a different view dataset (see Views in concepts section) from which to select the graph for dissemination. Mutually exclusive with workspace. Default is the published-resources view. Be careful to choose a view that does not include repository user instances.
workspace---URI of the workspace named graph to take the place of the default graph.   Relevant metadata and ontology graphs are included automatically.   Mutually exclusive with view.
inferred---When true, includes all inferred statements from the generated results.   This really only applies to rdf:type statements; default is false, so  so inferred types are left out of the results. Must be false when detail=identifier.
from---(optional) only resource instances last modified from (on or later than) this timestamp or later are shown.   See Date/Time Format below.
after---(optional) does the same thing as from, with which it is mutually exclusive, only the time is exclusive rather than inclusive.   That is, only resources modified later than this timestamp are shown.
not implemented: until---(optional, not implemented yet) only resource instances last modified until this timestamp or before are shown. See Date/Time Format below. NOTE: this may not be fully implemented until versioning is done.
embedded---(boolean) - include URIs of Embedded Instances (see Concepts section above) in a report at the detail=identifier level.   Has no effect at detail=full.   This is usually not even a good idea, was included for troubleshooting.
detail=(identifier|full)---adjust level of detail.  Required.  This affects the way deleted items are represented in the results:

• When identifier is chosen, only the identifier of each resource is returned in the subject column, AND deleted subjects are indicated by prefixing the URI with a fixed URI prefix such as "info:deleted#deleted" to represent that the URI in the fragment is deleted.
• For full results, a deleted item is indicated with a synthetic statement: the predicate :isDeleted and a boolean true value.

...

Args:
format---the MIME type (and charset) of the input document's serialization format. This overrides any content-type on the content arg's entity.
type=(user|resource|transition|role|grant)---which type of data is to be imported, one MUST be chosen and there is no default. MUST match the type of the exported data.
content=stream..---the serialized RDF data to import, must have been generated by export of the same type of data.
transform=(yes|no)---Required, no default. When 'yes', URIs of imported instances are transformed into new, unique URIs resolvable by the importing repository. When 'no', URIs are left as they are.
duplicate=(abort|ignore|replace)---how to handle an import that would result in a duplicate object. Default is abort.
newgraph=(abort|create)---how to handle a resource instance import that would result in creating a new named graph for the data. Must be superuser to choose 'create'. Default is abort.
{{include=list.. }}---Explicit list of user or resource instances to include in the import. Format is a series of resource URIs separated by commas (",") and optional spaces. Users may also be referenced by username. IMPORTANT NOTE: The URIs in the include (and exclude) lists are matched against URIs in the imported source file, NOT the repository.
{{exclude=list.. }}---Explicit list of user or resource instances to exclude from the import. Mutually exclusive with include, format is the same. Useful for avoiding conflicts, for example, when loading a user export into a repository where the initial admin user already exists.
ignoreACL=(true|false)---Ignore all access control grants on imported objects. The imported objects will not have any specific access grants.

Send Contact

...

E-mail - /emailContact

This service has not been rigorously designed, so it does not have a specification of behavior. This section only documents how to call it, the internal actions it takes are still under discussion.

URL: /emailContact (POST method only)
Args:
uri=subject-URI---required
client_ip=IP addr---required
from_name=personal name---required
from_email=mailbox---required
{{subject=text
{{message=text
test_mode---default false, true if present.

Sends an email message to the designated contacts for the resource identified by URI. The exact rules for determining that contact address have not been formally specified yet. When a contact cannot be determienddetermined, the mail is sent to the configured postmaster for hte repothe repository. See the Admin Guide for details about configuring that and the rest of the email e-mail service.

Workflow Services REST API

Show Transitions

/repository/workflow/transitions

Method: GET or POST
Args:
workspace=URI---restirct restrict results to transitions applying to given workspace (includes wildcards). Default is to list all.
format=mime---type of result.

...

• Subject URI
• Label
• Description
• Workspace URI
• Workspace Label
• initial-state URI
• initial-state Label
• final-state URI
• final-state Label
• allowed - boolean literal, true if current user has permission on this transition

Show Resources

/repository/workflow/resources

Method: GET, POST
Args:
state=URI|all---workflow state by which to filter, or 'all' for wildcard.
type=URI--- include only instances of this tyep type (by inference counts) - default Default is no restriction.
unclaimed=(true|false)---when true, unclaimed resources are included in the report. Default is true.
owner=(self|all|none)---show, in addition to any selected unclaimed resources:

• self---those claimed by current user
• all---instances claimed by anyone
• none---includes no claimed resources.
  Default is self. Note that the combination unclaimed=false and owner=none is illegal.
workspace=URI---restirct restrict results to resources in a given workspace; optional, default is all avaialble available worksaces.
  format=mime---type of result, one of hte the SPARQL query formats.
  detail=(brief|full)---columns to include in results, see description below.
  addPattern=SPARQL-text---add this triple pattern to SPARQL query. May refer to variables as described below. Value is a literal hunk of triple pattern ready to be inserted into the patterns of a SELECT query. It may refer to the result variables mentioned below, e.g. ?r_type.
  addResults=query-variable..---add these variables to results columns. value is expected to be a space-separated series of query variables (which must appear in the triple pattern), e.g. "?lab ?labname"
  addModifiers=modifiers..---add a SPARQL modifiers clause to the query. Modifers include ORDER BY, LIMIT, and OFFSET and can be used to implement pagination.

...

• The brief level of detail includes columns:
  • r_subject - URI of resource instance
  • r_label - label of resource instance
  • r_type - URI of instance's asserted type
• The full level of detail adds the fields:
  • r_created - created date from provenance
  • r_owner - URI of workflow claimant if any
  • r_ownerLabel - the rdfs:label of r_owner if it is bound (and has a label)
  • r_state - URI of workflow state
• Any query variables you specified in the addResults list are added to either result.

Claim Resource Instance

/repository/workflow/claim

Method: POST
Args:
uri=URI---subject to claim
user=UserURI---optional, user who asserts the claim; default is authenticated user.

...

Release (claimed) Resource Instance

/repository/workflow/release

Method: POST
Args:
uri=URI---subject to release

...

Transition on Resource Instance

/repository/workflow/push

Method: POST
Args:
uri=URI---subject to transition
transition=URI---indicates transition to take

...

Method: POST
Args:
action= create | update | delete---(keyword)
uri=URI---required except for create, identifies the role
label= text---immediate label of role
comment= text---lenghty description of the role

Update Grants

/repository/admin/updateGrants

Method: POST
Args:
{{action{*}= {{ add | remove }}---(keyword)
uri = URI---subject of the access grant
access= {{URI }}---access type to be added or removed
agent = URI of person or Role in the grant

...

Method: POST
Args:
action= create | update | delete}}---(keyword)
uri = URI --required except for create, identifies the role  uri=URI--subject to release
{{label=text}}---required to create
comment=text (description)
{{ initial}}= URI of initial state (required to create)
final=URI of final state (required to create)
tAction=java class of transition action provider
tActionParameter* = text or URI param to pass to action method
order= sorting key, usually a decimal integer

...

• Interactive SPARQL query workbench (all auththenticated users).
• List Named Graphs with the option to edit their descriptive metadata and ACLs.
  • Note that new Named Graphs are only added with the /graph service.
• List, add, delete, and modify access Roles - edit the metadata of each Role.
• List, add, and modify User login accounts:
  • Display and change membership in roles.
  • Edit user metadata and change password.
  • Disable a user from logging in at all, or reinstate disabled user.
• List, add, delete, and modify Workflow Transitions.
• Report versions of Data Model Ontology: loaded, and available.
• Get a list of Published Resources. This is handy for troubleshooting (all users).

...