310 likes | 437 Views
Reportnet SEIS proposals. Søren Roug. SEIS Prerequisites. Information is managed as close as possible to its source Information is provided once and shared with other for many purposes Information should be readily accessible for the end-users. Who are the providers in SEIS?.
E N D
Reportnet SEIS proposals Søren Roug
SEIS Prerequisites • Information is managed as close as possible to its source • Information is provided once and shared with other for many purposes • Information should be readily accessible for the end-users
Who are the providers in SEIS? • Member countries • International institutions • Non-EU countries • Regional bodies • Non-Government Organisations
What is QA? • Quality Assessment is a task the requester performs to verify the delivery is: • Correct • Complete • Useful for requester’s intended purpose • The resulting QA report is a permanent subjective comment on the delivery
How does Reportnet work today? • It’s a central repository with several features • Webforms • Converters • QA system • Envelopes • Every delivery is tagged with obligation, country and delivery period
Questions • When the datasets aren’t uploaded to CDR, how are the datasets found?
Questions • When the datasets aren’t uploaded to CDR, how are the datasets found? • How do we describe what the dataset contains?
Questions • When the datasets aren’t uploaded to CDR, how are the datasets found? • How do we describe what the dataset contains? • How to ensure it isn’t obsolete?
Introduction to scenarios With these prerequisites and questions in mind we developed 5 scenarios that progressively loosened up the requirements for the providers ”The scenarios” is a tool to structure the discussion around one issue at a time
Scenario 1 The first scenario simply covers giving every country a CDR. Doesn’t require much modification to Reportnet Content Registry becomes the new center The backside is, it only handles the same dataflows as today
Scenario 2 • Difference from scenario 1 is that we can’t rely on the functionality CDR has • In particular the QA reports produced by the requesters • Where do we store them?
Scenario 3 • Issue here is how to handle deliveries without an obligation id • I see only one option: If the provider can’t add metadata to the dataset that is understood by the requester, the requester must do it • First the requester must find it using the available metadata (or notification)
Scenario 3 • Then the requester tags/groups/bookmarks/registers the URL • This doesn’t happen on one site, but several specialised sites • Content Registry puts it all together to one factsheet • Example:
Scenario 4 • Scenario 4 discusses how to handle • data in multiple files • derived data • new versions under new file names • etc. • It doesn’t add much to the core proposal and isn’t interesting
How to solve Scenario 5 • Datasets posted on static websites • No harvestable metadata
Discoverability and tagging • Once the file is found, via Google or notification by email, it is registered by EEA staff in our registry • EEA attaches some standard metadata • Title, coverage, period, keywords • Quality assessment • Users attach their own metadata • Bookmarks, tags, comments • Links to products that use the file
Will it work? We’re already doing it We’re already maintaining bookmark lists and adding metadata to files we don’t own
What enhancements are needed? • Improve Content Registry • Better database • More flexible interface between CR and users, and CR and websites • Places to add/edit metadata and QA reports • Harvestable by Content Registry • Improved APIs to bring as many into Reportnet as possible