desk ver 3 0
Download
Skip this Video
Download Presentation
DESK ver 3.0

Loading in 2 Seconds...

play fullscreen
1 / 37

DESK ver 3.0 - PowerPoint PPT Presentation


  • 54 Views
  • Uploaded on

DESK ver 3.0. José A. Macias and Pablo Castells. Once upon a “short” time ago. DESK. Differences Model. Context Model. XML. XML. Finding out Differences. Finding out Context. Changes Management. HTML. HTML modif. Domain Model. Presentation Model. User Model. HTML. PEGASUS.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' DESK ver 3.0' - sharne


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
desk ver 3 0

DESK ver 3.0

José A. Macias and Pablo Castells

once upon a short time ago
Once upon a “short” time ago...

DESK

Differences Model

Context Model

XML

XML

Finding out

Differences

Finding out

Context

Changes

Management

HTML

HTML

modif

Domain Model

Presentation Model

User Model

HTML

PEGASUS

Runtime System

Authorized User

desk client server architecture
DESK Client-Server Architecture

Inference

Engine

DESK Back-End

DESK

Navigational WEB Pages

XML

User Monitoring Model

WYSIWYG

Authoring Tool

DESK Front-End

desk front end
DESK Front-End
  • Client-Side Authoring Tool. Allows the Author to navigate and edit presentation coming from PEGASUS
  • WYSIWYG (or maybe a half WYSIWYG) Authoring Tool. It also includes:
    • A module for building conditions under User/Platform model.
    • A module for building iterative tasks under user conditions/data models.
  • Monitors and tracks the user during interaction. This way DESK Front-End creates a Monitoring Model from user actions.
slide5

XML

DESK Front-End

Tracking and analysing

User Actions

...

User

Action 1

User

Action 2

User

Action N

User

Action 3

Applying

Low Level Heuristics

Finding out Syntactic Context

HL

And

Constructor

Primitive N

Constructor

Primitive 1

Constructor

Primitive 2

Encapsulating into

Constructor Primitives

...

Monitoring Model

Containing Syntactic

Context

Monitoring Model

user actions
User Actions
  • WYSISYG Actions
    • Paste, Copy, Cut
    • Deletion, Insertion
    • Create table.
    • Create enumeration
    • Applying and Disabling Styles
      • Font Type, Font Size, Bold, Underlying, Italic, Headers: <H1>...<H6>
  • No WYSISYG Actions
    • Create model conditions under hypermedia elements
    • Create model iterations under hypermedia elements
low level heuristics h l finding out context
Low Level Heuristics (HL)(Finding out Context)
  • 1st Order Heuristics address the problem of finding out client-side context for any User Action to be later identified by DESK Server-Side.

Low Level Heuristics

Identifying Special

Structures

Client-Side Context

Location Module

Finding out Suitable Constructor Primitives

low level heuristics h l
Low Level Heuristics (HL)
  • Finding Syntactic Context for changes on HTML
    • Client-Side Context Location Module

¿Witch is the nearest context

for the “New Insertion”?

HTML

HTML

HTML

New Insertion

New Insertion

New Insertion

<Insert_Single_HTML>

New Insertion

<In_Context location=“after”>

Paragraph

</In_Context> ...

<Insert_Single_HTML>

New Insertion

<In_Context location=“before”>

Paragraph

</In_Context>...

<Insert_Single_HTML>

New Insertion

<In_Context starts=15

ends=40>

Paragraph

</In_Context>...

low level heuristics h l1
Low Level Heuristics (HL)
  • Identifying Special Structures

HTML

HTML

Creating a table:

<Create_Table

id=T1 ...>

<In_Context>...

Inserting HTML into a Table:

<Insert_Single_HTML>

Text

<In_Context table_id=“T1”

col_n=1

row_n=1>

Paragraph

</In_Context>...

Text

HTML

On Deletion:

<Delete_Table id=“T1”>

...

<Delete_List id=“E1”>

...

Creating a List:

<Create_List

id=E1 ...>

<In_Context>...

1)

2)

3)

low level heuristics h l2
Low Level Heuristics (HL)
  • Identifying Special Structures in No WYSISYG Actions

HTML

HTML

HTML under

Model Conditions:

<Condition

id=C1 ...>

User.Age=18

<HTML_Affected>

Parapraph

<HTML_Affected>

...

HTML Iteration:

<Iteration

id=I1 ...>

<list id=E1>

<HTML_Affected>

Parapraph

<HTML_Affected>

...

User.Age

=

18

Iteration from a

List of Elements

<UL...>

<li>...

</UL>

