 | This page is a work in Progress and its content are subject to change. It is recommended to check back regulary.
|
1. Introduction
The Enhanced Publications Data model enables people and software applications to create Enhanced Publications. An enhanced publication is an RDF file pointing to all suplementary material and information surrounding a publication. Building Enhanced Publications in the same way enables searchengines to crosslink to publications and supplementary material beyond one Enhanced Publication. This allows one to browse through academic work, see connections that couldn't be seen before, discovering more idea's, leveraging greater exposure for the work one has put in research material, and revealing the harmony of science.
The Enhanced Publication Data model builds on exisiting semantic web technologies to richly represent an Enhanced Publication. The Enhanced Publication Data model builds on these technologies and gives developers one thing to implement. Developer simplicity is a key goal of the Enhanced Publication Datamodel which has informed many of the technical design decisions (DRIVER-II ORE Information Model).
First one describes the Resource Map RDF-file itself which contains the information of the Enhanced Publication. Then one describes the Enhanced Publication. Then one describes all the entities (eprint, dataset, person, etc.) containing the Enhanced Publication. And optionally one can additionally describe all the other relations (citedby, made, worksat, etc. ) the entities have within the Enhanced Publication. Below a simple manual is given how it is done.
The example follows the example of an Enhanced Publication consisting of an Eprint and a Dataset. Both documents have additional Metadata produced by a publishing repository. The Enhanced Publication and Eprint are created by he same person and the Dataset by another person.
Creating an Enhanced Publication follows different stages. The presentation below will show you the different stages. The Enhanced Publication follows the LinkedData principles to be globally interoperable with the rest of the world.
This datamodel of Enhanced Publications describes the minimal information needed for representation in other services like NARCIS, the Dutch Research Portal. More information about the exchange protocols of Enhanced Publications can be found in the section Discovery and Transport.
|
Enhanced publication
View more presentations from maurice.vanderfeesten |
Linked Data principles
by Tim Berners-Lee Source: http://www.w3.org/DesignIssues/LinkedData.html |
Document information
Document History
Date |
Version |
Owner |
Changelog |
|
|---|---|---|---|---|
14 March 2011 |
0.9 |
EPxchange working group |
changes added from the meeting at 2011-03-11 |
PDF What's new
This log describes changes on the 0.9 datamodel that has implications for installed instances.
Date |
wiki version |
Changed by |
Change description |
|---|---|---|---|
14 March 2011 |
EPxchange working group |
Initial 0.9 version |
2. Enhanced Publications in OAI-ORE
OAI-ORE in a nutshellObject Reuse and Exchange is a standard from Open Archives Initiative for the description and exchange of webresources. OAI-ORE differentiates between three different concepts: An ReMs are retrieved using deferencing, either via Cool URIs with or without (RECOMMENDED in this scenario where only the RDF/XML representation is used) content negotiation or using Hash URIs for identifiers of the It is strongly recommended to read the ORE primer to have a basic understanding of ORE. Enhanced Publications as ORE aggregationsAn Enhanced Publication can be realised as an ORE |
|
3. Creating a Resource Map in RDF/XML
RDF/XML in a nutshell
Resource Description Framework is a generic metadata data model. It is centred around the concept of so-called triples consisting out of a subject, predicate and object.
Subject |
Predicate |
Object |
|---|---|---|
dcterms:hasPart |
||
dcterms:title |
"A Booktitle" |
|
dcterms:creator |
John Doe |
RDF can be expressed using different serialisation, such as N3, Turtle and XML. ORE uses the XML variant.
Basic RDF/XML structure
An RDF/XML document starts with a root-element RDF. This then contains Description which contain the triples. The Subject is defined in the about attribute of the Description element. The subelements of a Description then contains the Predicate and Object. The object may either be a URI, a literal or a blank node. In the following example, the chapter is refenced by a URI, the title as a literal and the author as a blank node in FOAF.
The example in the table above is serialised as follows:
Spelling variations in RDF/XML
Within RDF/XML, the possibilties to describe something are virtually endless. For example when we want to describe that John Doe is the author of a book, as a blank node using the Friend of a Friend ontology, we can describe this using an in-line blank node as subelement of dcterms:creator:
Example 1
..., or by taking out the foaf:Person element of the dcterms:creator element and linking the two by using the identifier "a1" in the rdf:nodeID attribute:
Example 2
..., using the same approach with the separate foaf:Person outside the dcterms:creator, but this time linking the two rdf:about and rdf:resource attributes with the local identifier as a URI written as "_:a1":
Example 3
..., or by using the generic rdf:Description construct with an rdf:type element referencing the URI of the foaf:Person type:
Example 4
This last example can of course also be serialised using the rdf:nodeID attribute.
For clarity and consistency in the examples we will use the style presented in example 4 in the examples presented below. However, it should be noted that all four examples shown above are perfectly valid RDF/XML excerpts describing the exact same thing.
For details on the RDF/XML implementation of OAI-ORE, see Resource Map Implementation in RDF/XML of the ORE Specification and User Guide.
Please refer to the RDF/XML syntax specification for more details on RDF/XML.
Ontologies and their Namespaces
Core Ontologies
The following namespaces are used in this document
Prefix |
Namespace URI |
Description |
Application |
|---|---|---|---|
|
Dublin Core terms |
To describe bibliographic entities and make relations |
|
|
Friend of a Friend |
To describe person and organization entities |
|
|
Digital Author Identifier |
To describe the digitial identifier of the author |
|
|
info:eu-repo Controlled Vocabulary for Repositories in the EU context |
A vocabulary to give bibliographic entities a semantic type |
|
|
Web Description Resources (Powder-S) |
To describe relations between a resource and an entity that describes the resource |
|
|
ORE vocabulary terms |
To describe the aggregation |
|
|
RDF vocabulary terms |
To describe relations |
Community ontologies
| work in progress |
The following ontologies are not used in this document, but are possible
Prefix |
Namespace URI |
Description |
Application |
|---|---|---|---|
|
|
Discourse Relationships |
To describe the scientific relations between bibliographic entities in the Escape Editor for enhanced publications (http://escape.utwente.nl) |
|
Research Project Ontology |
specifying FOAF:Project to Research Projects |
|
|
Relation Annotation Ontology |
adding more information to a relation between entities |
|
|
Agents Ontology |
specifying FOAF:organisation in University, Research Group, etc. |
|
|
ESCAPE system ontology |
Defining system critical entities in order for ESCAPE application to work |
|
|
Publication Types Objects |
Defining Publication types used in the info:eu-repo namespace |
|
|
|
|
|
 | In this blog entry from PeteJ you can read all about how to Discover Approprate Vocabularies Or look at these overviews: |
Basic layout of a Resource Map
A ReM contains basically consists of three blocks:
- a
Descriptionelement defining the Resource Map itself. - a
Descriptionelement defining the Aggregation the ReM is describing. - one or more
Descriptionelements describing resources referenced by the Aggregation.
RDF Example for Resource Map
4. Bibliographic Entities
|
element |
Cardinality |
Enhanced |
Eprint |
Data Object |
Metadata Record |
Description |
|---|---|---|---|---|---|---|---|
Resource Identifier |
|
1..1 |
M |
M |
M |
M |
The location of the resource. This MUST be a HTTP-based URI. |
Persistent Identifier |
|
0..n |
R |
R |
R |
R |
The persistent identifier of the resource, e.g. NBN, DOI or Handle. |
Is Described By1 |
|
1..1 |
M |
n/a |
n/a |
n/a |
The location of the RDF/XML Resource Map of the Enhanced Publication. This MUST be a HTTP-based URI. |
Aggregates1 |
|
1..n |
M |
n/a |
n/a |
n/a |
The locations of the resources in the Enhanced Publication. This MUST be HTTP-based URI's. |
Semantic Type |
|
1..n |
M |
M |
M |
M |
The semantic type of the resource using a ontology, e.g. |
Author2 |
|
0..n |
M |
M |
M |
M |
The author of the resource using |
Publisher2 |
|
0..1 |
M |
M |
M |
M |
The publisher of the resource using |
Title |
|
0..1 |
R |
R |
R |
R |
The title of the resource. |
Description |
|
0..1 |
R |
R |
R |
R |
A description of the resource. |
Format |
|
0..1 |
n/a |
R |
R |
R |
The format as IANA Media Type |
Issued |
|
0..1 |
M |
M |
M |
R |
Date Issued: The Complete Date as described by http://www.w3.org/TR/NOTE-datetime |
LastModified |
|
0..1 |
R |
R |
R |
R |
Date Last Modified: The Complete Date as described by http://www.w3.org/TR/NOTE-datetime |
Conforms To |
|
0..1 |
n/a |
n/a |
n/a |
R |
metadata namespace - Provides information about the XML schema used for detailed metadata, using |
References |
|
0..n |
O |
O |
O |
O |
Relates from one bibliographic entity to another, using |
Described By |
|
0..n |
O |
O |
O |
O |
Detailed description in Metadata Record and/or human readable landing page, using |
M=Mandatory
1=Only applies on the current Enhanced Publication being subject. This does not apply for describing a nested Enhanced Publication.
2=Either Author or Publisher is mandatory
R=Recommended
O=optional
n/a=not applicable
4.1 Enhanced Publication
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Is Described By |
|
Aggregates |
|
Semantic Type |
|
Author |
|
Publisher |
Organisation XYZ |
Title |
"Example Enhanced Publication" |
Description |
"This is an example RDF entity to illustrate the structure of an Enhanced Publication." |
Format |
n/a |
Issued |
"2011-01-11" |
LastModified |
"2011-03-12" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example in RDF/XML
RDF example for Enhanced Publication
4.2 Eprint
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
Jan Jansen |
Publisher |
Publisher XYZ |
Title |
"A digital textual publication" |
Description |
"Some example text that describes the resource." |
Format |
" |
Issued |
"2010-02-12" |
LastModified |
"2011-01-02" |
References (relates to another entity) |
|
Described By (detailed description in Metadata Record ) |
|
Described By (human readable description on repository landing page ) |
| For all semantic types for a publication see http://wiki.surffoundation.nl/display/standards/info-eu-repo#info-eu-repo-Publicationtypes |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
|
|
|
||
|
||
|
|
|
{{_:bnode2} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
||
|
| The triples above are at least needed for interoperability. More statements about this entity (subject) can be made that is specific for your community. You can use community ontologies for describing these relations. Please specify the ontologies you use. |
Example in RDF/XML
RDF example for Eprint
4.3 Data Object
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
Mad Scientist |
Publisher |
A complex research institute |
Title |
"Dataset XYZ" |
Description |
"A fictitious dataset in a CSV format." |
Format |
" |
Issued |
"2011-01-11" |
LastModified |
"2011-03-12" |
Described By |
|
Described By |
| For all semantic types for an object see http://wiki.surffoundation.nl/display/standards/info-eu-repo#info-eu-repo-Objecttypes |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
| The triples above are at least needed for interoperability. More statements about this entity (subject) can be made that is specific for your community. You can use community ontologies for describing these relations. Please specify the ontologies you use. |
Example in RDF/XML
RDF example for Data Object
4.4 Metadata Record
Metadata for Eprint entity
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
|
Publisher |
A trusted repository |
Title |
"MODS metadata" |
Description |
"Metadatarecord for Eprint" |
Format |
" |
Conforms To |
|
Issued |
"2010-12-02" |
LastModified |
"2011-01-11" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
Example in RDF/XML
RDF example of Metadata Record for Eprint
Metadata for Data entity
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
|
Publisher |
A trusted repository |
Title |
"DDI Metadata" |
Description |
"Metadatarecord for Data" |
Format |
" |
Conforms To |
|
Issued |
"2011-01-11" |
LastModified |
"2011-03-12" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
Example in RDF/XML
RDF example of Metadata Record for DataObject
4.5 Human Startpage
Human Startpage for EPrint entity
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
|
Publisher |
A trusted repository |
Title |
"Humanstartpage" |
Description |
"Human startpage for Eprint" |
Format |
" |
Issued |
"2011-01-11" |
LastModified |
"2011-03-12" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example in RDF/XML
RDF example for Metadata Record
Human Startpage for Data entity
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
|
Publisher |
A trusted repository |
Title |
Humanstartpage |
Description |
Human startpage for Data |
Format |
" |
Conforms To |
|
Issued |
"2011-01-11" |
LastModified |
"2011-03-12" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example in RDF/XML
RDF example for Metadata Record
4.6 Nested Enhanced Publication
This example describes how another Enhanced Publication is nested inside the current Enhanced Publication.
Basically this is the core information of the other Enhanced Publication without the ore:aggregates and ore:isDescribedBy information
Example values
Resource Identifier |
|
|---|---|
Persistent Identifier |
|
Semantic Type |
|
Author |
|
Publisher |
Organisation XYZ |
Title |
"Example Nested Enhanced Publication" |
Description |
"This is an example of another of Enhanced Publications to illustrate the nesting of Enhanced Publications." |
Issued |
"2011-01-10" |
LastModified |
"2011-02-11" |
Example in Triples
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example in RDF/XML
RDF example for nested Enhanced Publication
5. Other Entities
Person
| A person is a non-information resource. Therefore, it MUST NOT have a representation, but SHOULD be dereferenced.
The link to a employee page should be included using the |
Resource Identifier |
|
|---|---|
Author Identifier |
|
Semantic Type |
|
Family Name |
"Jansen" |
Given Name |
"Jan" |
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
|
|
|
|
|
|
|
| The triples above are at least needed for interoperability. More statements about this entity (subject) can be made that is specific for your community. You can use community ontologies for describing these relations. Please specify the ontologies you use. |
RDF example for Person
Example of Robbert Dijkgraaf: using the URI of a person's employee page
In the example below of Robbert Dijkgraaf and his employee page at the University of Amsterdam using http://staff.science.uva.nl/~rhd/, the #Resource suffix is added to distinguish between the URI identifying the person Robbert Dijkgraaf and the URI identifying the page containing information about Robbert Dijkgraaf as an employee at UvA.
Note that the suffix does not contain any semantics and that "#Resource" could also be replaced by "#foo".
Subject |
Predicate |
Object |
|---|---|---|
|
||
|
|
|
|
|
|
|
|
|
|
RDF example for Person
RDF/XML examples of all persons and organisations used in previous entries
RDF/XML examples of all persons and organisations used in previous entries
6. Full Example
 | This is a Work-In-Progress. Therefore values and linenumbers may not correspond with the examples above. The values provided in the examples above are leading. |
RDF example for Person
d
Labels
24 Comments
Hide/Show Commentsjan 14, 2011
Thomas Place
Ben verbaasd om naast E-print, Data Object en Metadata Record opeens (?) Person te zien als een onderdeel van een EP. De eerste drie zijn intellectuele producten waarvan je een voorstelling kan maken als onderdeel van een publicatie, maar iets van vlees en bloed zie ik toch moeilijk als een onderdeel van een publicatie. Een publicatie kan er overgaan of kan erdoor gemaakt zijn, maar agregeert het niet.
Ik denk dat je duidelijker moet zijn over het onderliggende conceptuele model, want anders is deze voorstelling van zaken voor mij niet te pruimen.
Is dit de Escape invloed?
Thomas
jan 18, 2011
Maurice Vanderfeesten
Wat je schrijft is zeker stof om het volgende onder de aandacht te brengen;
Person staat erin omdat het "Agent" representeert zoals beschreven in het ORE object model in de DRIVER-II studie.
Hier wordt de kern van een verrijkte publicatie beschreven wat gebruikt/verwacht moet kunnen worden door iedere service provider.
Het mooie van RDF is juist dat het je niet beperkt en dat jij en anderen meer beweringen over de subjecten mag toevoegen. (zie Frank van Harmelen) Zo is een verrijkte publicatie niet beperkt tot bibliografische gegevens, maar kunnen er ook vak/domein specifieke informatie worden toegevoegd.
Wat we hier proberen te doen is dat er in ieder geval een basis aan bibliografische gegevens aan een verrijkte publicatie onderdelen wordt toegevoegd, waardoor een service iets krijgt aangeleverd waar het iets mee kan doen.
jan 21, 2011
Thomas Place
Ik ben nauw betrokken geweest bij het opstellen van ORE object model in DRIVER-II. Het toevoegen van een persoon aan een publicatie werd zeker niet gezien als het verrijken ervan. Dit is een citaat uit het oorspronkelijke document:
"Enhancing a publication involves adding resources to this ePrint. These can be the resources that have been produced or consulted during the creation of the text. In general they support, justify, illustrate or clarify the scientific claims that are put forward in a publication."
Het is overduidelijk dat als het DRIVER document schrijft over resources 'information resources' worden bedoeld. Het gaat over digital objects. "Agent" in het object model is de entiteit die de digital objects (enkelvoudig of compound) produceert. De ORE Aggregations zijn de compound digital objects geproduceerd door een Agent, net zoals er Agents zijn voor de geaggregeerde digitale objecten. De Agents zijn echter geen onderdeel van de Aggregations. Je krijgt dan constructies dat er Agents zijn de Agents die onderdeel zijn van de Verrijkte Publicatie produceren. Dat zijn dan de ouders. Kunnen die ook onderdeel van de VP, ik zou bijna zeggen van de familie, zijn?
Het klopt dat je van alles in een ORE Aggregation kan stoppen (misschien is Escape veel meer een Resource Map editor dan een VP editor) en het klopt ook dat RDF je niet beperkt in de beweringen die je kan maken. Maar het is niet waar dat een Verrijkte Publicatie uit van alles kan bestaan en dat je ervan alles over kan zeggen. Wil 'Verrijkte Publicatie' nog voor iets staan dat zul je de vrijheidsgraden moeten inperken, want anders is het een loos begrip.
Wat de bibliografische gegevens betreft, je kunt die prima in RDF representeren en dat moeten we ook zeker gaan doen. Maar dan moet je wel even nadenken hoe je dat precies doet. Iig niet zoals nu wordt voorgesteld. Vind ik.
Thomas
feb 10, 2011
Dennis Vierkant
Hoi Thomas,
ESCAPE heeft inderdaad een andere uitgangspositie gekozen. Maar als we ESCAPE buiten beschouwing houden en alleen even naar dit document kijken zie ik geen conflicten tussen wat jij zegt en de inhoud van het document. Wellicht is het een misverstand of is het document ondertussen al bijgewerkt.
Met jouw definitie van een EP ben ik het eens dat een persoon niet "in een aggregatie" behoort. Maar als je het document leest, dan wordt dat ook niet gedaan. Bij "Bibliographic Entities" staat geen entiteit "persoon" vermeld. De persoon komt alleen voor als waarde van de eigenschap "auteur" of "publisher". In RDF is alles een node, dus ook een auteur. In dit geval is een auteur een foaf:Person. Als je in de voorbeeld ReM kijkt zie je dat deze persoon niet als aggregated resource is opgenomen (via ore:aggregates). De persoon is alleen in het RDF document opgenomen als onderdeel van de metadata.
Ook een notatie als deze verandert daar niets aan:
Dit is RDF technisch namelijk equivalent aan:
Dus in alle gevallen is de foaf:Person een losse RDF node. Zolang deze niet ore:aggregates in de aggregatie wordt getrokken is het dus niet een "aggregated resource" en dus ook geen "onderdeel" van de EP.
Kun je je hier in vinden?
Groeten,
Dennis
feb 10, 2011
Thomas Place
Beste Dennis,
Mijn reactie had inderdaad betrekking op een eerdere versie. Maar de huidige versie is nog steeds niet klip en klaar over de positie van Person. Dit staat er: "Then one describes all the entities (eprint, dataset, person, etc.) containing the Enhanced Publication." Afgezien van de ongelukkige formulering, hier wordt nog steeds persoon in een adem genoemd met andere aggregated resources. Je hebt gelijk in de rest van de document wordt persoon niet (meer) gebruikt als aggregated resource. En daar ben ik blij mee.
Groet, Thomas
mrt 15, 2011
Maurice Vanderfeesten
Beste Thomas,
in afgelopen EPXchange meeting hebben we besloten dat Personen buiten de EP aggregatie horen.
We hebben het model van Peter Verhaar ter hand genomen en daarin staan personen niet genoemd als onderdeel van de EP.
Echter willen we personen wel opnemen in de rdf.
We hebben een rule of thumb in gesteld: Alles bij Bibliografische entiteiten wordt dcterms gebruikt. en bij personen en organisaties foaf. Dus je krijgt geen foaf:maker bij een bibliografische entiteit, maar dcterms:creator. dcterms:creator verwijst naa een persoon in de rdf. deze persoon is opgebouwd volgens de foaf structuur. Daarin kan een verwijzing worden opgenomen foaf:made richting de publicatie, maar dat hebben we niet verplicht gesteld. dcterms:creator heeft geen inverse relatie dcterms:created... foaf wel... foaf:maker owl:inverseOf foaf:made
feb 10, 2011
Dennis Vierkant
Hoi Magchiel,
Je vroeg me laatst bij de EP meeting om eens door je technische beschrijving van resource maps door te lezen. Bij deze mijn input (op de versie van 10 februari).
------------------
ReMs are retrieved using deferencing, either via Cool URIs with or without (RECOMMENDED in this scenario where only the RDF/XML representation is used) content negotiation or using Hash URIs for identifiers of the
aggregations.Het is me niet geheel duidelijk wat je voorkeur is. De zin leest gewoon niet erg makkelijk.
------------------
An RDF/XML document starts with a root-element
RDF. This then containsDescriptionwhich contain the triples. The Subject is defined in theaboutattribute of theDescriptionelement.De rdf:Description kan worden vervangen met een RDF type:
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-typed-nodes
De subject kan ook via een ID (of nodeID):
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-ID-xml-base
etc.
Ik begrijp dat je hier geen volledige RDF/XML beschrijving wilt opnemen. Misschien kun je de toon van het hoofdstuk net iets meer veranderen in "kan worden geserialized in de volgende manier", nu leest het net alsof dit de enige manier is.
Ook is het denk ik verstandig om te benadrukken dat ondanks dat RDF/XML in XML geschreven is, je het beter met specifieke RDF libraries kunt be-/verwerken. Voorbeelden hiervan:
Java:
PHP:
Perl:
Dit soort libraries begrijpen alle mogelijke variaties in de notatie van RDF en maken het een stuk makkelijker om met RDF te werken. Een RDF/XML aanmaken via XML tooling of op tekst basis lukt nog wel, maar het parsen ervan met XML tooling is echt niet te doen.
------------------
De sluit-tag ontbreekt voor foaf:Person. Daarnaast is het gebruik van rdf:parseType="Resource" hier niet correct. Probeer het maar eens met en zonder in een RDF parser/validator.
-
The following vocabularies are currently supported.
Ik zou hier toch op z'n minst ook dcterms of dces vermelden.
-
A ReM contains basically consists of three blocks:
Misschien kun je hier in plaats van "Description element" beter praten over nodes? We hebben het hier over RDF, niet XML.
------------------
Bij de RDF examples voor de bibliographic entities ontbreken de namespace declaraties.
------------------
In de RDF examples gebruik je door elkaar dces en dcterms. Waarom kies je niet voor 1 van de twee? DCterms zegt dat dcterms:creator een sub property is van dces:creator. Dus als je dcterms:creator gebruikt kun je daaruit dces:creator afleiden:
------------------
6. Full Example
…
Het voorbeeld document is geen well-formed XML, lees het maar eens in in een XML editor / validator. Na correctie hiervan geeft de RDF validator (http://www.w3.org/RDF/Validator/) ook nog een error.
------------------
Nog even wat anders. Dit kun je misschien ook ergens als best practice opnemen. Stel je hebt een enhanced publication in een repository, een onderdeel hiervan is een artikel. In de jump off page van dit artikel kun je (conform: http://www.openarchives.org/ore/1.0/discovery.html) dit opnemen:
Daarmee link je het artikel terug naar de aggregation. Echter, je weet niet welke RDF node uit de resource map overeenkomt met de HTML pagina voor het artikel. Dit kun je oplossen met een "primaryTopic":
http://esw.w3.org/SweoIG/TaskForces/CommunityProjects/LinkingOpenData/AutoDiscovery
Dit is nu ook in ESCAPE ingebouwd.
Een voorbeeld hiervan:
http://chroniclingamerica.loc.gov/lccn/sn85066387/1895-03-05/ed-1/seq-2/
In de source staat de URI van de resource die door de pagina wordt beschreven:
Ik ben minder enthousiast over hun gebruik van relatieve URLs hiervoor.
Een voorbeeld waar voor ik dit nodig heb is metadata extractie. Stel iemand voegt de bovengenoemde pagina toe aan ESCAPE, het systeem kan dan de ORE metadata ophalen en kan via de primaryTopic achterhalen welk deel van de resource map hij moet gebruiken.
Groeten,
Dennis
feb 10, 2011
Thomas Place
Ik heb mijn twijfels over het hebben van een aparte semantisch type voor verrijkte publicaties. Sinds het project SamenInDelen (2008) hebben wij nooit de behoefte gehad aan een aparte categorie. Als een aparte categorie ook inhoudt een nieuwe persistente identifier dan hebben wij een probleem. Bij ons ging het altijd om het verrijken van bestaande publicaties, m.n. publicaties zoals deze zich bevinden in de IR, en die hebben al een identifier. Wat mij betreft zijn er alleen Publications en die behouden hun identifier ook als er een dataset of iets anders bij komt. Net zo goed als dat ik geen nieuw burgerservicenummer nodig heb als ik verrijkt wordt met een vijfde ledemaat (schaap met ..).
Thomas
PS is het niet hoog tijd dat de technische werkgroep zich buigt over het profiel?
feb 14, 2011
Maurice Vanderfeesten
In die technische werkgroep zou ook iemand moeten die de "preservering van VP's" in de gaten houdt. (Iemand van de KB?)
feb 23, 2011
Maurice Vanderfeesten
From: Wilko Steinhoff [mailto:wilko.steinhoff@dans.knaw.nl]
Sent: woensdag 23 februari 2011 11:08
To: Vanderfeesten, Maurice
Cc: Bijsterbosch, Magchiel; Chris Baars
Subject: RE: RDF XML datamodel
Hoi Maurice,
Ik wil nog even op onderstaande vraag terugkomen:
Het is (mij) onduidelijk wat de minimale eisen zijn voor metadata van de Aggregation:
Wat willen/moeten wij verplicht stellen in de ReM’s (Aggreation) zodat NARCIS de boel indexeren/ zoekresultaten tonen kan, en de Visualizer het op een eenduidige manier tonen kan?
B.v. dient dit minimaal een (dc:, dcterms:)titel te hebben?
M.a.w moeten er geen minimale implementatie eisen verschijnen, zoals dat b.v. ook bij SurfShare het geval is?
(i.e. Use of MPEG21 DIDL/MODS for IR’s)
Wat zijn de minimale eisen waar de Visualizer vanuit gaat? Waar kunnen wij deze vinden?
Hoe diep graaft de visualizer door om b.v. een persoon te vinden:-?
Stel dat ESCAPE-ORE personen op een andere manier gaat opnemen, blijft de Visualizer dan werken (neem niet aan dat ie met een triple store werkt)?
Groeten,
Wilko Steinhoff
From: Wilko Steinhoff
Sent: woensdag 23 februari 2011 9:49
To: 'Vanderfeesten, Maurice'
Cc: Bijsterbosch, Magchiel; Chris Baars
Subject: RE: RDF XML datamodel
Hoi Maurice,
Binnen Resource Maps in RDF/XML ben je behoorlijk vrij in het plaatsen van je metadata.
Zo kan de “creator” van zowel de Rem als van de aggregatie op “verschillende” plekken te vinden zijn, onder verschillende namespaces:
- URI
- Literal
- Blank node
Dit wordt op http://wiki.surffoundation.nl/display/vp/Resource+Maps+in+RDF+XML dan ook uitgelegd.
Wij vroegen ons gisteren af of binnen het project hiervoor restricties bestaan, zodat het initiële parsen van de ReM (vooralsnog) op een eenduidige manier gebeuren kan.
Verder heb ik een paar correcties voor de “RDF FullExample” + (voorafgaande snippets):
(http://wiki.surffoundation.nl/display/vp/Resource+Maps+in+RDF+XML#ResourceMapsinRDFXML-6.FullExample)
<ore:Describes rdf:resource="http://myrepository.org/resource/enhancedpublication"/>
Dient <ore:describes rdf:resource="http://myrepository.org/resource/enhancedpublication"/> te zijn (lowercase).
De <rdf:Description> tag voor de ResourceMap wordt niet afgesloten: -> </rdf:Description>
Verder kan, voor de duidelijkheid, wellicht de optionele tag
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/ResourceMap" /> hierin worden opgenomen?
Dit is niet verplicht maar kan in de context van voorbeeld wel duidelijkheid scheppen. In de aggregatie wordt ie immers wel (ook optioneel) genoemd:
<rdf:type rdf:resource="http://www.openarchives.org/ore/terms/Aggregation" />
Groet,
Wilko Steinhoff
feb 23, 2011
Maurice Vanderfeesten
Hoi Wilko, veel van je vragen kan ik niet tot slecht beantwoorden, maar ik ga het toch proberen. De eerste vraag is over het datamodel de rest is over de visualiser die, terecht ook met het datamodel samenhangen.
--------------------------------
Q: ... moeten er geen minimale implementatie eisen verschijnen, zoals dat b.v. ook bij SurfShare het geval is?
A: Ja deze minimale eisen MOETEN verschijnen. Echter dit zijn de Minimale eisen zoals ze zijn vastgesteld in de ORE techmeet van September 2010. Graag verwachten we van NARCIS input of deze eisen nog strikter moeten worden, of dat dit is waar je zonder al te veel moeite iets mee kan. Dus ik stel de vraag terug! Doe maar een suggestie en ergens in het midden moeten we uit komen.
--------------------------------
Q: Wat zijn de minimale eisen waar de Visualizer vanuit gaat? Waar kunnen wij deze vinden?
A: Dat is een goede vraag om als uitgangspunt te nemen. Het staat in de Offerte aanvraag; als moscow.
Visualisatie
Visualisatie van objecten die onderdeel uitmaken van de Verrijkte Publicatie.
M
Visualisatie van relaties tussen onderdelen.
M
Metadata
Tonen van objectnamen.
M
Tonen van semantisch type van objecten.
M
Tonen van de namen van relaties tussen objecten.
M
Tonen van annotaties van relaties.
M
Metadata/details anders dan namen, typen en annotaties.
W
Manipulatie
Tonen van metadata bij mouse over.
C
Filtering
W
Data Access
RDF/JSON
M
RDF/JSON volgens hoofdstuk ‘Data formaat’ van bijlage A.
S
RDF/XML parsing.
W
--------------------------------
Q: Hoe diep graaft de visualizer door om b.v. een persoon te vinden:-?
A: De visualiser is gemaakt om data uit de complete resourcemap te verwerken. Alle nodes worden gecontroleerd op inverse relaties die niet expliciet zijn vermeld. Dus ook voor personen. Echter ga je werken met een tripple store, dan kun je niet de hele tripple store in JSON aan de visualiser voeden. Het beste is om de inverse relaties door inferencing van te voren door een preproces uit te laten zoeken, en de relaties rond het geselecteerde object in RDF/JSON aan de visualiser te voeden. Om om te gaan met a-synchrone data, dat moet nog ontwikkeld worden in de Dataconnector.js. Bij het aanleveren van a-synchrone data moet je bedenken dat de functie "uitzoeken van inverse relaties" door de visualiser uitgeschakeld kan worden, omdat de inferencing over de tripple store dat al gedaan heeft, en omdat de visualiser gevoed wordt met steeds maar een klein deeltje van de totale graaf.
--------------------------------
Q: Stel dat ESCAPE-ORE personen op een andere manier gaat opnemen, blijft de Visualizer dan werken (neem niet aan dat ie met een triple store werkt)?
A: Even kijken. wat bedoel je precies? Welke andere manier? De visualiser maakt gebruik van een schema.js; hiermee kun je de visualiser configureren om een icoontje te laten zien van persoon, met label 'person', bij rdf:type foaf:person en bijv. bij rdf:type dc:creator, en rdf:type narcis:wetenschappelijkmedewerker, ik noem maar wat.
Het punt is dat de visualiser zo is gemaakt dat er super flexibel kan mee worden omgegaan. Je kunt ook iconen toevoegen door de sprite.png en de style.css aan te passen. Your wildest dreams come true! :)
feb 24, 2011
Maurice Vanderfeesten
Moet foaf givenName en familyName geïncapsuleerd worden tussen Person of niet?
Hierboven heb je staan:
Moet het nou
of voor de volledigheid toch?
feb 25, 2011
Dennis Vierkant
Dus zonder de parseType=”Resource”. Zie mijn eerdere comment.
feb 25, 2011
Max Kemman
Heb dit doorgevoerd in de voorbeelden en beschrijvingen. Ik neem aan dat die niet geldt voor de beschrijving van een persoon zelf, zoals bijvoorbeeld:
Verder nog de vraag of dit niet ook geldt bij <dcterms:publisher rdf:parseType="Resource">, kan de parseType daar ook weggelaten worden?
feb 27, 2011
Maurice Vanderfeesten
Kan het voorbeeld RDF/XML grondig nagekeken worden? Het wordt namelijk niet goed geparsed door de rdf converter.
zie: ep-data-model-full-example.rdf
http://convert.test.talis.com/?data-uri[]=http://wiki.surffoundation.nl/download/attachments/10616910/ep-data-model-full-example.rdf&input=&output=html&callback=Deze laat slechts 2 RDF descriptions zien.
Ik neem aan dat er niks mis is met de parser, ondat hij de RDF/XML van de ORE gateway en ESCAPE wel laat zien.
zie de ORE gateway
http://convert.test.talis.com/?data-uri[]=http://ore.place.pukurin.uvt.nl//rem/rdf/neeo_didl/oai:wo.uvt.nl:183889/http://arno.uvt.nl/oai/wo.uvt.nl.cgi&input=rdf-xml&output=html&callback=of de VP editor van twente
http://convert.test.talis.com/?data-uri[]=http://escape.utwente.nl/rem/80&input=&output=html&callback=feb 28, 2011
Maurice Vanderfeesten
Opgelost! Met dank aan Magchiel; gebruik de W3C validator:
http://www.w3.org/RDF/Validator/ARPServlet?URI=http://wiki.surffoundation.nl/download/attachments/10616910/ep-data-model-full-example.rdf&PARSE=Parse+URI:+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED
Er ontbrak een = teken bij "rdf:resource="
Wil je de graaf zien van deze resource map zie:
http://www.w3.org/RDF/Validator/ARPServlet?URI=http://wiki.surffoundation.nl/download/attachments/10616910/ep-data-model-full-example.rdf&PARSE=Parse+URI:+&TRIPLES_AND_GRAPH=PRINT_GRAPH&FORMAT=PNG_EMBED#graph
mrt 30, 2011
Maurice Vanderfeesten
Vraag bij:
Author2
dcterms:creator0..n
M
M
M
M
The author of the resource using
foaf:Personwithindcterms:creator.is de creator , de creator van het real world object (schilderij van van Gogh), of van de JPG (in het geval van illustraties)
We gaan er van uit dat het om het object gaat van wie de naam van de creator in de context past waar het om gaat...
wie is de creator bij een foto van een architectonisch gebouw? (gaat het om de fotograaf of de architect?)
wie is de creator van een foto van een persoon? (gaat het om de creator van de foto of de creator van de persoon?)
apr 18, 2011
Thomas Place
De termen uit de info:eu-repo/semantics namespace beginnen in dit document allemaal met hoofdletters, terwijl afgesproken is om ze met kleine letter te laten beginnen, zie ook de wiki.
Als je de object types wil resolven met purl dan lukt dat niet. De publication types resolven wel met purl.
Thomas
nov 14, 2011
Maurice Vanderfeesten
hoofdletter vs kleine letter zie onderstaande discussie
Voor het resolven van de publicatie typen vs andere typen...
Tja, Hier moet iemand achter aan om met het purl-account in de info:eu-repo sub-domain voor elke term een redirect te maken naar de owl.
Ik stel voor dat hier een RFC van gemaakt moet worden.
nov 14, 2011
Maurice Vanderfeesten
Hoi Maurice,
Ik heb 2 opmerkingen over het Resource Maps in RDF XML document.
Bij Core Ontologies staat:
dai http://purl.org/info:eu-repo/dai#
Verderop staat echter:
xmlns:dai="http://purl.org/info:eu-repo/dai/"
De ene keer dus met een #, de andere keer met een /. Wat is correct?
Daarnaast zie ik ook de opmerking van Thomas:
De termen uit de info:eu-repo/semantics namespace beginnen in dit document allemaal met hoofdletters, terwijl afgesproken is om ze met kleine letter te laten beginnen, zie ook de wiki.
Hij heeft gelijk, we hadden afgesproken om ze met een kleine letter te doen.
Groeten,
Dennis
Dennis Vierkant
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
Telephone +31 53 489 4121, Fax +31 53 489 2383
D.Vierkant@utwente.nl; http://www.utwente.nl/icts
nov 14, 2011
Maurice Vanderfeesten
Hoi Dennis,
1.
Volgens Magchiel moet de namespace met een # zijn. in het voobeeld staat dus een fout.
Als je die met een # resolved, krijg je een OWL terug, met een / niet, dus...
De rede voor een # is dat dit gebruikelijk is bij duidingen van namespaces voor ontologiën. (info:eu-repo/dai/nl/12345 is een entry)
Als "de community" wil dat dat met een / resolved, dan moet daarover een RFC moeten worden ingediend, en besproken worden met de werkgroep.
2.
Klopt, er is afgesproken in de metadata werkgroep dat de publicatietypen beginnen met een kleine letter.
Echter volgens de W3C normering voor RDF is het gebruikelijk dat Object typen met een hoofdletter beginnen en relaties met een kleine letter.
Omdat we in de RDF wereld zijn gestapt is met dit document een poging gedaan om ook gehoor aan te geven aan de W3C norm.
Wat nu?
nov 14, 2011
Dennis Vierkant
We hebben tijdens de laatste vergadering (gezamenlijk) besloten om hier toch te kiezen voor een kleine letter. Dit omdat deze vorm reeds in gebruik is in de SURFshare community. Het zou uitermate verwarrend zijn wanneer deze identifier buiten RDF met een kleine letter begint en bij RDF opeens met een hoofdletter.
Als we een nieuwe lijst met types maken, dan hebben we de vrijheid om te kiezen voor een naamgeving naar smaak, dit zijn reeds bestaande type identifiers.
Groeten,
Dennis
nov 16, 2011
Egbert Gramsbergen
Een paar opmerkingen:
1- wdrs:describedBy moet zijn wdrs:describedby (met kleine letter b dus). Beetje vreemd dat W3C dit zelf zo doet maar het staat er nu eenmaal. Dit zal helaas overal waar het staat (bestaande VP's, Escape?) moeten worden aangepast.
2- eurepo:Datafile en eurepo:HumanStartPage bestaan niet volgens de ontologie op http://purl.org/info:eu-repo/semantics/
3- niet fout maar overbodig: ore:isDescribedBy in de aggregatie terwijl er al ore:describes in de resource map staat. Dit zijn volgens de OAI-ORE ontologie elkaars inversen.
En over de dai:
Er wordt een porpertiy dai:daiId gebruikt.
Als ik kijk naar de voorbeeld-tabellen lijkt het een ObjectProperty, en de objects zijn non-information resources. In dat geval zou ik dai:daiId vervangen door owl:sameAs. Dat strookt met de linked-data principes, immers een persoon is een nou-information resource en als personen A en B dezelfde dai hebben weet je dat A=B.
Maar als ik kijk naar de voorbeeld-rdf/xml, dan zie ik dat het wordt gebruikt als DatatypeProperty, dus met literals als object. Kan ook (hoewel ik de waarde dan niet zou vermommen als uri), maar dan moeten we el wel voor zorgen dat dai:daiId een InverseFunctionalProperty is. Daarmee maak je dezelfde redenering mogelijk over de personen A en B, alleen je introduceert een extra property die naar mijn idee niet nodig is.
De ontologie zoals hij nu bestaat klopt overigens niet, want dai:daiId staat er helemaal niet in. Wel dai:identifier, een DatatypeProperty. Die is niet inverse functional, ook niet via zijn superProperty (ja die heeft hij).
Tot slot over de voorbeelden van rdf/xml: ik vind het niet overzichtelijk, en het is ook niet gebruikelijk, om blank nodes in rdf/xml expliciet uit te schrijven. Ik zie ze liever op de "normale" manier. Omdat de tabellen met triples er ook bij staan is dit juist leerzaam voor newbies.
nov 16, 2011
Egbert Gramsbergen
Ik zag zojuist dat de b/B fout in wdrs:describedby niet consequent was doorgevoerd, dwz op sommige plaatsen was het wel goed. Kan dus zijn dat het in bestaande VP's en Escape wel goed zit maar dit moet wel even worden gecontroleerd.