Belongs to LEAP 2.0
1.1 A LEAP Portfolio is a collection of available information and resources with a mapping that maps it onto an RDF graph of triples (subject, predicate, object), together with available associated resources, that satisfies the conditions of this specification.
1.2 The RDF graph representation of the portfolio information serves as a supermodel of that information. This RDF supermodel is ideally, but not necessarily, equivalent or isomorphic to the information model of the original collection.
1.3 For the purposes of this specification, the part of LEAP portfolio information able to be represented by triples is grouped together as portfolio items which share the same subject, together with any dependent information.
1.4 An available portfolio item comprises a coherent set of triples that is available to the user or reader in the sense that they can be immediately retrieved, and where that set is recognisable as falling within the definition of one of the classes defined here.
1.5 Associated resources that do not conform to a class specified here must be made available, either packaged along with portfolio items, and with a local reference, or through an available URL that dereferences to give the resource.
2.1 Every triple subject must be a URL referring either to an available instance of a LEAP class in the hierarchy specified in Section 4 ("LEAP item"), or to an available instance of a class drawn from one of the specifications listed in Section 8 ("friendly item").
2.2 Every triple predicate (that is, property or relationship) must either be a LEAP predicate in the hierarchy as specified in Section 4 ("LEAP predicate"), or a predicate taken from the one of the specifications listed in Section 8 ("friendly predicate").
2.3 LEAP predicates may only be used with subject classes that are specified as being in their domain, or with descendant classes of those subject classes.
2.4 RDF specifies that every triple object must either be a URI or a literal. All LEAP triple objects must be URLs or literals - that is, what in RDF is a URI must be in LEAP a URL that is dereferenceable by the recipient or reader of the portfolio information.
2.5 An object URL must be a reference
2.6 An object literal may take the form of
2.7 Where a literal is expected, the URL of an available resource may be substituted, where the intention is for the resource to be interpreted as a literal. No rules are given in this specification for interpreting resources as literals.
2.8 Triples must also conform to any further constraints specified in connection with the subject or the predicate.
2.9 The use of LEAP predicates with instances of non-LEAP classes is not covered by this specification.
3.1 The original collection of portfolio information may be serialised in any form of XML, provided that it is properly associated with a public and freely available transform (e.g. XSLT), which, when applied to the XML, results in information in one of the allowed RDF formats, and where the resultant information conforms to the RDF supermodel as described in Section 2 above.
3.2 If an XML serialisation is used which includes information other than that covered by this specification, then the transform supplied should transform all the information into one of the allowed RDF formats, with the information not covered by this specification transformed to appear either with other predicates not covered by this specification, or other classes related in ways not covered here.
3.3 A specification of an XML serialisation intended for general e-portfolio use should include structures representing the basic classes and predicates, either directly mapping to them, or through a specified subclass or subpredicate standing in for the basic classes or predicates that are not mapped directly.
3.4 The prototype XML serialisation developed in the Portfolio interoperability projects, using the Atom Syndication Format, is called Leap2A.
4.1 LEAP classes and predicates have their own specifications. Their locations are given in Section 6.
4.2 Certain noted LEAP classes, and certain noted LEAP predicates, are specified as basic to this specification.
4.3 Each class (other than the ones specified as basic) must have a basic class as ancestor, and specify a superclass which is either a basic class or itself has a basic class as ancestor. A subclass is a specialization of a superclass by inheritance, and inherits all the properties of its superclass (i.e., strict inheritance) in addition to having zero or more additional properties of its own.
4.4 Each predicate, other than the ones specified as basic, must have a basic predicate as ancestor, and specify a superpredicate which is either a basic predicate or itself has a basic predicate as ancestor. A subpredicate is a specialization of a superpredicate by inheritance. Valid triples with a given predicate are also valid triples if the predicate is replaced by an ancestor predicate which accepts the same range. However, some ancestor predicates have text literal ranges, where descendant predicates have class ranges: in these cases, to have a valid triple, a conversion from structure to text is needed to result in a valid triple. The semantics are not altered, but the method of representation may be, and text literals are generally less machine processable than instances of classes.
4.5 Systems should accept instances of classes that represent information that is meaningful within their system and practice. To accept a class means being able to process some properties and relationships associated with that class more specifically than is done or would be appropriate for an ancestor class.
4.6 The specification for each non-basic class should include advisory rules for the interpretation that class in systems which do not recognise it, but only recognise its superclass. These rules must be able to be composed, with the result that any class can be reasonably interpreted as an instance of any ancestor classes.
5.1 Implementors of the specification are free to extend the specification by refining further subclasses and subproperties, provided that their definition is publicly available and conforms to the class and predicate hierarchy structure specification above.
6.1 All the specified LEAP classes are given at the LEAP classes page. The ones that are basic are noted there. Follow the links there to find a more detailed specification for each class, with extra information.
6.2 All the specified LEAP predicates are given on the LEAP predicates page. The specification is given on the one page: there are no separate pages for individual LEAP predicates.
(examples of portfolio information in these formats to be supplied)
(to be decided)
LDAP? vCard?
