1 / 45

CCBR Systems applied to Earthquake Science

CCBR Systems applied to Earthquake Science. Mehmet Aktas Dr. David Leake Dr. Marlon Pierce Indiana University. SERVOGrid. SERVOGrid is a NASA project to integrate historical, measured, and calculated earthquake data (GPS, Seismicity, Faults) with simulation codes.

pete
Télécharger la présentation

CCBR Systems applied to Earthquake Science

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. CCBR Systems applied to Earthquake Science Mehmet Aktas Dr. David Leake Dr. Marlon Pierce Indiana University

  2. SERVOGrid • SERVOGrid is a NASA project to integrate historical, measured, and calculated earthquake data (GPS, Seismicity, Faults) with simulation codes. • Using GML extensions as common data format.

  3. General Earthquake Model (GEM)

  4. Distributed Resources

  5. GEM Codes http://www-aig.jpl.nasa.gov/public/dus/gem/gemcodes.html

  6. Motivation • Purpose • Intelligent retrieval on metadata describing codes written for earthquake science. • Guidance on how to run the codes to get reasonable results. • Guidance for inexpert users to browse and select codes through a portal. • Casebase • disloc – produces surface displacements based on multiple arbitrary dipping dislocations in an elastic half-space • simplex - inverts surface geodetic displacements to produce fault parameters • VC – simulates interactions between vertical strike slip faults. visulization and analysis services

  7. CCBR Case CCBR CASE Feature Solution Problem Feature Feature = <Question, Answer>

  8. Conversational CBR CCBR CASEBASE A Case from CASEBASE Query Case A B Feature 1 Feature 2 Feature 3 Feature 4 Feature 1 Feature 2 Feature 5 Case IF ((A.Feature1.Solution = B.Feature1.Solution) & (A.Feature2.Solution = B.Feature2.Solution)) THEN Consistency # = 2 Case = <Problem, Solution>

  9. Prototype CCBR Application for GEM Code Selection http://ripvanwinkle.ucs.indiana.edu:4747/cbr/index.jsp

  10. Prototype CCBR Application for GEM Code Guidance

  11. Developing an Ontology for General Earthquake Modeling Codes

  12. Motivating Scenario • We have a collection of codes, visualization tools, computing resources, and data sets that we want to combine in an ontology. • Instances of the ontology can then be made that describe specific resources. • After we have built instances, we can pose queries on the data to retrieve values. • Values may be structured, so we can do “stepped” queries. • We thus need to start by grouping together related resources.

  13. Group 1: Simulation Codes • Disloc: calculates surface stress displacements causes by a fault placed in an elastic half-space. Surface data can be either on a grid or on defined scattered points. Can also create InSAR-style surface displacements. • Simplex: inverts Disloc to estimate fault parameters from observed surface displacements. Surface displacements can be either on a grid or at defined points. • GeoFEST: does a realistic model of stresses created by a fault. Uses finite element method, realistic material properties. • AKIRA: Converts a geometry (layers, faults) specification into a finite element mesh. Successive calls refine the mesh. Needed as a helper application for GeoFEST. • lee2geof: Converts the finite element mesh to GeoFest by associating boundary conditions and material properties with the nodes. • VirtualCalifornia: Based on realistic fault and fault friction models, simulates interacting fault systems.

  14. Group 2:Visualization Codes • We associate simulation codes with zero or more visualization systems. • GMT (General Mapping Tool) • IDL • RIVA • In practice, we usually refer to scripts for specific tasks rather than the entire toolkit.

  15. Group 3: Compute Resources • Grids: a Sun Ultra 60 with Disloc, Simplex, and VC installed. • Danube: a linux duel processor machine with GeoFEST, lee2geof, Akira, GMT installed. • Jabba: an SGI 8 processor machine with RIVA installed.

  16. Group 4: Data Types and Formats • This is a mixture of data objects and representations. As always, the data itself is not represented but information like the creator of the data is. • Faults • GPS data • Seismicity • Surface stress data • INSAR data • Surface data representation: grid or point data

  17. Building an Ontology Putting together an Ontology with RDF and RDFS

  18. Front Matters • We now wish to create classes and properties that we can couple into an ontology. • First, let’s define a base object, GEMObject, that we will extend as necessary. • This object doesn’t do anything but it will have some uses when we define property ranges and domains. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3c.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs=http://www.w3c.org/2000/01/rdf-schema#> <rdf:Description rdf:ID="GEMObject"> <rdf:type="http://www.w3c.org/2000/01/rdf-schema#Class"/> <rdfs:label>GEMObject</rdfs:label> <rdfs:comment>This is a generic object from which everything in our ontology will be derived. </rdfs:comment> </rdf:Description> </rdf:RDF>

  19. Defining Some Useful Classes • Based on our introductory comments, we need the following classes: • GEMCodes, with “application” and “visualization” extensions • GEMData, such as Faults, GPS, and so on. • GEMDataFormat: either grid or point data • ComputeResources: host computers.

  20. Defining a GEMCode Application Codes • We next choose to subdivide the GEMCode class into finer distinctions: Application and Visualization. • Application resources are described like this: <rdf:Description rdf:ID="ApplicationCode"> <rdf:type="http://www.w3c.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#GEMCode"/> <rdfs:label>Application Code</rdfs:label> <rdfs:comment>This is used to describe science application</rdfs:comment> </rdf:Description> • GEMCodes should extend our GEMObject generic superclass. • It should itself be extended by other, more specific resource types. <rdf:Description rdf:ID="GEMCode"> <rdf:type="http://www.w3c.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="#GEMObject"/> <rdfs:label>GEMCode</rdfs:label> <rdfs:comment>This is a general code class that we will extend</rdfs:comment> </rdf:Description> GEMData and GEMDataFormat Computing Resources <rdf:Description rdf:ID="ComputeResources"> <rdfs:label>ComputeResources</rdfs:label> <rdfs:comment>This is a general compute resource class that we will extend</rdfs:comment> <rdfs:subClassOf rdf:resource="#GEMObject"/> </rdf:Description> • The GEMData resource looks like this. <rdf:Description rdf:ID="GEMData"> <rdfs:label>GEMData</rdfs:label> <rdfs:comment>This is a general data class that we will extend</rdfs:comment> <rdfs:subClassOf rdf:resource="#GEMObject"/> </rdf:Description> • The GEMDataFormat resource looks like this <rdf:Description rdf:ID="GEMDataFormat"> <rdfs:label>GEMData</rdfs:label> <rdfs:comment>This is a general data format class that we will extend</rdfs:comment> <rdfs:subClassOf rdf:resource="#GEMObject"/> </rdf:Description>

  21. Defining Useful Properties Making Classes Mean Something

  22. Defining Properties • Classes by themselves don’t tell us much, but when we associate them with properties, things start to fall into place. Before describing how a property may be encoded, let’s try and enumerate the ones that we will need. • ownsGEMResource: who owns a particular resource. • installedOn, hasCode: where a GEMCode is installed, or, conversely, what codes a particular computing resource has. • hasData: where some piece of data is (on some compute resource). • hasDataFormat: associate a data format with a piece of data. • takesInputData, createsOutputData: what kind of data a code takes as input and generates as output. • dependsUpon: a code depends upon another operation before it can be completed.

  23. A Property for Ownership Now let’s look at how to encode this first property. It looks like this: <rdf:Description rdf:ID="ownsGEMResource"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdfs:domain rdf:resource="http://www.w3c.org/2001/vcard-rdf/3.0#"/>' <rdfs:range rdf:resource="#GEMObject"/> </rdf:Description>

  24. Tag Explanations • Property descriptions start out the same as our class descriptions, but instead of having a Class <type>, they are of <type> Property. • Next, we use two new RDFS tags, domain and range. • Domain is used to say which classes can be the subject of this property and range specifies the classes that can be objects. • The range of the ownsGEMResource object is obviously class, GEMObject. • The domain, on the other hand, is a human and we have not yet defined classes for humans. • Instead of inventing our own, we use a standard definition for people, known as a VCARD. • VCARD properties include first and last names, addresses, email addresses, and so on

  25. The installedOn Property • The other properties can be constructed similarly • We show the installedOn example: <rdf:Description rdf:ID="installedOn"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdfs:domain rdf:resource="#GEMCode"/>' <rdfs:range rdf:resource="#ComputeResource"/> </rdf:Description>

  26. Developing a Fault Schema • In addition to classes we outlined above, we need to expand on our GEMData class. • This class however needs to be extended to describe specific data types. • Faults are characterized in several ways, which we will group as follows: • Descriptive Characteristics: name of the fault (like San Andreas, Northridge, etc.), the journal that describes the fault, the publication date, and other “Dublin Core” like parameters. • Material Properties: Viscosity, lame parameters • Geometric Properties: Size and orientation of the fault (see figure). • Geo-location Properties: Latitude and Longitude

  27. Fault Resources Let’s look at how to describe the fault, concentrating on the geometric properties. We’ll start as before: <rdf:RDF xmlns:rdf="http://www.w3c.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3c.org/2000/01/rdf-schema#" xmlns:gem="http://www.servogrid.org/schemas/GEMOntology"> <rdf:Description rdf:ID="Fault"> <rdf:type rdf:resource="http://www.w3c.org/2000/01/rdf-schema#Class"/> <rdfs:subClassOf rdf:resource="http://www.servogrid.org/schemas/GEMOntology#GEMData"/> <rdfs:label>Fault</rdfs:label> <rdfs:comment> This is a fault class. Would be useful to compare to an XML fault definition. </rdfs:comment> </rdf:Description> <!—Property values go here --> </rdf:RDF>

  28. Fault Properties We are simply defining a class instance called “Fault” that is a subclass of the GEMData resource we defined previously. The real usefulness comes from the properties. We show only geometric properties, but we can easily add to these. Let’s look at one such value: <rdf:Description rdf:ID="hasDepthValue"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:domain rdf:resource="#Fault"/> <rdf:range rdf:resource="http://www.w3c.org/2001/XMLSchema#double"/> </rdf:Description> <rdf:Description rdf:about="http://www.w3c.org/2001/XMLSchema#double"> <rdf:type rdf:resource="http://www.w3c.org/2000/01/rdf-schema#DataType"/> </rdf:Description>

  29. Fault Properties with Units • Fault depths are measured in kilometers, so we could add units by defining a new resource called “KilometerUnits”. This value would be described by two properties; hasKilometerUnits and hasKilometerValue. <rdf:Description rdf:ID="KilometerUnits"> <rdf:type rdf:resource="http://www.w3c.org/2000/01/rdf-schema#Class"/> <rdfs:label>KilometerUnits</rdfs:label> </rdf:Description> <rdf:Description rdf:ID="hasKilometerUnits"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:domain rdf:resource="#KilometerUnits"/> </rdf:Description> <rdf:Description rdf:ID="hasKilometerValue"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:domain rdf:resource="#KilometerUnits"/> <rdf:range rdf:resource="http://www.w3c.org/2001/XMLSchema#double"/> </rdf:Description>

  30. Giving hasDepthValue a Property with Units • We then modify the hasDepthValue so that its range is the KilometerUnits resource instead of the simple XML double type. <rdf:Description rdf:ID="hasDepthValue"> <rdf:type rdf:resource="http://www.w3c.org/1999/02/22-rdf-syntax-ns#Property"/> <rdf:domain rdf:resource="#Fault"/> <rdf:range rdf:resource="#KilometerUnits"/> </rdf:Description>

  31. Creating Schema Instances • We’re now ready to look at some simple examples of creating instances of our ontology. Let’s first start with a simple example. Let’s take a look at Disloc. We need to know the following about Disloc: • Where is it installed? • What does it take for input data? • Where is the input data? • What does it create as output data? • What can I use to visualize its output? • Note that we are not actually trying to invoke the code. We are just trying to manage enough information about the code so that we know how to invoke it with other services

  32. Creating URIs • I first need to assign several URIs for the things that I will use to describe my resource. • Again, these are just intended to be structured names of things on the internet, or at least pointers to information about things. • The URIs we will use are • The GEMOntology itself will be assigned the URI of http://www.servogrid.org/schemas/GEMOntology. • All computing platforms will be subdirectories of the URI http://www.servogrid.org/instances/ComputeResource • All data names will start with http://www.servogrid.org/instances/data/ • All applications will have names starting with http://www.servogrid.org/instances/gemcodes/. • We can further extend the relative paths to specify/distinguish applications and visualizations.

  33. An Instance for Disloc We first need to describe the applications (Disloc). In particular, we need to describe the input and output that Disloc takes, and the places where this code is installed. This looks like the following: <rdf:RDF xmlns:rdf='http://www.w3c.org/1999/02/22-rdf-syntax-ns#' xmlns:rdfs='http://www.w3c.org/2000/01/rdf-schema#' xmlns:gem='http://www.servogrid.org/schemas/GEMOntology#' xmlns:dc="http://purl.org/dc/elements/1.0/"> <rdf:Description rdf:ID="Disloc"> <rdf:type rdf:resource="http://www.servogrid.org/schemas/GEMOntology#ApplicationCode"/> <dc:creator>A. Donnellan</dc:creator> <gem:installedOn rdf:resource="http://www.servogrid.org/instances/ComputeResources/Grids"/> <gem:takesInputData rdf:resource="http://www.servogrid.org/instances/data/Faults"/> <gem:createsOuputData rdf:resource="http://www.servogrid.org/instances/data/SurfaceStress"/> </rdf:Description> </rdf:RDF>

  34. RDF Representation in CCBR Systems

  35. RDF Representation of a GEM Code disloc.c (Meta-data) <rdf:RDF xmlns:rdf='http://www.w3c.org/1999/02/22-rdf-syntax-ns#' xmlns:rdfs='http://www.w3c.org/2000/01/rdf-schema#' xmlns:gem='http://www.servogrid.org/schemas/GEMOntology#' xmlns:dc="http://purl.org/dc/elements/1.0/"> <rdf:Description rdf:ID="Disloc"> <rdf:type rdf:resource="http://www.servogrid.org/schemas/GEMOntology#ApplicationCode"/> <dc:creator>A. Donnellan</dc:creator> <gem:installedOn rdf:resource="http://www.servogrid.org/instances/ComputeResources/Grids"/> <gem:takesInputData rdf:resource="http://www.servogrid.org/instances/data/Faults"/> <gem:createsOuputData rdf:resource="http://www.servogrid.org/instances/data/SurfaceStress"/> </rdf:Description> </rdf:RDF>

  36. Triples in disloc.c RDF Representation Class Property Property Value Disloc dc:creator A. Donnellan Disloc gem:takesInputData rdf:resource="http://www.servogrid.org/instances/data/Faults” Disloc gem:createsOutputData rdf:resource="http://www.servogrid.org/instances/data/SurfaceStress" Disloc gem:installedOn rdf:resource="http://www.servogrid.org/instances/ComputeResources/Grids"

  37. Queries on RDF Meta-data - I

  38. Queries on RDF Meta-data - II

  39. Ideas on RDF representation and integration with IUCBRF • Each case has an RDF instance • Each RDF instance has a number of triples • Each RDF instance might have more descriptive information than necessary for CCBR system retrieval. • User will form a triple as a query, rather than answering a question. (Protégé Query Service has a good example for this).

  40. Protégé Query Service

  41. Ideas on RDF representation and integration with IUCBRF • Ranking of the cases • Cases will be ranked based on their consistent triple numbers. • If the case has a matching triple, it will have higher ranking. • If the case does not have the entered triple, its ranking won’t change, unless user wants the cases which don’t have this triple. • Ranking of the questions • We need to recommend user what properties of GEMObject Class are good to start. • Ranking can be based on (property, property value) apperance # in the triples stored in the case base.

  42. CCBR Case with RDF Representation CCBR CASE RDF Triple Solution Problem RDF Triple RDF Triple = (Subject, Predicate, Object)

  43. How will it work? CCBR CASEBASE A Case from CASEBASE Query Case A B RDF Triple 1 RDF Triple 2 RDF Triple 3 RDF Triple 4 RDF Triple 1 RDF Triple 4 RDF Triple 5 Case //case ranking calculation for “B.RDFTriple 1” Model model = new ModelMem(“case A”); StmtIterator stmts = model.listStatements(); while (stmts.hasNext()) { Statement st = (Statement) stmts.next(); if (st == q_st) { //increase the consistency# for this case } else { //do nothing } System.out.println(stmts.next()); } Case = <Problem, Solution>

  44. Ideas on RDF representation and integration with IUCBRF • Any suggestions and/or comments? • Thanks.

More Related