constructor primitives
Constructor Primitives
  • Used for translating User Actions+Syntactic Context Information” into XML, in order to represent the final Monitoring Model
    • WYSISYG Constructor Primitives
      • <Style>, <Font_Applied>, <Font_Size_Applied>, <Header_Style_Applied>
      • <Create_Table>, <Delete_Table>
      • <Create_List>, <Delete_List>
      • <Insert_Single_HTML>, <Insert_HTML_Into_Table>
      • <Remove_Single_HTML>,<Remove_HTML_From_Table>
    • No WYSISYG Constructor Primitives
      • <Condition>, <Iteration>
monitoring model
Monitoring Model

<?xml version="1.0" encoding="UTF-8"?>

<Monitoring_Model>

<Remove_Single_HTML ID="1">

<Text_Affected><![CDATA[<p>

DIJKSTRA (G, s)<br>INICIALIZAR (G, s)<br>Q = V[G]<br>while Q not empty do<br>

u = EXTRACT_MIN (Q)<br>for v in Ady[u] do<br>RELAX (G, u, v)

</p>]]></Text_Affected>

<In_Context start_text="0" end_text="120"><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></In_Context>

</Remove_Single_HTML >

<Insert_Single_HTML ID="2">

<Text_Affected><![CDATA[<p>

DIJKSTRA (G, s)<br>INICIALIZAR (G, s)<br>Q = V[G]<br>while Q not empty do<br>

u = EXTRACT_MIN (Q)<br>for v in Ady[u] do<br>RELAX (G, u, v)

</p>]]></Text_Affected>

<In_Context start_text="12" end_text="172"><![CDATA[Solo grafos dirigidos con peso no negativo.]]></In_Context>

</ Insert_Single_HTML >

< Insert_Single_HTML ID=”3">

<Text_Affected><![CDATA[<br>]]></Text_Affected>

<In_Context location="before" location_pos="2"><![CDATA[Procedure]]></In_Context>

</ Insert_Single_HTML >

monitoring model1
Monitoring Model

<Create_List ID=”4" nature="sorted" type="1" start="1">

<Text_Affected><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></Text_Affected>

<In_Context><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></In_Context>

<List_Items>

<Item-1><![CDATA[DIJKSTRA (G, s)]]></Item-1>

<Item-2><![CDATA[INICIALIZAR (G, s)]]></Item-2>

<Item-3><![CDATA[Q = V[G]]]></Item-3>

<Item-4><![CDATA[while Q not empty do]]></Item-4>

<Item-5><![CDATA[u = EXTRACT_MIN (Q)]]></Item-5>

<Item-6><![CDATA[for v in Ady[u] do]]></Item-6>

<Item-7><![CDATA[RELAX (G, u, v)]]></Item-7>

</List_Items>

</Crate_List>

<Style ID=”5" type="UNDERLINE" action="applied">

<Text_Affected><![CDATA[algoritmo]]></Text_Affected>

<In_Context start_text="15" end_text="24"><![CDATA[El titular del algoritmo es:]]></In_Context>

</Style>

</Monitoring_Model>

desk back end
DESK Back-End
  • DESK Server-Side. Receives DESK Front-End Monitoring Model and process such XML Model to perform changes on web presentation
  • The user sends automatically to DESK Server-Side the Monitoring Model by using DESK Client-Side browser, then the system performs all the changes reflected on Monitoring Model. The feed-back to author is a special web page informing about the changes summary and asking the designer (if needed) information about ambiguous changes. Furthermore, events and errors are reported to the designer as well.
desk back end1

XML

DESK Front-End

Desk Back-End

DESK Back-End

Monitoring Model

DESK

Summary Web Page

XML

Monitoring Model

from DESK Front-End

Applying

High Level Heuristics

HH

Finding out Semantic Context

Enriched Monitoring Model

(Initial Monitoring Model

+

Semantic Context Information)

Pegasus Models

XML

++

Updating

Models

Looking out for

Authorised User

Managing Changes

high level heuristics h h finding out semantic context

JSP

XML

High Level Heuristics (HH)(Finding out Semantic Context)
  • High Level Heuristics allows DESK Server-Side application to exactly find out where the changes will be located in Web Application Models. It uses information coming from Low Level Heuristics (<In_Context>)

High Level Heuristics

Server-Side Context Location Module

Disambiguation Module

Domain Model

Context Search

Presentation Model Context Search

Constructing

a Presentation

Model Map

Domain Object

Location

Free HTML Search

and Recognition

high level heuristics h h
High Level Heuristics (HH)
  • Server-Side Context Location Module
    • Domain Model Context Search

Processing change from Monitoring Model =>

