Introduction

structXML is a straightforward RDF serialization in XML format used for internal communications between structWSF Web services, the Semantic Components and conStruct; this is the core format used to transmit information between any OSF component. In structWSF, any data is internally processed as structXML, and is then converted into several other formats (RDF+XML, RDF+N3, irJSON, commON, etc.). It is composed of subjects (records) that are defined with properties and values. Values can be "data" values such as literals or "object" values that are reference to other subjects.

A simple schema is used to describe these resultsets and their major elements that comprise the XML data structure. The API and DTD documentation for each Web service provides sample results fragments that help illustrate this structure.

Specification

A number of major elements comprise the XML data structure. The API and DTD documentation for each Web service provides sample results fragments that help illustrate this structure.

<resultset />

The goal of any Web service is to return results. The root element of any structWSF Web service is the element where all results in a given results document are nested.

<subject />

Any query to a Web service refers to a "subject" (consistent with the understanding of subject within the standard subject-predicate-object RDF triple). This subject can be a resource referred to by its ID, it can be one or multiple keywords of a search string, it can be text of one thousand words to be analyzed, or other options.

A resultset is composed of one or multiple subject(s) depending on the Web service. This means that the subject element represents the subject of a query to a Web service endpoint.

A subject has a type and a URI. The type of a subject can be seen as its kind. The URI of a subject is its unique identifier.

<predicate />

Any Web service takes the subject of a query and processes it according to the procedures set by other input parameters to the query. The result of this processing is to relate a subject to other things (objects; see below) using different predicates. Any subject has zero, one or multiple predicate(s) relationships with other objects.

Every predicate has a type. The type of a predicate can be seen as the kind of relationship between two things (a subject and an object).

<object />

Any predicate refers to one or multiple objects. An object is a thing such as a subject with a type and an optional URI. An object could be the subject of another query.

Subject and object are the same in that both refer to a "thing" (or collections of things, in which case they are a class). The only difference between the two elements is the way in which they are referenced by a predicate, as either a subject or an object.

An object has a type and a URI. The type of an object can be seen as its kind. The URI of an object is its unique identifier. It is optional if the object reference is a literal, such as a string name or a number.

A special kind of object exists: rdfs:Literal. The characteristics of this kind of object will be discussed in a special section below.

<reify />

Sometimes it is useful to be able to assert facts about a given triple statement <subject, predicate, object>.

The example below means: we have a subject that is a bibo:Document. This document has a predicate relationship umbel:isAbout with the thing, that itself is a umbel:SubjectConcept, referred as http://.../War. Basically, this triple relationship means: "I have a document that is about War".

However we can also assert a certain ratio that shows the confidence level in asserting that statement. By using the umbel:withLikelihood reification property, we can assign a confidence level regarding the "fact" (assertion) of the initial triple statement, as follows: <bibo:Document, umbel:isAbout, umbel:SubjectConcept>, umbel:withLikelihood, "0. 87345872835434">.

This reification gets expressed in the XML data structure as:

So, basically, the reify element helps us to assert a fact about another fact (triple statement).

Data consumers should thus parse the XML document in this following way:

If there is a <reify /> element within the body of a <object /> element, the data consumer must check the three parent nodes of the <reify /> element to compose the assertion fact about <subject, predicate, object> comprising the three nodes of the triple.

Unique Identifiers: URIs

Nearly all resources subject, predicate or object has a unique identifier called aURI. (Subjects and predicates must have a URI; objects most frequently do, but sometimes may optionally be assigned a literal.)

These URIs are unique to each resource. Since these IDs are unique, if a Web service A refers to a resource X and another Web service B also refers to a resource X, then both Web services A and B refers to the same thing. This understanding must hold true for the reason that atomic Web services can easily interact together to create compound Web services.

However, sometimes, the subjects or the objects of a resultset may not have a defined URI (the attribute). If such a case happens, the consumer of this Web service data must itself define a unique identifier for that thing.

Literals

A literal is a special kind of object. Unlike any other object, a literal object can not be a subject of a predicate. (Technically, a resource could describe a literal, but the literal itself can't be described; but this fact is out of the scope of this document). An example of a resource that describes a literal is the bibo:Document use case described above.

A literal object may not also have a URI attribute.

Flexibility of this XML Data Structure

This XML data structure is thus flexible enough to describe any relation within an RDF graph produced by a structWSF Web service.

The advantage of re-using the triple assertions of the RDF data model with types and URIs is that a data consumer can easily handle the data produced by any Web service, even without knowing the type of the subjects, predicates and objects returned by that Web service. The data consumer can always say: I have this thing that refers to this other thing with this given predicate. The data consumer can manipulate results in some ways even if it doesn't know much or anything about the types of those things.

This consistent abstraction is helpful since even if the Web services evolve and change over time, the data consumers of these Web services will be able to handle the things it knows, and only discard the new types that have been added that it may not know, all without having to change anything in the procedures that manage the resultsets returned by these Web services.

DTDs

Each Web service has its own DTD. These DTDs have been created to help data consumers validate the outputs of these Web services. It is also useful to let data consumers know what they should expect from a given Web service.

The full listing of the DTD for an existing Web service is linked to on its Web service API documentation page.