1 / 16

Content Working Group Brainstorming Results

Content Working Group Brainstorming Results . Meeting actions. Discussing what is a solution for scenario #1 Played with the framework and proposed changes Approached provenance as a DL resource

koen
Download Presentation

Content Working Group Brainstorming Results

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Content Working GroupBrainstorming Results

  2. Meeting actions • Discussingwhatis a solutionfor scenario #1 • Playedwith the framework and proposedchanges • Approachedprovenanceas a DLresource • Identifiedpossiblecategories and sub-categoriesofsolutions, i.e., “outline”of the Cookbook

  3. DL.Org Interoperability Framework Knowledge Interoperability Realwordsprocesses and workflowsabout the organization Organization Organization Knowledgemodelingand design: organization, end users, designers, developers Task Resource Relevantfactsabout the resource: structure, semantics,functionalities Semantics Semantics Realization Realization Data management systems: data model and language Knowledgerepresentation and provision: hardware, software, protocols Interface Interface Toolsfor remote interaction: data model and language System Interoperability Consumer Provider

  4. Objective: cookbook Knowledge Interoperability Categories “Outline” organization organization Sub-Categories Sub-Categories Task Resource Interface Interface Interface Interface Logic Logic Solution Space S1 S2 S3 S4 S5 S6 Realization Realization Interface Interface System Interoperability Provider Consumer Rome DL.org meeting, 26-28 of May, 2010

  5. Mainconcepts • Content(semantics, realization and interface) • Data model • formaldescription (withspecs or DDL) ofstructure and semanticsof the resource (extentionalview) • Language • formallanguage, programminglanguage, or APIstomanipulate the resource • Resource • provenance, attributes, context, identifiers, format • Tasks • Consumerspurpose (can be a combinationofsub-tasks)

  6. Categories • “Providers to be consumed”: a consumer is willing to perform a task by consuming resources from interfaces of one or more providers • “Providers willing to be consumed”: a provider is willing to expose the resource to a consumer that expects given resource and APIs from providers ? ? Task Task Resource Resource Consumer Consumer Provider Provider 6 Rome DL.org meeting, 26-28 of May, 2010

  7. Provider(s) tobeconsumed: the sub-categories • Provider Cardinality: one(1:1) provider, fixed(1:n) number of providers (e.g., European Film Gateway) or arbitrary (1:) number of providers(e.g., Europeana, DRIVER, OAIster) • If more than one provider is included: • Different data models and languages • Different data models and same language • The same data model but different languages ? Task Resource Consumer Provider Rome DL.org meeting, 26-28 of May, 2010

  8. Provider(s) tobeconsumed: the sub-categories • “Data-oriented” data model and language • Consumer can performtaskstoconsume the data instances • “Data type-oriented” data model and language • i.e., protocolstodiscover format structure and semantics • Consumer can performtaskstodiscoverstructure and semantics and thenconsume data instancesaccordingly ? Task Resource Consumer Provider Rome DL.org meeting, 26-28 of May, 2010

  9. Provider(s) willingtobeconsumed: the sub-categories • An existing consumer, withgiven interface and constraints/requirements (e.g., OAI-PMH consumer expectingproviderstoofferDublinCoreusedaccordingtogiven “guidelines”) • Provider performs the mapping, consumer doesnothing • Provider hastogive the mapping and consumersperforms • e.g., throughuser interface or XSLT files ? Task Resource Consumer Provider

  10. Provider(s) willingtobeconsumed: the sub-categories • Adoptionofstandards: an hypothetical consumer, matching some given standards (on resource representations and/or access APIs) • Resource data modelstandards (no language API isnecessarilyrequired) • StudyingprovenancemodelsforDigitalLibraries • e.g., MARCXML, CERIFXML, DublinCore • Resource data model and LanguageAPIsstandards • e.g., OAI-ORE , OAI-PMH ? Task Resource Consumer Provider Rome DL.org meeting, 26-28 of May, 2010

  11. Cookbookoutline:Consumer lookingfor a solution (OAI-PMH example) • categories (e.g., provider tobeconsumed) • Sub-category (e.g., given data model and language) • Provider Resource(attributes, e.g., attributesasdublincore) • Provider APIs(language, e.g., OAI-PMH) • Solutions • Task oriented (e.g., index the record): allpossibletechnicalsuggestions and references Interface Rome DL.org meeting, 26-28 of May, 2010

  12. Cookbookoutline:Provider lookingfor a solution (Europeana, OAI-PMH example) • categories (e.g., provider willingtobeconsumed) • Sub-category(consumer notperforming the mapping, given data model and language) • Consumer resource(attributes, e.g., ESE format) • Provider APIsexpectedby consumer (language, e.g., OAI-PMH) • Solutions: writingan OAI-PMH publisher and a transformatorfromlocal data format to ESE- allpossibletechnicalsuggestions and references Interface Rome DL.org meeting, 26-28 of May, 2010

  13. Describing solutions… • Solutionsshouldbedescribed in termsof: • Overview (context), Preconditions (conditions), Effects (changes), Transformationfunction (how), Assessment (qualitative evaluation and cost) • Terminologyfrom the framework • Resource, task, organization,semantics, realization and interface Rome DL.org meeting, 26-28 of May, 2010

  14. Methodologytodescribesolutions • Identify “firm conditions” in the Provider-Consumer context • Specify required level of quality • Characterize the task preconditions • Select the solution that satisfies the task preconditions and it is more closed to the desired level of quality Rome DL.org meeting, 26-28 of May, 2010

  15. Consumer’s Task • A task can be composed by multiple sub-tasks • The task preconditions result from the composition of the subtask preconditions • Generally a solution to interoperability for a consumer is the composition of solutions to simpler problems related to sub-tasks • Step oriented • fetch it, transform it, split task into sub-tasks, match the sub-tasks with the sub-object parts, check if there exist tools for performing the task that uses the parts DL.org All WG Meeting, 26-28 May 2010

  16. Next steps • Identifying 10 interoperability solutions according to the schema overview-preconditions-effects-transformation-assessment (all) • Propose scenarios - (trivial ones, e.g. date, less trivial, e.g. metrics) (Detlev/all) in order to evaluate the “outline” of the Cookbook • Circulate an updated version of the cookbook including the observations discussed today • Feedback by all DL.org All WG Meeting, 26-28 May 2010

More Related