From CETISwiki
Belongs to LEAP 2.0
This is an introductory explanation of how LEAP triples work.
Please refer to the LEAP specification for a more exact view.
Basic RDF and triple concepts
LEAP triples are rooted in RDF, and there are many introductory guides to RDF that explain more fully the concepts given in brief outline here.
See the LEAP references.
RDF is best explained as simply a representation of a directed graph.
Thus, an e-portfolio, as represented in LEAP 2.0, is equivalent to a directed graph,
with records of things, bits of information, and the relationships between them.
This can be drawn as a diagram where each thing is an oval blob, each separate value is a rectangular blob,
and the arrows between them represent either the relationships between things,
or the properties of things, with separate values.
- The oval blob "things" that are relevant to us are described in the LEAP classes page.
- The relationships or properties that are relevant are given in the LEAP predicates page.
- The separate rectangular blob values can all be seen as data, which can have one of many data types.
For those who are unfamiliar with RDF, it is worth studying some of the referenced introductory material
for familiarization with typical RDF graph concepts and structures.
In essence, RDF represents each arrow in this diagram, which connects two blobs.
A "triple" is the threesome of the blob the arrow starts from, the arrow name, and the blob the arrow ends with.
In RDF terms, these are called the "subject", the "predicate" and the "object". So there is one triple for each arrow.
Different forms of triples in LEAP
Relating things within the collection of e-portfolio information
This is the most straightforward form of triple.
- The subject, as always, is a URL referring to something in the e-portfolio that is an instance of one of the LEAP classes.
- The predicate is taken from the list of LEAP predicates.
- The object is another URL referring to another thing belonging to the e-portfolio, in the same way as the subject.
Giving literal values to things
- The predicate is either taken from the list of LEAP predicates, or from another approved specification.
- The object is a string, directly giving the value of the property. The string may have a type - integer, date, etc.
- The object string may be in XHTML, which allows it to be richly structured. However, if appropriate, an object should be created in its own LEAP class, rather than having XHTML substituting for it. Where XHTML is used for a literal, its structure should be interpreted as layout for presentation, rather than significant in terms of LEAP classes and predicates.
Referring to another available resource
- The predicate is taken from the list of LEAP predicates.
- The object is the URL of an available resource.
In this case, the resource may play one of two roles
- It may be taken to substitute for a literal, as in the XHTML case above.
- It may be taken as a whole to be a relevant resource, as might a file packaged with the e-portfolio information.
The resource can, of course, be anything at all that has a URL,
but its meaning for the purposes of the e-portfolio should be taken to be just what is specified in the class and predicate definitions.
The URL may be a standard URL available throughout the web, or it may be one that is available to the portfolio reader in a different way.
- It may have restricted access which extents to the user or reader, but not the public.
- It may not be on the web at all, but instead, dereferenceable to a file packaged along with the rest of the portfolio information. How this is done will depend on the implementation.
Representation of predicates used in the LEAP classes
In the class pages, all the predicates are given which are logically applicable to the class in question.
There are more, possibly many more, than are required for most purposes, and it is the responsibility of
those who develop an XML "binding" to specify which ones are to be required.
In principle, e-portfolio systems should aim to be able to import as much information as they can,
regardless of how restricted the set of predicates they use for exporting information.
The list of relevant predicates is then given with symbols to indicate the type of triple.
- an "=" sign means the predicate can take a literal object, which may be XHTML or XML CDATA, or may be given by a URL for an available resource playing the part of a literal object.
- a → sign means the predicate can take an object which is an instance of a LEAP class, or where applicable, a friendly or associated resource.
- a ← sign means an inverse relationship, where one of the instance of a LEAP class in the portfolio information can be the subject with this predicate, with instances of the current class as object.
See also the LEAP references.
