2R

From Leapspecs Wiki

Jump to: navigation, search

Contents

Leap2R: guidelines for using RDF to represent Leap2 information

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 Leap2R/people interested.

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.

What is the idea of Leap2R?

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

  • proposing example material to format in RDFa with Leap2R
  • exploring RDFa Leap2R export and import, and feeding back from your experience to guide developer-friendly decisions for Leap2R
  • planning the implementation of Leap2R export and import.

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.

Types

The substantive item types or classes come from the types given in 2A/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)
leap2: 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 affiliation #activity new concept now in Leap2A
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
publication publication BibliographicResource Document #resource 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

Specification of new required node types

The new node types required for RDF have these properties/relationships. All labels are text literals.

address

addressline

  • #value → text literal
  • #label → indicating type of address component

category

Just as in atom:category

datenode

idnode

location

Not implemented. Abstract class to allow for location information other than address: e.g. geo coordinates.

partnode

stage

valuenode

  • #value → any literal, including text, URI, vocabulary terms
  • #label → label with more meaning in context for user

Vocabularies

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

Predicates

Table of predicates or properties or relationships.

This is based on the tables at Leap2A/predicates, Leap2A/personal_data, Leap2A/organizational_data and possibly LEAP 2.0 predicates. Leap2A/personal data also 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.

Need to fill in the column for iCal etc..

specification Leap2A Atom
Threading
RSS 1.0 		DCMI RDF
RDF Schema
OWL Ref
SKOS 		FOAF rfc2426
hCard
vCard-XML
(W3C note) 		iCalendar hCalendar (vCalendar) rdfcal
meaning domain range refines leap2: atom:
thr:
rss: 		dcterms: rdf:
rdfs:
owl:
skos: 		foaf: vCard: notes
active time spent #item ISO 8601 activetime
alternate representation #item URL (see alternate) atom:alternate
attended by #activity #person attended by
attends #person #activity attends
author #item #agent (see author) atom:author creator
content #item text, html
xhtml 		content atom:content description rdfs:comment
content type #item #contenttype
rfc4288 		(see content) atom:type
contributor #item #agent (see contributor) atom:contributor contributor
country #address
#agent 		text country Country
countrycode #address
#agent 		ISO 3166 countrycode
date of birth #person W3C DTF dob birthday bday FOAF has no year
date #item #datenode date
display order #partnode integer display order
field identifies predicate
e-mail #agent rfc5322 email atom:email mbox email
gender #person #gendertype gender
has account #agent #idnode (see id; id) holdsAccount
has agenda #item #item has agenda
has as reply #item #item has reply thr:replies
has category #item URI
#category 		(see categories) atom:category (categories)
has evidence #item #item has evidence
has line #address #addressline (see addressline)
has outcome #item #item has outcome
has part #item #item
#partnode 		has part hasPart
has part object #partnode #item
has photo #item #resource depiction
img 		photo
in reply to #item #item in reply to thr:in-reply-to
is agenda of #item #item is agenda of
is evidence of #item #item is evidence of
is outcome of #item #item is outcome of
is part of #item #item
#partnode 		is part of isPartOf
is part of object #partnode #item
is photo of #resource #item depicts
label #category
#valuenode 		text label atom:label rdfs:label
skos:prefLabel
name given legal #person text legal_given_name firstName
givenname 		Given
Other
name given preferred #person text preferred_given_name firstName
givenname 		Given
NICKNAME
name family first #person boolean family_name_first
name family legal #person text legal_family_name family_name
surname 		Family
name family preferred #person text preferred_family_name family_name
surname 		Family
name full #person text full_name atom:name name fn
name org legal #organization text legal_org_name Orgname
Orgunit
name org preferred #organization text preferred_org_name Orgname
Orgunit
name prefix #person text name_prefix title Prefix
name suffix #person text name_suffix Suffix
open id #agent text openid openid
orgdata do not use
persondata do not use
point #datenode #pointtype point
postcode #address text postcode Pcode
published #item rfc3339 published atom:published issued
created
reflected on by #item #item reflected on by
reflects on #item #item reflects on
related #item #item relation atom:related relation rdfs:seeAlso agent
rights #item text (see rights) atom:rights rights
holder's role #item text myrole role
contextual id #item text roleid
scheme #category URI atom:scheme
service #idnode URL; text service account...page
spatial #item #location spatial spatial based_near geo
status #item #stage status
summary of content #item text summary atom:summary
rss:description 		abstract
supported by #item #item supported by fundedBy
supports #item #item supports
telephone #agent rfc3966
(URI) 		homephone
workphone
etc. etc. 		phone tel This use of rfc3966 (idea from FOAF, though their documentation is outdated) is suggested as a step forward from Leap2A. The type of phone should be given by the context.
term #category text atom:term
title #item html title atom:title
rss:title 		title
type #item URI rdf:type
updated #item rfc3339 updated atom:updated
value #valuenode any literal rdf:value
web page #agent URL website
website 		page
homepage 		URL
when added #partnode rfc3339 when added

Specification notes

Atom

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.

vCard

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.

Guiding principles for the specification

  • Leap2R is not to have a namespace of its own, but to use other namespaces, including the "leap2:" namespace from Leap2A.
  • Leap2R is by nature a permissive specification. A set of information, or document, whose content is entirely covered by the documentation can be described as "Just Leap2R".

Leap2A constructs and their representation in RDF

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 leap2: <http://terms.leapspecs.org/> .
  @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
  @prefix categories: <http://wiki.leapspecs.org/2A/categories/> (or something else).
  @prefix atom: <http://www.w3.org/2005/Atom> .
  @prefix xsd: <http://www.w3.org/2001/XMLSchema> .

Leap2A/entry

This is a basic bare Leap2A entry with no relationships.

Example target triples 

 portfolio:reflexion/1357 a leap2: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.""" .

RDF diagram

To do

  • Consider making participation / creation explicit, by having explicit relationships between the portfolio holder and the recorded items.
  • Add agent to Leap2A development track.
  • When getting on to recommending RDFa practice, check bookmarks from recent discussions particularly about CURIEs and alternatives.

References

Retrieved from "http://wiki.leapspecs.org/2R"
Personal tools