OER-world-map
Use case submitted by Adrian Pohl (hbz).
This case study in the RDF validation database: http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=node/416.
The hbz has built a prototype for an Open Educational Resources (OER) world map, see the project report. The data of the OER map prototype covers descriptions of organizations, persons, services and projects. In this context efforts were made to develop a formal description of the application profile in RDF.
For the OER world map a read/write API was developed as well as an application (Drupal) for viewing, adding, deleting and editing the data. (See the image of the architecture.)
Both API and application need some specifications which we would like to express in an RDF application profile. While the API mainly needs information for validating incoming data, the application also needs information about presenting the data (result lists, single results, forms for editing the different resources). Below is a list of the specifications needed.
Note: The following overview heavily uses terms from RDF Schema and OWL, but does this somehow metaphorically as an application profile is 'not' an ontology or vocabulary. To make this clear, here an overview over the differences between ontologies/vocabs and application profiles.
- An ontology has a global scope, i.e. it applies to any use of the defined properties and classes. The scope of an application profile is limited to an application or a community.
- An AP mixes different vocabs while a single vocabulary mainly defines terms in one namespace (and may import terms from other ontologies).
- Ontologies are created for reasoning/inferencing purposes, whereas APs are created for purposes of validation and/or data presentation.
Validation (API)
- Classes: What types of resources (rdf:type) can be submitted? - Answer: schema:Organization, schema:Person, schema:Service, foaf:Project
- Properties: What properties can be used?
- Domain: On which types can the properties be used?
- Range: What values are expected on the different properties? (Instances of which classes on object properties, what kind of data types or regex pattern on datatype properties, terms/concepts from what controlled vocabulary/concept scheme?)
- Cardinality: What is the cardinality of the different properties (which properties are obligatory, optional, repeatable)?
- ...?...
Viewing and editing (application)
- Validation: The application needs the above specifications for validating form input.
- Labels: What labels should be used for the different RDF properties?
- Order: What properties need to be shown on the different types in different contexts (result list, single result, web form etc.)?
- Displaying links: How should links to other resources be displayed (e.g. label + underlying link to the resource)?
- ...?...
Draft RDF application profile & requirements for an RDF AP
See http://git.io/LD_H9w for the current application profile that is already used to generate the Drupal forms. For the start, we implemented an OWL-based AP, quite similar to this approach and added information not covered by this approach with properties from the http://example.org/ namespace. Though we specified information needed both for the validation and the presentation of data, we realized one would better seperate these aspects in two different documents. Thus, people only interested in validating data wouldn't be bothered with all the additional information that is provided for presentation purposed. Also, different applications built on the same data provided by an API would each need a different AP.
Here is a list of all the functions an AP should fulfill (distinguished by genereal requirements and requirements for presentation and validation) and how we addressed the needs in the draft AP (if we did at all).
Note: As we had this prototype to get going quickly, we didn't immerse ourselves in long discussions about the best way to go but relied heavily on workarounds that we would not implement in a production system.
Prefixes
The examples below are written in Turtle and the following prefixes are used:
@prefix : <#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix dct: <http://purl.org/dc/terms/> . @prefix ex: <http://example.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix marcrel: <http://id.loc.gov/vocabulary/relators/> . @prefix oo: <http://purl.org/openorg/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix schema: <http://schema.org/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix gn: <http://www.geonames.org/ontology#> .
General requirements for an AP
Stating the document's type ("application profile")
Currently, no RDF type for application profiles exists. That's why we used the class ex:ApplicationProfile like this:
@prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix ex: <http://example.org/> . :ap a owl:Ontology , ex:ApplicationProfile .
Providing information about the AP as a whole
E.g.:
;
dct:created "2014-02-24" ;
dc:rights "This application profile is available under the Creative Commons Public Domain Dedication (CC0)" ;
dct:rights <http://creativecommons.org/publicdomain/zero/1.0/> .
Provide human-readable description of property/class usage
We used rdfs:comment for this. Example:
:description
rdfs:comment "In the context of this application profile the property schema:description is used to give a description of a person, organization, project, or service."@en .
Requirements for validation
Identify an element/class and its relation to AP, indicate the refined property/class
A first approach was to use the OAI ORE proxy construct to identify a property/class and its relation to the property/class it refines as well as its relation to the AP. We then switched to only using OWL (see this commit) with document-relative IDs for the properties and rdfs:subPropertyOf to state their relationship to the refined property and rdfs:isDefinedBy to state the relationship to the AP. Example (in turtle):
:description
a rdf:Property ;
rdfs:subPropertyOf schema:description ;
rdfs:isDefinedBy :ap .
:Person
a owl:Class ;
rdfs:isDefinedBy :ap ;
rdfs:subClassOf schema:Person .
Define object restrictions for properties
One important function of an AP is to define what kind of object should be used with a specific property within an application: another resource (URI) (if yes, of which type) or a literal value (if yes, with what kind of restrictions). We used the combination of property type (owl:ObjectProperty, owl:DatatypeProperty) with rdfs:range for this. Examples:
:description
a owl:DatatypeProperty ;
rdfs:range rdf:HTML .
:logo
a owl:ObjectProperty ;
rdfs:range foaf:Image .
:email
a owl:DatatypeProperty ;
rdfs:comment "In the context of this application profile the property schema:email is used to indicate the email address of a person, organization, project, or service. The literal should conform to this regular expression: [A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}"@en ;
rdfs:subPropertyOf schema:email ;
rdfs:isDefinedBy :ap ;
rdfs:range [
a rdfs:Datatype ;
owl:onDatatype xsd:string ;
owl:withRestrictions (
[
xsd:pattern "[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}"
]
)
] .
:startDate
a owl:DatatypeProperty ;
rdfs:comment "In the context of this application profile the property schema:startDate is used to indicate the start date of a project using the xsd:gYearMonth datatype."@en ;
rdfs:subPropertyOf schema:startDate ;
rdfs:isDefinedBy :ap ;
rdfs:label "Start date"@en ;
rdfs:label "Beginn"@de ;
rdfs:range xsd:gYearMonth .
For some use cases (e.g. restricting range to members of specific controlled vocabulary) it would make sense to indicate a namespace allowed resource URIs should be from. We didn't need such a function in this prototypem though.
Define cardinality restrictions for properties
Cardinality restrictions are usually bound to the use of a property on an instance of a specified class. As frequently done, we used owl:Restriction for this. E.g. to say that a person should exactly have one name:
:Person
a owl:Class ;
rdfs:isDefinedBy :ap ;
rdfs:subClassOf schema:Person ,
[ a owl:Restriction ;
owl:onProperty :name ;
owl:cardinality "1" ] .
Or, e.g., to say that an organisation can have a memberOf relation:
:Organization
rdfs:subClassOf schema:Organization ,
[ a owl:Restriction ;
owl:onProperty :memberOf ;
owl:minCardinality "0" ] .
(X)OR rules
At one point we would have liked to indicate cardinality relations between two elements like: a :PostalAddress has at least one :postOfficeBoxNumber statement OR at least one :streetAddress statement (actually, we had more an XOR rule in mind). We moved away from implementing this in the prototype as we couldn't think of an easy to implement workaround.
Requirements for building a web application
These include requirements for presenting the data as HTML/RDFa and generating a web form for creating/editing/linking the data.
Define types of resources to generate web forms for
The question here is how to indicate to an application how many different web forms for which different types of resources should be generated. We solved this by defining the range of the rdf:type property:
:type
a owl:ObjectProperty ;
rdfs:comment "In the context of this application profile the property rdf:type is used to indicate the type of a resource (person, organization, project, or service)."@en ;
rdfs:subPropertyOf rdf:type ;
rdfs:isDefinedBy :ap ;
rdfs:label "Type"@en ;
rdfs:label "Typ"@de ;
rdfs:range [
a owl:Class ;
owl:oneOf ( :Organization :Service :Person :Project )
The problem with this approach is that it also forbids to provide other (more specific) type information which we sometimes would have liked to add.
Define labels for presentation of properties on webpages/web forms
We used rdfs:label with language tags for this. We applied this in two ways. If the same label is used for one property across the whole application we used it on the property, e.g.:
:description
rdfs:label "Description"@en ;
rdfs:label "Beschreibung"@de .
If one property was used in the context of different types of resources with different labels, we used a workaround, applying rdfs:label on the class restriction, e.g.:
:Person
a owl:Class ;
rdfs:isDefinedBy :ap ;
rdfs:subClassOf schema:Person ,
[ a owl:Restriction ;
owl:onProperty :alternateName ;
rdfs:label "Nick name"@en ;
owl:minCardinality "0" ] .
Define order of properties for presentation/web form
The order should be adaptable seperately for each resource type. We didn't use a RDF-solution for this but just took the sequence as enumerated for each resource type in the Turtle document. (This, obviuously, couldn't workm if somebody transformed the AP to N-Triples or something else before implementation.) Example:
:Service
a owl:Class ;
rdfs:isDefinedBy :ap ;
ex:labelProperties ( :name ) ;
rdfs:subClassOf schema:Service ,
[ a owl:Restriction ;
owl:onProperty :name ;
owl:cardinality "1" ] ,
[ a owl:Restriction ;
owl:onProperty :alternateName ;
owl:minCardinality "0" ] ,
[ a owl:Restriction ;
owl:onProperty :description ;
owl:minCardinality "1" ] ,
[ a owl:Restriction ;
owl:onProperty :url ;
owl:minCardinality "0" ] .
--> This was inteprreted as the sequence of properties :name, :alternateName, :description, :url.
Differentiate between text boxes and small input fields
For the input form, one has to distinguish between small input fields (e.g. for name, phone number etc.) and larger text boxes (e.g. for description). We did this in the prorotype by applying different rdfs:range restrictions: rdfs:Literal for small input fields and rdf:HTML for bigger ones, e.g.:
:description
a owl:DatatypeProperty ;
rdfs:range rdf:HTML .
:name
a owl:DatatypeProperty ;
rdfs:range rdfs:Literal .
Define API endpoints to be queried in the web form for interlinking
A web form for creating linked data should include the possibility to query for resources to link to. These resources may reside within the same application or within third-party data sets. In our case both the lobid OER API as well as the GeoNames API are queried for interlinking. We created draft properties for this that met our specific requirements.
<http://api.geonames.org/search>
a ex:endpoint ;
ex:queryParam "q" ;
ex:offsetParam "startRow" ;
ex:limitParam "maxRows" ;
ex:additionalParam "username=literarymachine" , "type=rdf";
ex:resultFormat "application/rdf+xml" ;
ex:supplies :Locality , :Country .
<http://api.lobid.org/oer>
a ex:endpoint ;
ex:queryParam "q" ;
ex:typeParam "t" ;
ex:offsetParam "from" ;
ex:limitParam "size" ;
ex:resultFormat "application/rdf+xml" ;
ex:supplies :Organization , :Service , :Person , :Project .
Define values to be shown for a linked resource
If I present linked data in HTML I might not want to show the URI of a linked resource but the values of specific properties instead, e.g. show a name of an organisation rather than its URI. We indicated the properties to be shown with ex:labelProperties like this:
:Person
a owl:Class ;
rdfs:isDefinedBy :ap ;
ex:labelProperties ( :name ) .
:PostalAddress
a owl:Class ;
rdfs:isDefinedBy :ap ;
ex:labelProperties ( :streetAddress :postalCode ) ;