Client-Side Context of changed is needed =>

Suppose the change is in Domain Model => but ...

What in the Web Application is going to be affected by the change?

Domain Model

Domain Model

Domain Model

<AtomicFragment>

DIJKSTRA (G, s) <BR>

INICIALIZAR (G, s) <BR>

Q = V[G] <BR>

while Q not empty do <BR>

u = EXTRACT_MIN (Q)

for v in Ady[u] do <BR>

RELAX (G, u, v)]]>

</AtomicFragment>

<Class name=

"Algorithm"

parent="Topic">

<Relation

name="procedure"

title="Procedure”

...

<Algorithm

ID="Dijkstra"

TITLE=

”Dijkstra\'s

Algorithm">

...

1

2

3

Attribute of a Domain Object

Attribute of a Relation Between Classes

HTML Fragment in the Domain

high level heuristics h h1
High Level Heuristics (HH)
  • Server-Side Context Location Module
    • Domain Model Context Search

1

<Context>

<Found_In>

<Class class_name=”Algorithm" id=“Dijkstra” attribute=“TITLE”/>

</Found_In>

</Context>

2

<Context>

<Found_In>

<Class class_name=”Algorithm" relation_name=“procedure” attribute=“tittle”/>

</Found_In>

</Context>

3

<Context>

<Found_In>

<Class class_name="AtomicFragment"

path="AtomicFragment,procedure,prerequisites,Algorithm,items,Course,Domain"/>

</Found_In>

</Context>

high level heuristics h h2
High Level Heuristics (HH)
  • Server-Side Context Location Module
    • Presentation Model Context Search
      • Based on a Explicit Representation of The Domain Object Information located in the Presentation Model (Presentation Model Map) that better allows for any change processed to be located in the Presentation Templates.

Presentation Model Map

Presentation Model

<Presentation_Model

class_name="Algorithm">

<Domain_Objects>

<Domain_Object name="algorithm"

from_domain_model_class="Algorithm" />

<Domain_Object name="prerequisites"

from_domain_model_relation=

"prerequisites" />

<Domain_Object name="procedure"

from_domain_model_relation=

"procedure" />

<Domain_Object name="proof"

from_domain_model_relation=

"proofOfCorrection" />

</Domain_Objects>

<h1> <%= title %> </h1>

}

<%= prerequisites.title () %>

<%= procedure.title () %>

<%= prerequisites.tree () %>

.......

presentation model map
Presentation Model Map

<?xml version="1.0" encoding="UTF-8"?>

<Presentation_Model class_name="Algorithm">

<Domain_Objects>

<Domain_Object name="algorithm" from_domain_model_class="Algorithm" />

<Domain_Object name="prerequisites" from_domain_model_relation="prerequisites" />

<Domain_Object name="procedure" from_domain_model_relation="procedure" />

<Domain_Object name="proof" from_domain_model_relation="proofOfCorrection" />

</Domain_Objects>

<Another_Objects>

<Another_Object name="title" type="String" from_class="Algorithm" from_attribute="TITLE" />

</Another_Objects>

<Domain_Objects_Appearing>

<Found object="prerequisites">

<Appearing><![CDATA[<%= prerequisites.title () %>]]></Appearing>

<Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found>

<Found object="procedure">

<Appearing><![CDATA[<%= procedure %>]]></Appearing> </Found>

<Found object="procedure">

<Appearing><![CDATA[<%= procedure.title () %>]]></Appearing>

<Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found>

<Found object="proof">

<Appearing><![CDATA[<%= proof %>]]></Appearing> </Found>

<Found object="proof">

<Appearing><![CDATA[<%= proof.title () %>]]></Appearing>

<Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found>

<Found object="title">

<Appearing><![CDATA[<%= title %>]]></Appearing>

<Surrounding_Tags><![CDATA[[<h2>]]]></Surrounding_Tags> </Found>

</Domain_Objects_Appearing>

</Presentation_Model>

high level heuristics h h3
High Level Heuristics (HH)
  • Server-Sidce Context Location Module
    • Presentation Model Context Search
      • Domain Object Location

Presentation Model Map is used in order to locate

domain object types and definition present in Presentation Template

...

<Found_In>

<Class class name=

"Algorithm"

relation_name =

"procedure"

attribute=“tittle” />

</Found_In>

...

<Appearing><![CDATA[<%= procedure.title () %>]]>

</Appearing>

DomainObject

procedure =

algorithm.getRelation ("procedure")

...

<Domain_Object name="procedure"

from_domain_model_relation="procedure" />

...

...

<Found object="procedure">

<Appearing><![CDATA[<%= procedure.title () %>]]>

