1 / 10

Different layers of expressiveness QueryLang and/or Data Model No sessions ! Architecture

Different layers of expressiveness QueryLang and/or Data Model No sessions ! Architecture Verify that OurLanguage fits in architecture Experiments EUNLRE, ARIADNE/GLOBE, KnowledgeMarkets Due diligence ~existing repositories Later Context (in repository and thus OL or separate?)

asha
Download Presentation

Different layers of expressiveness QueryLang and/or Data Model No sessions ! Architecture

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. Different layers of expressiveness • QueryLang and/or Data Model • No sessions ! • Architecture • Verify that OurLanguage fits in architecture • Experiments • EUNLRE, ARIADNE/GLOBE, KnowledgeMarkets • Due diligence • ~existing repositories • Later • Context (in repository and thus OL or separate?) • Simple restrictions can be dealt with in OL - check against layers • result set, …

  2. Plan • OLv0.7: end of June • Summer: implementation/experiments • October: re-asses OLv0.7 based on experiments • OLv0.9: 1 Jan 2007 • Deliverable: 1 July 2007

  3. Layers of expressiveness for results • Assumption: result=identifiers of resources • The resource itself is out of scope. (delegate to obtain) • Identifier of metadata?? • Needed for multiple descriptions of same resource in same repository • Indicate that you relaxed the query • Some qualitative indication on path matching,from “perfect” (perfect mapping) over “pretty close” (known close mapping) to “informed guess” (partial path match) to “just guessing” • Note: relates to user profiling and context • Ranking • Level 0: bag • Level 1: partial sequence • 1st result at least as important as 2nd at least as important as 3rd … • Level 2: set of <id,%> • Level 3: set of <id, %, method to calculate %> • Method can include metadata instance that made the resource appear in the result • Metadata • Level 0: only identifier • Level 1: specific metadata • Not always all! • Level 2: actual resource ---> out of scope • Merging • Out of scope: for middle layer or application

  4. Layers of expressiveness • Assumption: result=identifiers of resources • Ranking? • Merging? • 0: search terms (same as CQL) • “dog” • AND if several search terms

  5. Layer 1: properties of resources • Property is • path, but no expressions, parentheses, … • Title as well as DC.title, LOM.General.Title • ~CQL: SRW.ServerChoice… • Example: DC.title, LOM.general.title, … • “Namespace” • We reserve the following path roots • DC, LOM, MPEG • No core properties, nothing special about Types • documents or people or events or … • “jaguar” cars • Only “User defined” • LOM, DC, MPEG • Core attributes of values? • Level 1: just strings • AND of path property-search term pairs • Note: • Lucene would support this • CQL Level 1: Boolean operators or reference to index

  6. Level 2 • Parentheses • LOM.General.Identifier.(catalog=isbn and entry=xxxxx) • no variables, no skipping operators • Namespace extensions? • To be re-discussed once level 1 is clear • UP TO LEVEL 2, WE ARE WITHIN MORE OR LESS CURRENT STATE OF THE ART FOR NOW • We need to make at least explicit that we don’t do what comes beyond in what came before

  7. Level 3 • Other kinds of values than strings? • URI to identify value? • Type of value? • Level 4 • Joins, quantifiers, nested queries • Variables • Needs to be separated out? • Level 5 • recursion

  8. To discuss? • Properties of values: • Type (URI): restricts values • string value [with URI]: representing value • URI: identifies value • Namespace, common data model • We don’t want • Proximity operator • Hard to implement • We may not need it in our context • Because we do have structure (I.e. schema) • Relevance feedback • Separate issue? • Needs the protocol to obtain the document?

  9. How do we go from here • Do a short note on the wiki • Present • PoLiMi • Friday 19 morning • Post slides to the wiki • By presenters • By Monday 22 May • Document that details levels 0, 1 and 2 • Structure from these slides: PoLiMi & Stefaan • 1 June • LOMI seminar to verify that we agree on what we agreed on • 6 June, 14h30, FlashMeeting&SummerSchool

  10. + / - • “less hot” • What is our implementation and/or research ambition? • Remains unclear • Uptake most important? • More aspects than SQI • How does it relate to professional learning? • Enabler • We need better title? • Do we understand the community we’re trying to serve? • This is more about our visions than about existing practice & there are early initiatives • Focus on concept, not on syntax • “proximity” and semantics • Not just presenting, we did a lot of work • focused discussion • LOMI seminars helped to prepare, so we could focus fast • And we needed to have f2f to move beyond what we did before • “like you all” • Nice hot weather • Later: look at protocol for interaction with repository • All have contributed at technical level • We learn to understand one another

More Related