Contents
|
This page will act as a focal point and index for an RDF approach equivalent to the LEAP2A specification. Initally this page will contain all relevant information, but the intention is soon to move the proposal, project, partners, and details to other pages, so that this page will give the summary vital information only -- a kind of quick reference guide with links to further information.
The ideas were initiated with a LEAP2R outline proposal, which discusses what work might be needed. There is also a page for people interested in LEAP2R.
If you are interested, please go ahead and code up some RDF in any dialect, or RDFa in something, and we can discuss together how much sense it makes, and whether there are alternatives.
The LEAP2A specification has been accepted as a reasonable approach to representing portfolio information, based on the Atom Syndication Format, for download and transfer between e-portfolio systems. Being based on Atom, it is relatively straightforward to implement, compared to other plausible specifications. But also, being tied to Atom, it cannot be extended to any other format, XML or otherwise. The idea of LEAP2R is to open this up completely, and allow the same information to be represented in any other XML, RDF, or Semantic Web format.
One of the most interesting and promising options for other formats is RDFa. The principle behind RDFa, as microformats, is principally to allow structured, machine-processable information to be contained within and alongside human readable HTML or XHTML data, using the same content wherever possible. There is much documentation on RDFa, and the reader is referred to this, as it will not be duplicated here. In practice, this means that a single HTML or XHTML document could, simultaneously, be offered both to people to read, and to e-portfolio systems to import from -- the systems could process the information provided in a standard way, and input it directly into their database. This would be especially valuable for portfolio presentations, but could also be used by a portfolio holder to store their complete portfolio information in a way which was easily and directly readable by them.
The ultimate intention is to have examples illustrating the whole process. We need to construct example RDFa web pages; then show the RDF extracted; then show how that can be imported into e-portfolio systems. If you have anything to do with developing e-portfolio systems, you may be able to help, for example, by
The same approach could in principle be used with any XML dialect, following the GRDDL concept. In all cases, this involves having a standard way of extracting RDF information from the HTML, XHTML or XML. This could prove very valuable in providing a bridge from other formats to the LEAP2 family.
To facilitate any of these processes, we need to define types or classes of portfolio information, and relationships or properties or predicates relating them, and give them all URIs. As LEAP2A was created with this in mind, this is not starting from scratch, but it still requires work. The outputs of this work are being assembled here, either on this page, or linked from this page. Please consider contributing, either directly, or by commenting.
The substantive item types or classes come from the types given in 2009-03/LEAP2A types. Other new classes are needed to represent necessary blank nodes.
| LEAP2A | Atom Threading RSS 1.0 | DCMI | RDF RDF Schema OWL Ref SKOS | FOAF | rfc2426 hCard vCard-XML (W3C note) | |||
|---|---|---|---|---|---|---|---|---|
| leaptype: | atom: thr: rss: | dcterms: | rdf: rdfs: owl: skos: | foaf: | vCard: | refines | notes | |
| substantive items | ||||||||
| ability | ability | #item | LEAP2A | |||||
| achievement | achievement | #item | LEAP2A | |||||
| activity | activity | #item | LEAP2A | |||||
| affiliation | #activity | new concept | ||||||
| agent | Agent | Agent | #item | generalisation | ||||
| meeting | meeting | #activity | LEAP2A | |||||
| organization | organization | Organization | ORG | #agent | LEAP2A | |||
| person | person | Person | #agent | LEAP2A | ||||
| plan | plan | #item | LEAP2A | |||||
| portfolio item | entry | atom:entry rss:item | LEAP2A | |||||
| resource | resource | BibliographicResource PhysicalResource | NOT rdfs:resource, which is broader | Document Image | #item | LEAP2A | ||
| selection | selection | #item | LEAP2A | |||||
| blank nodes | ||||||||
| address | see spatial | ADR LABEL | #location | LEAP requires | ||||
| addressline | see addressline | Street Locality Region | #valuenode | LEAP requires | ||||
| category | see categories | atom:category | Atom requires | |||||
| datenode | see date | #valuenode | LEAP requires | |||||
| idnode | see id; id | OnlineAccount | #valuenode | LEAP requires | ||||
| location | see spatial | Location | LEAP requires | |||||
| partnode | see Whole-part | LEAP requires | ||||||
| stage | see stage | #valuenode | LEAP requires | |||||
| valuenode | see label | LEAP requires |
The new node types required for RDF have these properties/relationships. All labels are text literals.
Just as in atom:category
Not implemented. Abstract class to allow for location information other than address: e.g. geo coordinates.
These are the enumerated types that are the values of certain properties. They can in principle be represented by text strings, URIs, or possibly other means.
| value type | LEAP2A | notes | ||||||
|---|---|---|---|---|---|---|---|---|
| gendertype | 0 (not known) | 1 (male) | 2 (female) | 9 (not specified) | see gender | From MIAP. FOAF uses literals. | ||
| pointtype | end | start | target | see point | ||||
| stagetype | planned | progressing | completed | see stage | ||||
| contenttype | text | html | xhtml | see content | from atom:content |
Table of predicates or properties or relationships.
This is based on the tables at 2009-03/LEAP2A predicates, 2009-03/LEAP2A_personal_data, 2009-03/LEAP2A_organizational_data and possibly LEAP predicates. LEAP2A personal data has a useful older cross-reference table including vCard.
vCard itself is somewhat unusual: as the microformats community spurn namespaces, hCard does not have a namespace; while the Jabber/XMPP community's vCard-XML does not assign a URI for its namespace. W3C does, however, assign a namespace URI to vCard, which is the one given.
NOTE this table is very much under construction! Feedback gratefully received.
Atom itself is not designed for RDF use -- indeed, to distinguish it from RSS, many writers abjure RDF for Atom altogether. The atom: namespace is not ideal for use directly as a prefix, as it does not end with # or /. And many Atom structures -- even basic ones like atom:content -- have attributes (type, in this case) that have to be worked around somehow. Obviously, there are several ways to work around this: you could have a blank content node, with a type as an object, or you could have three new predicates, one for text content, one for html content, and one for xhtml content.
In essence, to convert to RDF, we have to try to forget native Atom, and just represent what is in a LEAP2A feed, including the Atom, in a sensible way. The line which I personally favour at the moment is to introduce blank nodes wherever needed, to keep the correspondence with element names in LEAP2A reasonably close, so that we have to define as few more as feasible.
As vCard was not even designed in any way for RDF or the Semantic Web, it is not surprising that it is sometimes hard to distinguish what is a type and what is a property. On the whole, the solution here is to interpret structured properties as types. ADR and ORG are understood that way. N would be a type, but as an agent is taken as having just one name, it is not needed, and the name parts are direct properties of the agent. However, if multiple structured names were useful, we would adopt a name node equivalent to N.
Street, Locality and Region are given as "#addressline" type: the addressline is composed of the label equivalent to the substructure name, plus the value.
UID and CATEGORIES pose problems. UID is a property of an agent, while in LEAP2R an agent "#has account", where hopefully the service URL plus the identifier itself will be unique. To convert a vCard UID into a idnode, one would have to distinguish the service from the id with that service.
vCard CATEGORIES are simply a list of terms. They would be converted into a set of "#has category" relations to URIs or #category nodes.
Target triples are represented in this section as Turtle format. To get a valid Turtle file, you have to prefix the triples with the lines corresponding to any prefixes used:
@prefix portfolio: <http://www.example.ac.uk/interop/atom.aspx/> . @prefix leap: <http://wiki.cetis.ac.uk/2009-03/LEAP2A_predicates#> . @prefix leaptype: <http://wiki.cetis.ac.uk/2009-03/LEAP2A_types#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix categories: <http://wiki.cetis.ac.uk/2009-03/LEAP2A_categories/> . @prefix atom: <http://www.w3.org/2005/Atom> . @prefix xsd: <http://www.w3.org/2001/XMLSchema> .
This is a basic bare LEAP2A entry with no relationships.
portfolio:reflexion/1357 a leaptype:entry . portfolio:reflexion/1357 atom:updated "2009-03-15T14:33:12Z"^^xsd:dateTime . portfolio:reflexion/1357 atom:type "text" . portfolio:reflexion/1357 atom:content """this content can split over several lines without any problems.""" .
