This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
This document is a deliverable (D12.5 Final Implementation Report) of the ARIADNE project(“Advanced Research Infrastructure for Archaeological Dataset Networking in Europe”), which isfundedundertheEuropeanCommunity'sSeventhFrameworkProgramme.ItpresentsresultsoftheworkcarriedoutinTasks:12.3“ImplementingIntegration”.
TheoverallarchitectureoftheARIADNEinfrastructurehasbeenlaiddownbytheuserrequirementsanalysis (D12.1), and the infrastructure specifications (D12.2). Initial implementation has alreadybeendescribedinD12.3.ThegoaloftheARIADNEinfrastructureistointegratedataandmetadatafromdifferentproviders intoonecommonschema,andalsotoprovidesemantic integrationalongdifferentaxes(e.g.subject,space,time).Thisintegrationintendstoprovideusefulanduser-friendlyinformation services for archaeology. The services are intended to be available not only toresearchersandrelatedstakeholders,butalsotoawiderrangeofpotentialusersrequiringaccesstocollectionsanddatasets.
The main goal of Task 12.3 is to accomplish the infrastructure implementation of ARIADNE. Theinfrastructure is specifiedonD12.2and includesservices suchas the registry,vocabulary services,metadataenrichmentservices,preservationservices,etc.withthefollowingcomponents:
a) atriplestorewithsemanticfeaturesb) theARIADNEportalc) theMOReaggregationinfrastructured) anindexercomponent(Elasticsearch)e) ametadataqualitymeasurementservicef) asetofenrichmentservices
ThemainobjectivesofWP12are:• ToadaptinfrastructuresprovidedtoARIADNEforintegration• To design, implement and configure the necessary mechanisms (crosswalks, mappings) and
The main goal of Task 12.3 is to present the infrastructure implementation of ARIADNE. Theinfrastructure is specifiedonD12.2and includesservices suchas the registry,vocabulary services,metadataenrichmentservices,preservationservices,etc.(fig.1).
Thegoalof theARIADNE infrastructure is to integratedataandmetadatafromdifferentprovidersinto one common schema, and also to provide semantic integration along different axes (e.g.subject, space, time). This integration intends to provide useful and user-friendly informationservices for archaeology. The services are intended to be available not only to researchers andrelatedstakeholders,butalsotoawiderrangeofpotentialusersrequiringaccesstocollectionsanddatasets. The overall architecture of the ARIADNE infrastructure has been laid down by the userrequirements analysis (D12.1) and the infrastructure specifications (D12.2). Initial implementationhasalreadybeendescribedinD12.3.
AtLevel1,dataiscreatedbyresearchprojectsandgroups,andsubsequentlystoredininstitutionalrepositoriesatLevel2.Then,atLevel3,thisdataisaggregatedbyhigher-leveldatamanagers,suchas data centers, portals and thematic information gates. Finally, at Level 4, the ARIADNEinfrastructureintegratesallinformationandprovidesasetofservicesthroughtheARIADNEportal.Theseservicesinclude:resourcediscovery,integrateddatasearchservices,andotherservices(suchaspreservation,quality, etc.).DeliverableD12.1 “UserRequirements” [1],whichoutlines theuserneedsfortheinteroperabilityframeworkoftheARIADNEInfrastructure,setsoutageneralviewoftheintegrationfunctionalities,organizedinfoursuccessivelevels(fig.2)[1].
The implementation of the infrastructure focuses on the creation and aggregation of contentaccordingtotheACDMmodelspecification[4](thecurrentversionis2.6).Accordingtothecontentaggregationworkflow(fig.3),theMOReaggregator(seerespectivesectionbelow)isusedtoharvestexistingcontent inotherschemasandmapittoACDM,or importdirectly frombatchesofXMLorExcelfiles.ACDMencodedinformationisthenpushedtoanRDFstoreandtotheRegistryservice.AnotherserviceisusedtosynchronizecontentfromtheRDFstoretoanElasticsearchindexservice.The rest of the services within the infrastructure consume these three APIs in order toaccess/managethisinformation.TheAPIsare:
4 ARIADNE Services for Data Collection and Integration
InARIADNEtheaggregationservice iscomprisedofasetof toolsandservicesthataimtoharvestcontentrelatedtoarchaeology,andtocleanandtransformittoacommonformat(inthiscasetheACDM).ThiscontentisthenstoredpersistentlyinanRDFstoreandanindexserver.Thisprocessisintegral to the data integration process of the project, which focuses on integration of datascatteredamongstdiversecollections,datasets,unpublishedfieldworkreports(greyliterature),andpublications. Thisprovidesresearcherswiththeabilitytouseheterogeneousdistributeddatasetsasanintegralcomponentofarchaeologicalresearchmethodologies.ContentaggregationisnecessaryinordertomapallcontentavailablebytheARIADNEpartnersinacommonschema(inthiscase,theACDM),soastofacilitatetheintegrationprocess.Aggregationincludesanumberofsteps,suchasvalidation,cleaningandenrichment.
Inorder toaddress theserequirements, theMetadata&ObjectRepository (MORe)aggregator [6]has been employed in ARIADNE (http://more.dcu.gr/). The MORe aggregator, developed by theDigitalCurationUnit–IMIS,AthenaR.C.,hasbeeneffectivelyusedindiverseprojects(CARARE,3D-ICONS,andLoCloud)toaggregateandenrichmillionsofrecordsanddeliverthemtotheEuropeanaplatform (http://www.europeana.eu).MORe provides a flexible architecture, and is used here toaggregatecontent invarious formats,andfromavarietyofsources, totheRDFstore, theregistryandtheElasticsearch.MORe incorporatesamicro-serviceorientedarchitecture(fig.4),supportingcore services for input, validation, transformation, eEnrichment and publication of the ingestedcontent.
Thecoreservicesaredesignedinamodularwaysotheycancombineoneormoremicro-servicestoaccomplishthevarioustasks.Thisapproachallowsthesystemtobeextendedmoreeasily,andalsore-use certainmicro-services. The stackable andmodular architectureofMORe (fig. 4) presents adataaccess layerused toaccessdataon the storageanda core services layer, encompassing thevarious core services management. The different core management services are responsible fororchestrating numerous micro-services. For example, the enrichment management services areresponsiblefororchestratingandstreamliningtheexecutionoftheenrichmentmicro-services.
ARIADNED12.5(Public)
13
Figure4.TheMORearchitecture.
Otherimportantarchitecturalaspectsofthesystem(fig.5)providethecapabilityofusingmultiplestoragetechnologiessimultaneously.Thedataaccesslayer,whichisinstantiatedthroughastorageAPI, provides seamless access todataobjects regardlessof the storage inwhich they reside. Twoadditional importantcomponentsofMORearethemessagingand loggingservices.Themessagingservice is responsible forprovidingmessagingacross services. It isbasedon theRabbitMQAMPQbroker, a framework that provides scalability and elasticity. The logging service provides amechanismformonitoringalltheservicesintheaggregationinfrastructure.ItisimplementedbasedontheGraylog2loggingframework,whichprovidesamechanismforstoringlogsofanyformatandfrom any service. Graylog2 provides a way of organizing these logmessages (using streams) andpresentingtheminauser-friendlyway.
ARIADNED12.5(Public)
14
Figure5.SignificantarchitecturalaspectsofMORe.
Themainaggregationworkflowispresentedbelow(fig.6).Aninformationpackageisharvestedbyamicro-service and is pre-validated (pre-validation includes basic validation, such as a record to bestructurally checked to see if it is well formed). The package can be either deleted or ingested.During ingest, thepackage isstored inthestorage layer (it firstgoes intotemporarystorage),andthenitcanbeeitherrejectedortransformedintoacommonschema(inthiscasetheACDM).Duringtransformation,thenewrepresentationisvalidatedandindexed.Afterithasbeentransformed,thepackagecanberejected,enrichedorpublished.Inthecaseofenrichment,anewrepresentationiscreated (enriched ACDM), which has to be validated and indexed again. During the publishingprocesstheuserselectsthepublicationtarget.
The ARIADNE services for data access andmanagement consist of a layer that provides differentways of allowing access to the available data sources. These are native access to the RDF store,access through an Elasticsearch, and access through the Registry. Although they access the sameinformation, each might contain only a subset (e.g. Elasticsearch), or provide access throughdifferentprotocolsandformats.
Furthermore, as ARIADNE enables trans-national access of researchers to data centres, tools andguidance, it is important to provide multiple access points in the data sources. This means thatthrough thedataaccessmanagementservices, researcherscanpreviewtheirdatasets indifferentformats,suchasRDF,JSONorXML.
The Semantic Triple Store
ARIADNEimplementsanRDFstoretoholdthecataloginformationrepresentedinRDFandavailablethrough a SPARQL endpoint. Taking into account the complexity of the ACDM, an RDFrepresentationof theARIADNECatalog is necessary to support the complexqueries required. Forthatreason,theACDMcanberepresentedasRDFandURIsareassignedforeachtypeofresource.
ARIADNED12.5(Public)
16
ThedataintheRDFstoreisupdatedbyMORedynamicallyduringcontentaggregation.TheVirtuososemantic technology (http://virtuoso.openlinksw.com/) has been used for implementing theARIADNEtriple store.Virtuosowasselectedprimarilydue itsbetterperformance,especiallywhenhandlinglargeamountsofcontent.Inaddition,Virtuosohasbeenavailablesince1998,asopposedtoSesame,whichwasreleased in2004.Virtuoso isalsoavailable inmanyprogramming languages(.Net,C,C#,C++,Java,JavaScript,Perl,PHP,Python,Ruby,VisualBasic),whereasSesameisavailableto Java,PHPandPython. Themost important characteristics thatmakeVirtuosomore favourableover Sesame are its capability to partition the data and being able to be setup in a clusteredenvironment.TheSPARQLendpointandascreenshotcanbeseenbelow(fig.7).
The Elasticsearch component provides the indexing capabilities required in order to power theARIADNE portal. Elasticsearch (ES) is based on thewell-known Lucene indexing engine (the samethat SolR uses) and provides extremely low response times for performing full text search andfacetedbrowsing.ThetwomainreasonsforselectingElasticsearchoverothertraditionalinterfacesto SolRare its simpleandeffectiveRESTfulAPI (fig. 8) and its clustering capabilities. Elasticsearchprovidesveryrobustandeasytouseclusteringsupport.
ARIADNED12.5(Public)
17
The primary format that Elasticsearch accepts through its API is JSON. Thatmeans that all ACDMrecordsmustbefirstmappedintoJSONinordertobepushedtoES.
description: "Onderzoeks- en adviesbureau voor Bouwhistorie, Archeologie, Architectuur- en Cultuurhistorie (BAAC bv) heeft een archeologisch bureauonderzoek en inventariserend veldonderzoek met behulp van boringen (karterende fase) uitgevoerd op een terrein in de bebouwde kom van Tilburg. Tijdens het veldonderzoek is aangetoond dat de bodem is verstoord tot in de Chorizont van de dekzandafzettingen. Archeologische indicatoren werden daarbij niet aangetroffen. De verwachte duinvaaggronden zijn niet aangetroffen. Hieruit kan worden geconcludeerd dat aan het plangebied een lage archeologische verwachting voor archeologische resten uit alle perioden kan worden toegekend.", rights: "BAAC bv", id: 46949, language: ["nl"], subject: "Event/intervention databases", title: "Tilburg Bredaseweg 421", originalId: "DMO_ID easy-dataset:22059", keyword: ["50F", "Bredaseweg 421", "Tilburg", "Noord-Brabant"], creator: [{ id: 480, name: "Boshoven, E.H.", type: "person" }], spatial: [{ id: 34449, coordinate_system: "http://www.opengis.net/def/crs/EPSG/0/4326", lon: 5.04075, label: "51.55941102,5.04075138", lat: 51.5594 }], landingPage: "http://www.persistent-identifier.nl/urn:nbn:nl:ui:13-dox-y9f", issued: "2008-01" } }
In order to provide accurate and robust thematic based results, an indexwith the complete AATterms was created. This index contains the complete AAT hierarchy plus the content providermappingsfromtheirnativesubjectstoAAT.AnexampleofanAATispresentedinfig.9.
"label":"vambraces","lang":"en"},{"label":"arambrazo","lang":"es"},{"label":"armguards","lang":"en"},{"label":"arm-guards","lang":"en"},{"label":"avambrazo","lang":"es"},{"label":"vambrace","lang":"en"},{"label":"guards,arm","lang":"en"},{"label":"onderarmstuk","lang":"nl"}],"prefLabel":"vambraces","providerMappings":[{"sourceURI":"http://purl.org/heritagedata/schemes/mda_obj/concepts/97103","matchURI":"http://www.w3.org/2004/02/skos/core#broadMatch","providerId":1104,"sourceLabel":"ARMGUARD"}],"id":"300201790","broader":[{}],"uri":"http://vocab.getty.edu/aat/300201790","altLabels":[],"scopeNote":"Termappliedtotheensembleofplatearmorpieces forthearmbelowtheshoulder,consisting of two cannons linked by a cowter, in use in Europe from the 14th to the 17th century. Alsosometimesusedtomeancannonswornontheforearmonly,includingsuchancientGreekpieces."}}
Figure9.TherecordofanAATterm.
ARIADNED12.5(Public)
20
The ARIADNE Registry
TheregistryserviceisasinglepointwhereallARIADNEresourcesarestoredandmadeavailable.Itprovides access to all ACDM records, and allows users to create/edit them both through a RESTinterface and through a Web UI. The registry consists of an SQL database and a REST API thatprovidesaccesstothedata.TheuserscanregisteranAPIkeyandusetheRESTAPItoperformCRUDoperationsonallentities.AnexampleofanAPIcallisasfollows:
This sectiondocuments the listof services thatcouldbeused toperformvalidationon theACDMXSD.Validationisperformedduringcontentingestandcreation,andisfacilitatedautomaticallybyMORe.AllvalidationservicesprovideareportingmechanismthroughtheUItoalerttheuser.
Apart from the standard validation reporting mechanism, when a certain type of information isdetected (spatial, temporal, thematic), respective blocks of information appear alerting the uservisually.Ascreenshotpresentinganexampleforthematicandspatialinformationcanbeseeninfig.10.
Schema Validation
This service provides schema validation for every XML record ingested. This functionality isautomaticallyprovidedbyMORe.SchemavalidationrequiresanXSD(inthiscaseACDMXSD).
Normalization
This service performs normalization of the ingested datasets. This process ensures the properidentitymanagementofeachresourcebymatchingproviderandcollectioninformation,alongwithnativeidentifiers,etc(fig.11).
Link Checking
ThelinkcheckingservicerequiresalistofelementsthatcontainURLs,forwhichitattemptstocheckifthelinksareavailable(or,else,itreturnsanHTTPerrorcode).ThisserviceisalreadyprovidedbyMORe, but requires a list of elements to check. Elements thatmay contain links and need to becheckedhavetobemarkedbeforehand.
ThisserviceperformsmorecomplexchecksonanXMLrecord.Itprovidesamechanismtoperformcomplex conditional checks, and also provide feedback back to the user in a human-readablemechanism. The mechanism is provided by MORe but requires a Schematron rule for ACDM. AscreenshotofanindicativeSchematronrulevalidationreportcanbeseeninfig.12.
The systemprovidesa service formetadataenrichment that consistsof a seriesofmicro-servicesthatcanbeusedeffectivelytoaugmentACDMcontent.Thesemicro-servicescanbeeitherusedasenrichmentservicesinMORe,ordirectlybytheARIADNEpartnersandservices.Inthissection,alistofavailablemicro-servicesispresented.
Once the metadata enrichment services are registered in MORe, users can utilize them byincorporatingthemintoenrichmentplans.Enrichmentplansareawayofstreamliningandexecutingenrichmentservicestogether.Theyapplytooneschemaandcanbere-usedindifferentpackages.Thismeansusers candefine themonce,andapply them forall incomingpackageswith the samecharacteristics.
Although enrichment services can perform a wide variety of operations, only the main ones arepresented in this section, and in particular those concerning subject, special and temporalenrichment.
Subject Enrichment
Thethematicservices focusonenrichingsubject-related information.Thisenrichmentprocesscaneither be automatic (e.g. by automatically matching concepts from vocabularies) or manual (byallowing users to create collections of concepts and attach them to all items in a package). Allthematic enrichment services have access to the large number of vocabularies listed inAnnex III.Thesevocabulariesarestandardised,publishedandSKOSified,andcontainhundredsof thousandsofterms.
Description: A string (e.g. dc:subject or dc:description) is submitted to the service and a list ofrelevant concept terms are retrieved (basedon a list of 29 SKOS vocabularies). Theelementdc:subjectisupdated.
Description: This service allows the user to upload or create a list ofmappings from their ownnativesubject terms(found intheirprovidedpackages) toAAT.ThesemappingsareusedtoenrichtheincomingpackageswithAATterms.
AAT Mapping and Conversion of Subject Terms
In order to ensure interoperability and facilitate integration, all ACMD recordsmust contain AATterms(AATstandforArtsandArchitectureThesaurusandreferstothefacetedthesaurusdevelopedbytheGettyFoundation,andintendedfor“vocabularycontrolofmuseum,culturalheritageandartcollections”). Thus, a translation service, developed by the Hypermedia Research Group at theUniversity of South Wales, is provided to allow partners to upload their native subjectterms/vocabularies,mapthemtotheAAT,andexportamappingfile.Thismappingserviceproducesthemappingrulesinvariousformats(suchasJSONandCSV).Thetoolisavailableat:
http://heritagedata.org/vocabularyMatchingTool/
The service comes as a web application (thus only a web browser is needed) and provides anintuitiveUIinterface(fig.14)consistingmainlyoftwocolumns(leftforthesourcevocabulary,rightforthetargetvocabulary).
ARIADNED12.5(Public)
26
Figure14.ScreenshotoftheVocabularyMatchingTool.
Userscandefinetheconceptmappings,thensaveandexporttheminvariousformats.AnexampleofaJSONencodedmappingcanbeseen inTable2.ThismappingcouldbealsouploadedintotheMORe subject translation enrichment service and used to automatically transform native subjecttermstoAATconcepts.
Terminological Information for the ARIADNE Infrastructure
The use of thesauri, and especially the required use/existence of at least 1 AAT termper record,addsacertaincomplexitythatrequiresspecialhandlingbytheinfrastructure.Furthermore,hands-ontestingoftheportal(e.g.throughrunningdifferentqueries)broughtouttheneedforsemanticexpansionanduseofmultilingualsearch.Theinformationflow(regaringsubjects)canbeseeninfig.15,inwhichcontentprovidersprovidetwokindsofsubjectterms:a)nativesubjects(couldbeanything,SKOSified,simpleterms,etc)b)providedsubjects(havetobeAAT)ProvidersthatdonotprovideAATtermshavetomaptheirnativesubjecttermstoAATusingthevocabularymappingtool.ThistoolinturnfeedsallthemappinginformationtoMOReandassociatesitwiththeprovider.Thus,whenapackagefromaproviderisreceivedthatcontainsnativesubjectsandamappingexists,thederivedsubjectisautomaticallycomputedandusedtoenrichtherecord.
Asmentioned, in the elastic search a separate AAT index is published that includes the providermappings(undereachAATtermthenativesubjectsareassociatedaccordingthemappings).
Description: 1. A string (e.g. place Label) is submitted for geo-coding and theLatitude/Longitude coordinates are returned. The lat/lon elements areupdated.
Description: A string containing the grid coordinates is submitted for transformation and theWGS84lat/loncoordinatesarereturned.Thelat/lonelementsareupdated.
Service: TransformationbetweenEPSGcodes
Status: ProvidedasaservicethroughMORe
Description: The lat/lon coordinatesare transformed fromanEPSGcode toanother. The lat/lonelementsareupdated.
Service: Geo-normalization
Status: ProvidedasaservicethroughMORe
Description: A string that contains a concatenated string of coordinates is submitted for geo-normalization. The user indicates the delimiter and the lat/lon coordinates arereturned.Thelat/lonelementsareupdated.
This section currently includes a language identification service to automatically detect languageinformation based on text. It is based on Apache Tika and contains trainedmodels for all majorlanguages.
This sectionaimsatdocumenting the listof services thatcouldbeused toprovidequality relatedinformationforACDMrecords.Thesemetadataqualityservicesmainlyfocusoncompletenessandconsistency.
This service allows to check certain elements for consistency issues. Consistency refers to thefollowingcases:
1. URLformatchecking(forexample:elementslikerdf:aboutshouldhaveaURLasvalue)2. Dateformat(basedonISOdatesformat)3. Person names (regex patterns that could detect patterns such as: Name Surname, Title
A series ormock-ups were created to start a discussion on the design and functionalities of theARIADNEportal,and toactasaguideline for implementation.Thesemockupspresentedadesignwiththreedifferentsections:Browse,SearchandServices.TheBrowsesectionwasintendedtoactas a startingpoint for exploring theARIADNE Info Space in different geo, time and subject basedvisualizations.TheSearchsectionpresentsaclassic informationretrieval interfaceforthedifferenttypesofresourcesintheARIADNECatalog,andisintendedtobecomplementedusingfacet-basedsearch(fig.18–fig.22).TheServicessectionprovidesaccesstothedifferentservicesdevelopedintheprojectaspartofWP13.
Although the ARIADNE portal is designed to be modular, the main framework selected for itsimplementation is Laravel (http://laravel.com/). Laravel is a PHP based framework designed tofacilitatethedevelopmentofmodel-view-controller(MVC)applications.Laravelisopensourceandalreadyprovidesagoodnumberofservices,ascanbeseenfromthetable3.
Initial Prototype
Aninitial implementationoftheARIADNEportalusingthementionedtechnologiesisshowninthefollowing screenshots (fig. 23 – fig. 25). They present the initial implementation,which has beenusedbypartners to inspect their contentandevolvedaccording to themockupspresented in theprevioussection.TheprototypewasbasedonaBootstrap3.0responsivethemeanddesign,whichallows use of the portal from virtually any kind of device, including workstations, tablets andsmartphones. The prototypewas designed using amodular architecturewhere eachmodulewasusedtoprovideaspecific functionality, includingsearching,browsingandviewingofrecords,mapandthematicviews,contentproviders’facets.
The final implementation of the ARIADNE portal (http://portal.ariadne-infrastructure.eu/) wascarriedoutaccording to themockupsand,as canbe seen in fig.26, itpresents theuserwith thetoolstoperformasimplesearch(wherehecanselectoneoranyfield),anAATbasedautocompletesearch based on a subject, and a search based on space (using a map), time (using a timelinehistogram)andsubject(usingathematiccloud).
Figure26:Ariadneportalhomepage.
Afterenteringaquery,theuser ispresentedwithasearchresultspagewherethematching itemsare listed on the right (initialy sorted by score, allowing the user to also change the sortingparameter)anda listof facetson the left. The facets includeaquery refine textbox,aheatmapwhereallthesearchresultsaredepictedonthemap,atimelinehistogramandalistofboxeswithlistedattributesthatcorrespondtothoseofthematchingrecords.
The user can utilize any (or a combination) of these facets to refine his/her search, include thetimelineandheatmap.
ARIADNED12.5(Public)
41
Figure27:Ariadneportalsearchresults.
Figure28:Ariadneportalrecordview.
Source Code
ThesourcecodeoftheAriadnePortal(latestversion1.2.0)ishostedinGitHubrepository(fig.29),with open access. It can be found at https://github.com/dainst/ariadne-portal, together with theinstallationinstructions(fig.30).
• Improvementsonthesearch/browsequeriesinElasticSearch.• ImprovementsinthemappingoftheElasticSearchindextoimprovefacets.• ImprovementsinthePortalsearchandbrowsefunctionality.• Buttonineachresourceandgeneralcontactforminportalforreportingdataissues.• Creation of a date normalization service in order to better handle dates and improve the
facetedfunctionality.• Creationof a spatial normalization service that calculates themidpointof aboundingbox
andenrichestheresources,thusprovidingthemageographicalrepresentation.• RDFmicro-mappingandexportoftheCatalog.• Creation of new andmodification of existing import services that import data from excel
This document presented the final implementation of the ARIADNE infrastructure project. Thetechnicaldesignchoices,aswellastheprimarycomponentsthatarerequiredtosetupandmakethe infrastructure operational, have been presented. The infrastructure has aggregated over 2millionrecords,cleaned,enrichedandpublishedthemtotheARIADNEportal(http://portal.ariadne-infrastructure.eu/),whichisavailableandusedglobally.
Thediversityofthecomponentsrequiredtoruntheinfrastructure,alongwiththelargenumberofservices, are indicative of the complexity of the infrastructure. During the testing of theinfrastructure,thevariousissueswereaddressedandimplemented.
ThisARIADNEportalservesasthepublicfaceoftheinfrastructure,andwaslaunchedduringtheCAA2016 conference onMarch 29th, 2016. Since then, and up to theNovember 17th, 2016 (almost 8months),ithasbeenvisitedbyover8,700users,withover45.000viewsfrom39countries(referredtocountrieswithmorethan10visits).
Response [ {"desc":"A new package [498] has been created.","timestamp":"2014-10-14 12:49:14.0"}, {"desc":"Harvest complete for package 498","timestamp":"2014-10-14 12:49:24.0"}, {"desc":"Validation complete for package 498","timestamp":"2014-10-14 12:49:34.0"} ]
The first thing the user who wants to use the API must do, is to find his own API key fromtheSettings.Thiswayhecanaccessonlyhisownrecordsandmanipulatethem.HewillneedthekeyfortheAPIcalls.
properties List ThelistofthepropertiesforthespecificDataResource
Status 200–SUCCESS500–INTERNAL_SERVER_ERROR
Example
ARIADNED12.5(Public)
64
Request:{"key":"tUzQwU2P2T1RqBRHC1ENJmtaopTMfWF63sHE7OrjRPzr98DiBG"}Response:{"id":41, "name":"dFMROe","properties":{ "dct_issued":"1990s","dct:accessRights":"access only to 75565 records", ":scientificResponsible":"282","dcat:keyword":"Roman coins", "ARIADNEDistributionId":"44", "dct_identifier":"dat:41","dct:subject":"Roman coins", "dct:extent":"140000 records", "dct:audience":"researchers","ariadne_subject":"Artefacts", "dct_temporal":"116", "dct:creator":"281", "dct_language":"en","dct:description":"information on coins of the Preroman (Celtic) period and of Roman ImperialTimes found in Austria and in Romania", "dct:landingPage":"http://www.oeaw.ac.at/numismatik/fmroe/content/suche.de.php","dct_spatial":"108",":dbms":"MySQL"},"type":2}
Request:{"key":"tUzQwU2P2T1RqBRHC1ENJmtaopTMfWF63sHE7OrjRPzr98DiBG"}Response:[{"id":6,"name":"dati.culturaitalia"},{"id":17,"name":" SITAR - Sistema InformativoTerritorialeArcheologicodiRoma"}]