Ecore Model Reflection in RDF
Upcoming SlideShare
Loading in...5

Ecore Model Reflection in RDF



Persist Ecore models to RDF, or use Active Objects and Reflection to hold active object state in RDF. These slides were presented as a lightning talk at Code Generation 2013 <http: />.

Persist Ecore models to RDF, or use Active Objects and Reflection to hold active object state in RDF. These slides were presented as a lightning talk at Code Generation 2013 <http: />.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Resources have (absolute) URIs or may be anonymous.Literals (represented by rectangles) may be untyped, use XSD datatypes, or may use custom datatypes (e.g. for enumerated types).
  • Resource-Orientationrecasts the code-centric notion of object-orientation to an inter-linked network of web-resources.It is an architectural style for developing software in the form of resources with RESTful interfaces.
  • In genmodel, set Root Extends Class, and FeatureDelegation to ‘Reflective’.
  • SPARQL,pronounced "sparkle", is a recursive acronym for SPARQL Protocol and RDF Query Language.The result is returned programmatically as a relation, or as JSON via the web.

Ecore Model Reflection in RDF Ecore Model Reflection in RDF Presentation Transcript

  • Model Reflection in RDF Steve Battle @stevebattle
  • Introduction • Based at the Bristol and Bath Science Park. • Aerospace and Advanced Manufacturing. • Model Driven Architecture and Development. Successes : • DSL based service configuration • Model Driven Architecture Evaluation • Model Driven 3D Printing • Linked Data and Ontology
  • Purchase-Order MetaModel Sharing of models between applications is hard: • Code dependency. • Wrong level of modularization for Services. • Alternative Views.
  • Resource Description RDF : Resource Description Framework <> • URIs name resources • Share data not objects • Self-describing (schema-less)
  • Resource vs. Object Orientation public interface PurchaseOrder extends EObject { String getShipTo(); void setShipTo(String value); String getBillTo(); void setBillTo(String value); EList<Item> getItems(); } External view • Model reflection in RDF • Shared ontology in OWL • Loose coupling • Resource Orientation Internal view • System model • Code Generation • Object Orientation Model Driven • Ecore Meta-Model • Architecture Evaluation
  • Persistence and Reflection • Ecore Persistence framework – ResourceSet supplies the base URI e.g. – RDF Resource defines a hash URI e.g. – Benefit : Exchange objects by URI reference • Active Objects and Reflection – RDF EStore holds active object state in RDF model – Generated classes use reflective methods eGet(),eSet(), … – Generated implementations extend custom EStoreEObjectImpl – Benefit : Lazy object construction resolves URIs on demand
  • SPARQL Query • Query across models (aspect orientation?) • Expose models as linked-data PREFIX po: <> PREFIX rdfs: <> SELECT * WHERE { ?po a po:PurchaseOrder ; po:PurchaseOrder_billTo ?bill ; po:PurchaseOrder_items [ rdfs:member ?item ] . ?item a po:Item ; po:Item_quantity ?qty ; po:Item_price ?price . OPTIONAL { ?item po:Item_productName ?product } }
  • Summary • Comments, ideas, applications? Bristol & Bath Science Park, Dirac Crescent, Emerson's Green, Bristol.