</Appearing>

<Surrounding_Tags><![CDATA[[<h3>]]]>

</Surrounding_Tags> </Found>

<h3>

<%= procedure.title () %>

</h3>

...

Enriched Monitoring Model

Explicit Presentation Model

Presentation Model (Template “Algorithm”)

high level heuristics h h4
High Level Heuristics (HH)
  • Server-Side Context Location Module
    • Presentation Model Context Search
      • Domain Object Location
      • Free HTML Search and Recognition

Once Domain Objects have been located, DESK uses Client-Side Context

Information from Monitoring Model for applying changes. Free HTML

is located using advanced search algorithms and processed as well

<In_Context location=“before”>

...

<In_Context location=“after”>

...

<In_Context starts=15 ends=40>

...

Enriched Monitoring Model

Presentation Model (Template)

high level heuristics h h5
High Level Heuristics (HH)
  • Disambiguation Module

Aims at addressing the problem of changes involving multiple contexts

...

<Context>

<Found_in>

<Class class_name=”Algorithm" attribute=“tittle” />

<Class class_name="AtomicFragment"

path="AtomicFragment,procedure,prerequisites,Algorithm,

items,Course,Domain"/>

</Found_in>

<Real_Context>

<Class class_name=”Algorithm" attribute=“tittle” />

</Real_Context>

</Context>

...

Enriched Monitoring Model

high level heuristics h h6
High Level Heuristics (HH)
  • Disambiguation Module

If <Real_Context> exists => Automatic Disambiguation

else => User Interaction is needed

and nowadays
... and Nowadays...

DESK Server-Side

Monitoring Model

+

Context Model

XML

++

Finding out

Context

Changes

Management

(Enriched

Monitoring Model)

XML

Monitoring Model

HTML

HTML

Domain Model

Presentation Model

User Model

Authorized User

PEGASUS

DESK Front-End

Runtime System

improvements

Improvements

(September, October, 2002)

searching for disambiguation
Searching for Disambiguation
  • What dos it happen if we have a modification context like this?
    • This is the Dijkstra’s Algorithm
    • From : This is the <%=Title%>
  • Up to now DESK can not carry out this modification (i.e. Dijkstra’s Algorithm) by using usual searching an characterising algorithms
  • Solution:
    • Syntactic context in DESK Client-Side must codify block information as well as context-in-environment information.
      • We need: After (paragraph), before (paragraph) and into (paragraph together with start and end positions) at the same time, as well as word after (modification) and word before (modification) location
    • Now, the search-for-semantic algorithm located at DESK Server-Side must search as follow:
      • 1. Search the Domain Model for words before and after
        • This generates a list of occurrences (as Title attribute in Dijkstra Object_id and maybe several atomic fragments)
      • 2. Search the previously built on list for matching the related paragraph
        • This generates a more reduced and optimised list of, maybe, an only element location. If not => Ambiguity. DESK must ask the user for disambiguation. User’s previous answered questions will be taken into account for resolving similar ambiguous cases.
desk h desk history
DESK-H (DESK-History)
  • The main idea of DESK-H is to provide the user with a history of related modifications for any change made by user under DESK to be translate to any presentation language or template
    • Up to now, changes are applied to both Domain Model and Presentation Template.
    • Now, we only have to completely codify general purpose changes to Domain and a given (unknown) Presentation Model
desk h desk history ii
DESK-H (DESK-History) (II)
  • For providing such a DESK-History, we need:
    • Find out syntactic information about the changes at DESK Client-Side (as usual)
    • Find out semantics about previous syntactic information at DESK Server-Side (as usual)
    • Find out (Characterise) a Main Object of every change
      • The principal object witch modified object belongs to
        • This could be supplied by means of the URL or meta tag into HTML
      • The class of the previously mentioned object
        • This could be supplied by means of the URL or meta tag into HTML
      • The relation (path) from the Main Object to the current modified object
        • For carrying out this task, we need to locate the relationships of both modified object and context environment objects (by using after and before attributes), identifying the relationship with such objects belong to.
        • Sometimes this heuristic results ill-suite since there could be no context around the modified object (i.e. one only prerequisite in such a relation) => Ask the user for disambiguation
semantics at client side
Semantics at Client-Side
  • In the beginning, we claimed not to use any semantic at Client-Side. But nowadays we use semantics in Special Structures Module for identifying complex structures coming from Presentation dynamics and widget rendering.
    • From now onwards, we can assume that DESK either uses semantics or not for enhancing generality and transportability to another systems.
    • This way, DESK will try to find out semantics at Client-Side, but if not then it will attempt to find them out at Server-Side. Those semantics could be applied to all structures and block detection.
    • It is a fact that non-use of semantics increases ambiguity cases and makes worse the inference process results.
    • Anyway, we must provide a list of all cases that DESK can address in lack of semantics.
atomic changes between widgets
Atomic Changes between Widgets
  • Automated atomic changes between widgets
    • By means of a agent-inspired monitoring, providing the user with editing assistance.
      • Configurable by creating a behaviour XML configuration file (it might be present in DESK front-end browser / Client Software)
      • The agent search in the Monitoring Model for actions upon conditions codified in the above mentioned file.
    • Use of suitable windows for adding elements to widgets in edition time, by double clicking the given widget
      • A further range of actions to be controlled/inspected by the Agent.
    • Examples
      • Automated change from Table to Combo Box and List (Relationship)
      • Automated change from Combo Box to Table
      • Automated change from Table to Tree
agent s configuration
Agent’s Configuration

<Atomic_Changes precision_search_degree="10">

<widget type="Table" change_to="ComboBox&List">

<Condition action="Creation" to="ComboBox" />

<Condition action="Creation" to="List" />

<Condition action="Exists_Relation" from="Combo" to="List" />

<OR>

<Condition action="Guided_Insertion" from="Table"

to="ComboBox" min_items_to_inference="3" />

<Condition action="Copy_and_paste" from="Table"

to="ComboBox" min_items_to_inference="3" />

</OR>

<OR>

<Condition action="Guided_Insertion" from="Table" to="List"

items_to_inference="3" />

<Condition action="Copy_and_paste"_ from="Table" to="List"

min_items_to_inference="3" />

</OR>

</widget>

agent s configuration y ii
Agent’s Configuration (y II)

<widget type="ComboBox" change_to="Table">

<Condition action="Creation" to="Table" />

<OR>

<Condition action="Guided_Insertion" from="ComboBox" to="Table"

min_items_to_inference="3" />

<Condition action="Copy_and_paste" from="ComboBox" to="Table"

min_items_to_inference="3" />

</OR>

</widget>

<widget type="Table" change_to="Tree">

<Condition action="Creation" to="Table" />

<Condition action="="Exists_Relation" from="Table" to="Tree" />

<Condition action="Elements_moved_out" from="Table"

min_items_to_inference="3" />

<Condition action="Elements_automatically_sorted" to="Tree" />

</widget>

...

</Atomic_Changes>

syntax meaning
Syntax Meaning
  • min_items_to_inference
    • Min number of items to be inserted, moved, etc. until the assistance window to reach.
  • precision_search_degree
    • to search from bottom to up to 10 previous Monitoring Model’s primitive actions
  • Guided_Insertion
    • Elements inserted using pop-up add-element windows by double clicking the widget
  • OR
    • Almost one of the conditions has to be true. It could be omitted if there is only a condition inside the OR block.
  • Exists_Relation
    • It means that elements are related by an ontology-defined relationship
      • It could be detected by checking the meta-information attributes present in each HTML structure (Table, List, etc.) and copied to The Monitoring Model
dealing with ambiguities
Dealing with Ambiguities
  • The main idea is to codify generic possible ambiguities that can be appears during the inference process
    • What does it happens if there are more list elements than Table columns/rows?
    • If the first column has different attributes, Should the rest be copied to others cells?

<widget type="List" change_to="Table">

<Condition action="Creation" to="Table" />

<Condition action="Copy_and_paste" from="Table" to="List" />

<Ambiguity condition="Table.dim.N < List.items.size"

action="Table.add.columns(List.items.size-Table.dim.N)"

default="Ask_user_for(N) " />

<Ambiguity condition="Table.dim.M < List.items"

action=" Table.add.rows(List.items.size-Table.dim.M)"

default="Ask_user_for(M)" />

<Ambiguity condition="Table.cell.attributes.Differ"

action="Table.cell.copy.attributes"

default="Ask_User_for_Acknowledgement" />

</widget>

iteration patterns
Iteration Patterns
  • Transforming any kind of widget into another one (e.g. a Table) is not an easy task
    • How does DESK has to infer the table generation?
      • Depending on where the user makes copy-paste to
        • Different cases
          • linear column motion (always in the same column)
          • linear row motion (always in the same row)
      • DESK has to search the Monitoring Model for correspondences between insertion into table columns/rows.
      • For making the whole insertions by him-self, DESK has to detect IterationPatterns.
      • Such patterns could be either parametrical, or maybe could be pre-defined inside the authoring tool.
        • Check out for different examples, such as List=>Table, Tree=>Table, ComboBox=>Table, and so on.
ad