The RPI/TWC semantic development methodology re-dux: Use cases, and beyond January 18, 2012 USGS,...

The RPI/TWC semantic development methodology re-dux:

Use cases, and beyond

January 18, 2012

USGS, St. Petersburg, FLPeter Fox (RPI* and WHOI**) [email protected] and OTHERS!!*Tetherless World Constellation, ** AOP&E

Modern informatics enables a new scale-free** framework approach

• Use cases• Stakeholders• Distributed

authority• Access control• Ontologies• Maintaining

Identity

Systems v. Frameworks

• Rough definitions– Systems have very well-define entry and

exit points. A user tends to know when they are using one. Options for extensions are limited and usually require engineering

– Frameworks have many entry and use points. A user often does not know when they are using one. Extension points are part of the design

– Platforms are built on frameworks

Tetherless World Constellation3

Developed for NASA TIWG

Team: Roles and skill-sets needed

• Facilitator *** (usual key skills, knows method)• Domain experts (literate, knows resources; data,

applications, tools, etc.)• Modelers (to extract concepts, etc.)• Software engineers (architecture, technology)• Scribe (to write everything down)• The social aspect is key - it is a team effort

• So, how did it go?

Analysis

Use Cases Expose System Requirements

• Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts

• And … semantics, terms, concepts and their relations

Goal of Analysis

• Get the team a shared understanding of who is in the use case, what they do and interact with, and what the stages of the use case, and relations are

• To get an informal visual representation of the use case that begins to sync up with the written material

• The order in which to do this is dependent on the team

Data-Information-Knowledge Ecosystem

10

Data Information Knowledge

Producers Consumers

Context

PresentationOrganization

IntegrationConversation

CreationGathering

Experience

Curators

Information Modeling

• Conceptual

• Logical

• Physical

11

Information Models

• Conceptual models, sometimes called domain models, are typically used to explore domain concepts and often created – as part of initial requirements envisioning efforts

as they are used to explore the high-level static business or science or medicine structures and concepts

– as the precursor to logical models or as alternatives to them

• Followed by logical and physical models

12

Object oriented design

• Object-oriented modeling is a formal way of representing something in the real world (draws from traditional set theory and classification theory). Some basics to keep in mind in object-oriented modeling are that:– Instances are things.– Properties are attributes.– Relationships are pairs of attributes.– Classes are types of things.– Subclasses are subtypes of things.

13

Logical models

• A logical entity-relationship model is provable in the mathematics of data science. Given the current predominance of relational databases, logical models generally conform to relational theory.

• Thus a logical model contains only fully normalized entities. Some of these may represent logical domains rather than potential physical tables.

14

Logical models

• For a logical data model to be normalized, it must include the full population of attributes to be implemented and those attributes must be defined in terms of their domains or logical data types (e.g., character, number, date, picture, etc.).

• A logical data model requires a complete scheme of identifiers or candidate keys for unique identification of each occurrence in every entity

15

Physical models

• A physical model is a single logical model instantiated in a specific information system (e.g., relational database, RDF/XML document, etc.) in a specific installation.

• The physical model specifies implementation details which may be features of a particular product or version, as well as configuration choices for that instance.

16

Conceptual model example

• Radiative process model after a volcanic eruption

17

Logical model example

18

Physical model example

• NB – does not correspond to two previous models!

19

For example for relational DBs

20

Feature Conceptual Logical PhysicalEntity Names ✓ ✓ Entity Relationships ✓ ✓ Attributes ✓ Primary Keys ✓ ✓Foreign Keys ✓ ✓Table Names ✓Column Names ✓Column Data Types ✓

One more example

21

Physical Information Models

• PIMs are used to – design the internal schema (e.g. of a database, or

file), – depict the structured information (e.g. tables), – specify the layout of those structures (e.g.

columns of those tables)– specify the relationships between the structures

(e.g. primary keys).

23

Steps in modeling

• Identify entity types

• Identify attributes

• Apply naming conventions

• Identify relationships

• Apply model patterns

• Assign relationships

• Normalize to reduce redundancy (this is called refactoring in software engineering)**

• Denormalize to improve performance**

24

Not just an isolated set of models

• Handle errors, evolution, …• To the physical model?• To the logical model?• To the conceptual model?

• Relating to and/ or integrating with other information models?– General rule – integrate at the highest level you

can (i.e. more abstract)– Remember the cognitive aspects! (detail)

25

Tools for modeling..

• Concept mapping - http://cmap.ihmc.us/

• Models - http://www.datamodel.org/

– MSDN: http://msdn.microsoft.com/en-us/library/bb399249.aspx

• Schema– differs in basic concept from other schema languages– not based on grammars but on finding tree patterns in the

parsed document– approach allows many kinds of structures to be represented

which are inconvenient and difficult in grammar-based schema languages.

– http://www.schematron.com/ 26

More schema tools

• http://www.w3.org/XML/Schema

• http://www.stylusstudio.com/xml_schema.html

• http://download.cnet.com/SQL-Schema-Tool/3000-10254_4-10752603.html

27

Tools

• CMAP Ontology Editor (concept mapping tool from IHMC - http://cmap.ihmc.us/coe )– Drag/drop visual development of classes, subclass

and property relationship– Read and writes OWL– Formal convention (OWL/RDF tags, etc.)

• Mindmapping– http://en.wikipedia.org/wiki/

List_of_mind_mapping_software

• White board• Piece of paper … you get the idea…

29

Review

Evaluation

• Formative (more on this later)

These come later

• Implementation– Technology assessment– Leverage infrastructure– Rapid prototyping

• Evaluation

• Open world, iteration

Use case!

Use Case• … is a collection of possible sequences of

interactions between the system under discussion and its actors, relating to a particular goal.

• The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly.

• Any system behavior that is irrelevant to the actors should not be included in the use cases.– is a prose description of a system's behavior when

interacting with the outside world.– is a technique for capturing functional requirements of

business systems and, potentially, of an ICT system to support the business system.

– can also capture non-functional requirements

Use Case

• Must be documented (or it is useless)• Should be implemented (or it is not well

scoped)• Is used to identify: concepts ~ resources,

processes, roles (aka actors), relations, requirements, etc.

• Should iterate with your end-user on wording and details at least once


Use case format

• Use case name• Goal• Summary• Triggers• Basic flow• Alternate flow• Post conditions• Activity diagram• Preconditions in tabular form• Notes


Use case format?

• Short (in document) format for:– Exploratory phase of a project

where you want to collect a lot of use cases

– An example for others to use– Including in a proposal– For activities like this!

Scoping

• Focus initially on:• Core functionality• What it takes to implement the use case, resist

early generalizations• May (will) have to iterate on use case and

requirements

• Acknowledge other important issues such as:• Required vs. optional• Non-functional requirements• Available personnel (skills) and resources

Actors• The initial analysis will often have many

human actors• Begin to see where these can be replaced

with machine actors – may require additional encoding

• If you are doing this in a team, take steps to ensure that actors know their role and what inputs, outputs and preconditions are expected of them

• Often, you may be able to ‘run’ the use case (really the model) before you build anything

39


Actors

• Real people (round heads) and computers (block heads)

• E.g. Data provider, end-user, data manager, alert service

• Primary – initiate (act on)• Secondary – respond (acted upon)


What’s a pre-condition?

• defines all the conditions that must be true (i.e., describes the state of the system) for the trigger to meaningfully cause the initiation of the use case.

Preconditions

• Often the preconditions are very syntactic and you may not understand how they fit in the implementation

• Some level of modeling of these preconditions may be required (often this will not be in your first pass encoding which focuses on the main process flow, goal, description, etc.)

• Beware of using another entities data and services: policies, access rights, registration, and ‘cost’

42


Preconditions - data/model


Preconditions - event/application


Post-condition?

• describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.


Success scenarios

• A re-statement of how the use case via its flows and actors and resources results in achieving the result

• Describe artifacts produced

• Describe impacts and metric values


Failure scenarios

• A statement of how the use case via its flows and actors and resources did not result in achieving the result

• Describe role of actors in failure

• Describe role of resources in failure

• Describe what artifacts were and were not produced

• Describe impacts of failure and any metric values


Normal (process) flows

• A basis step of (usually) distinct steps that result when the use case is triggers (commences)

• Steps are often separated by actor intervention or represent modular parts of the flow (can encapsulate activities)

• Can have loops

• Should end with the final goal achieved

Process flow• Each element in the process flow usually denotes

a distinct stage in what will need to be implemented

• Often, actors mediate the process flow• Consider the activity diagram (and often a state

diagram) as a means to turn the written process flow into a visual one that your experts can review

• Make sure the artifacts and services have an entry in the resources section

• This is often the time you may do some searching (no, not soul searching – web searching…)

49


Alternate (process) flows

• Variations from the main flow, often invoked by valid but non-usual (or rules)

• Activity diagrams are useful in representing this part of the document

• Do not usually represent exceptions/ error flows

• Can often help to identify general patterns in the use case via similarities with the normal flow

• While many are possible, usually only include one - illustrative


Non-Functional requirements

• (from Wikipedia): Non-functional requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

• This should be contrasted with functional requirements that specify specific behavior or functions.

• In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.


Functional/ non-functional

• (from Wikipedia): Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements".

• Qualities, (non-functional requirements), can be divided into two main categories.– Execution qualities, such as security and usability, are

observable at run time.– Evolution qualities, such as testability, maintainability,

extensibility and scalability, are embodied in the static structure of the software system.

Artifacts

• Add artifacts that the use case generates to the resources list in the table

• It is often useful to record which artifacts are critical and which are of secondary importance

• Be thinking of provenance and the way these were produced, i.e. what went into them and produce suitable metadata or annotations

• Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution)

53


Resources• http://alistair.cockburn.us/index.php/Use_cases,_ten_years_later• http://www.digilife.be/quickreferences/pt/functional%20requirements

%20and%20use%20cases.pdf• http://alistair.cockburn.us/index.php/

Resources_for_writing_use_cases• http://alistair.cockburn.us/Usecasesintheoryandpractice180.ppt• http://alistair.cockburn.us/Agileusecases1dy.ppt• http://alistair.cockburn.us/index.php/

Structuring_use_cases_with_goals• http://www.foruse.com/publications/bibliographies/usecases.htm• http://en.wikipedia.org/wiki/Use_case• http://www.ddj.com/dept/architect/184414701

• Omnigraffle (Mac) www.omnigroup.com/applications/omnigraffle/ or

• Cmap http://cmap.ihmc.us/coe

Questions?

Tomorrow

• Breakouts to work on use cases– Use case scoping and refactoring– Completing / reviewing diagrams– Analysis and information modeling

• Review use cases

57

Semantic Web Methodology and Technology Development Process

• Establish and improve a well-defined methodology vision for Semantic Technology based application development

• Leverage controlled vocabularies, et c.

Use Case

Small Team, mixed skills

Analysis

Adopt Technology Approach

Leverage Technology Infrastructur

e

Rapid PrototypeOpen World:

Evolve, Iterate, Redesign, Redeploy

Use Tools

Science/Expert Review & Iteration

Develop model/

ontology

EvaluationEvaluation

References

• Twidale, Randall and Bentley (1994) and references therein

• Scriven (1991, 1996)

• Weston, Mc Alpine, and Bordonaro, (1995)

• Worthen, Sanders, and Fitzpatrick, (1997)

58

Inventory

• What categories can you measure?– Users– Files– Databases– Catalogs– Existing UI capabilities (or lack thereof)– Services– Ontologies

• In the stage of use case development is a very good time to capture these elements; do not guess, get them from quantitative sources or the users/ actors

59

Metrics

• Things you can measure (numerical)

• Things that are categorical– Could not do before– Faster, more complete, less mistakes, etc.– Wider range of users

• Measure or estimate the baseline before you start

60

Result/ outcome

• Refer to the use case document

• Outcome (and value of it) is a combination of data gathering processes, including surveys, interviews, focus groups, document analysis and observations that will yield both qualitative and quantitative results.

• Did you meet the goal?

• Just listen… do not defend … if you start to then: QTIP – quit taking it personally

61

Example: what we wanted to know about VSTO

• Evaluation questions are used to determine the degree to which the VSTO enhanced search, access, and use of data for scientific and educational needs and effectively utilized and implemented a template for user-centric utilization of the semantic web methodology.

• VO – appears to local and integrated and in the end-users language (this is one of the metrics)

62

Evaluation (Twidale et al.)

• An assessment of the overall effectiveness of a piece of software, ideally yielding a numeric measure by which informed cost-benefit analysis of purchasing decisions can be made.

• An assessment of the degree to which the software fulfils its specification in terms of functionality, speed, size or whatever measures were pre-specified.

63

Evaluation

• An assessment of whether the software fulfils the purpose for which it was intended.

• An assessment of whether the ideas embodied in the software have been proved to be superior to an alternative, where that alternative is frequently the traditional solution to the problem addressed.

• An assessment of whether the money allocated to a research project has been productively used, yielding useful generalizeable results.

64

Evaluation

• An assessment of whether the software proves acceptable to the intended end-users.

• An assessment of whether end-users continue to use it in their normal work.

• An assessment of where the software fails to perform as desired or as is now seen to be desirable.

• An assessment of the relative importance of the inadequacies of the software.

65

(Orthogonal) Dimensions of evaluations

Structured Less structured

Quantitative Qualitative

Summative Formative

Controlled experiments Ethnographic observations

Formal and rigorous Informal and opportunistic

66

Formative and Summative

• evaluation carried out for two reasons:– grading translations = summative evaluation– giving feedback = formative evaluation

67

Formative and Summative

68

Evaluation questions and associated data collection methods

Evaluation questions: To what extent does VSTO’s

Interviews/ Focus Group

Surveys Document Analysis

Observation

Activities enhance end-user access to and use of data to advance science and education needs?

X X X X

Activities enable higher levels of semantic capability and interoperability such as explanation, reasoning on rules, and semantic query?

X X X X

Contribute to the development and support of community resources, virtual observatories and data systems /provision of results from diverse observing systems using semantically-enabled technologies?

X X X X

69


Evaluation questions: To what extent does X’s

Interviews/ Focus Group


Observation

Template contribute to the reports on modern data frameworks, user interfaces, and science progress achieved?

X X X X

Incorporate user experiences in the redesign and development cycles of the VSTO?

X X X X

70


Evaluation questions: Interviews/ Focus Group


Observation

How do VSTO activities a ect IHE faculty and sta ff fffrom participating institutions (e.g., changes to virtual observatories) and data sources, results from diverse observing systems using sematically-enabled technologies and institutional collaboration activities?

X X X X

What factors impede or facilitate progress toward VSTO goals?

X X

What progress has been made toward sustaining and ‘scaling up’ VSTO activities?

X X X

71

Implementing an evaluation

• Based on our experience with use case development and refinement, community engagement, and ontology vetting, a workshop format (6 up to 25 participants, depending on desired outcomes and scope) is a very effective mechanism to make rapid progress.

• The workshops can be part of a larger meeting, stand-alone or partly virtual (via remote telecommunication).

• We have found (for example, in our data integration work) that domain experts in particular are extremely willing to participate in these workshops.

72

Implementing

• Let’s take an example– VSTO– Representative but does not exercise all

semantic web capabilities

73

VSTO qualitative results

• Decreased input requirements: The previous system required the user to provide 8 pieces of input data to generate a query and our system requires 3. Additionally, the three choices are constrained by value restrictions propagated by the reasoning engine. Thus, we have made the workflow more efficient and reduced errors.

74


• Syntactic query support: The interface generates only syntactically correct queries. The previous interface allowed users to edit the query directly, thus providing multiple opportunities for syntactic errors in the query formation stage. As one user put it: “I used to do one query, get the data and then alter the URL in a way I thought would get me similar data but I rarely succeeded, now I can quickly re-generate the query for new data and always get what I intended”.

75


• Semantic query support: By using background ontologies and a reasoner, our application has the opportunity to only expose query options that will not generate incoherent queries. Additionally, the interface only exposes options for example in date ranges for which data actually exists. This semantic support did not exist in the previous system. In fact we limited functionality in the old interface to minimize the chances of misleading or semantically incorrect query construction.

76


• Semantic query support: for example, that a user has increased functionality – i.e., they can now initiate a query by selecting a class of parameter(s). As the query progresses, the sub-classes and/or specific instances of that parameter class are available as the datasets are identified later in the query process.

77


• Semantic query support: We removed the parameter initiated search in the previous system because only the parameter instances could be chosen (8 different instances to represent neutral temperature, 18 representations of time, etc.) and it was too easy for the wrong one to be chosen, quickly leading to a dead-end query and frustrated user. One user with more than 5 years of CEDAR system experience noted: “Ah, at last, I’ve always wanted to be able to search this way and the way you’ve done it makes so much sense”.

78


• Semantic integration: Users now depend on the ontologies rather than themselves to know the nuances of the terminologies used in varying data collections. Perhaps more importantly, they also can access information about how data was collected including the operating modes of the instruments used. “The fact that plots come along with the data query is really nice, and that when I selected the data it comes with the correct time parameter” (New graduate student, ~ 1 year of use).

79


• Semantic integration: The nature of the encoding of time for different instruments means that not only are there 18 different parameter representations but those parameters are sometimes recorded in the prologue entries of the data records, sometimes in the header of the data entry (i.e. as metadata) and sometimes as entries in the data tables themselves. Users had to remember (and maintain codes) to account for numerous combinations. The semantic mediation now provides the level of sensible data integration required.

80


• Broader range of potential users: VSTO is usable by people who do not have PhD level expertise in all of the domain science areas, thus supporting efforts including interdisciplinary research. The user population consists of: Student (under-graduate, graduate) and non-student (instrument PI, scientists, data managers, professional research associates).

81

VSTO quantitative results

• Broader range of potential users: For CEDAR, students: 168, non-students: 337, for MLSO, students: 50, non-students: 250. In addition 36% and 25% of the users are non-US based (CEDAR – a 57% increase over the last year - and MLSO respectively). The relative percentage of students has increased by ~10% for both groups.

82

Adoption (circa 2007)

• Currently there are on average between 80-90 distinct users authenticated via the portal and issuing 400-450 data requests per day, resulting in data access volumes of 100KB to 210MB per request.

• In the last year, 100 new users have registered, more than four times the number from the previous year.

• The users registered last year when the new portal was released, and after the primary community workshop at which the new VSTO system was presented.

• At that meeting, community agreement was given to transfer operations to the new system and move away from the existing one.

83

Facilitating new projects

• At the community workshop a priority-area was identified which involved the accuracy and consistency of temperature measurements determined from instruments like the Fabry-Perot Interferometer. As a result, we have saw a 44% increase in data requests in that area. We increased the granularity in the related portion of the ontology to facilitate this study.

84

Facilitating new projects

• We focused on improving a users’ ability to find related or supportive data, with which to evaluate the neutral temperatures under investigation. We are seeing an increase (10%) in other neutral temperature data accesses, which we believe is a result of this related need.

85

Informal evaluation

• We conducted an informal user study asking three questions: What do you like about the new searching interface? Are you finding the data you need? What is the single biggest difference? Users were already changing the way they search for and access data. Anecdotal evidence indicated that users are starting to think at the science level of queries, rather than at the former syntactic level.

86

Informal evaluation

• For example, instead of telling a student to enter a particular instrument and date/time range and see what they get, they are able to explore physical quantities of interest at relevant epochs where these quantities go to extreme values, such as auroral brightness at a time of high solar activity (which leads to spectacular auroral phenomena). This suggested to us some new use cases to support even greater semantic mediation

87

Further measuring

• One measure that we hoped to achieve is to have usage by all levels of domain scientist – from the PI to the early level graduate student. Anecdotal evidence shows this is happening and self classification also confirms the distribution. A scientist doing model/observational comparisons: noted “took me two passes now, I get it right away”, “nice to have quarter of the options”, and “I am getting closer to 1 query to 1 data retrieval, that’s nice”.

88

Focus group

• A one hour workshop was held at the annual community meeting on the day after the main plenary presentation for VSTO. The workshop was very well attended with 35 diverse participants (25 were expected) ranging from a number senior researchers, junior researchers, post-doctoral fellows and students - including 3 that had just started in the field.

• After some self-introductions eight questions were posed and responses recorded, some by count (yes/no) or comment. Overall responses ranged from 5 to 35 per question.

89


• How do you like to search for data? Browse, type a query, visual? Responses: 10; Browse=7, Type=0, Visual=3.

• What other concepts are you interested in using for search, e.g. time of high solar activity, campaign, feature, phenomenon, others? Responses: 5; all of these, no others were suggested.

• Does the interface and its services deliver the functionality, speed, flexibility you require? Responses: 30; Yes=30, No=0.

90


• Are you finding the data you need? Responses: 35; Yes=34, No=1.

• How often do you use the interface in your normal work? Responses: 19; Daily=13, Monthly=4, Longer=2.

• Are there places where the interface/ services fail to perform as desired? Responses: 5; Yes=1, No=4.

91

Qualitative questions

• What do you like about the new searching interface? Responses: 9.

• What is the single biggest difference? Responses: 8.

• The general answers were as follows:– Less clicks to data (lots)– Auto identification and retrieval of independent

variables (lots)– Faster (lots)– Seems to converge faster (few)

92

Unsolicited/ unstructured comments

• It makes sense now!

• [I] Like the plotting.

• Finding instruments I never knew about.

• Descriptions are very handy.

• What else can you add?

• How about a python interface [to the services]?

93

Surprise! New use cases

• The need for a programming/ script level interface, i.e. building on the services interfaces; in Python, Perl, C, Ruby, Tcl, and 3 others.

• Addition of models alongside observational data, i.e. find data from observations/ models that are comparable and/or compatible.

• More services (particularly plotting options - e.g. coordinate transformation - that are hard to add without detailed knowledge of the data).

94

Keep in mind

• You need an evaluation plan that can lead to improvements in what you have built

• You need an evaluation to value what you have built

• You need an evaluation as part of a publication

95

Iterating

• Evolve, iterate, re-design, re-deploy– Small fixes– Full team must be briefed on the evaluation results

and implications– Decide what to do about the new use cases, or if the

goal is not met– Determine what knowledge engineering is required

and who will do it (often participants in the evaluation may become domain experts in your methodology)

– Determine what new knowledge representation– Assess need for an architectural re-design

96

Summary

• Project evaluation has many attributes• Structured and less-structured• Really need to be open to all forms• A good way to start is to get members of your

team to do peer evaluation• This is a professional exercise, treat it that

way at all times• Other possible techniques for moving forward

on evolving the design, what to focus upon, priorities, etc.: SWOT, Porter’s 5 forces

97

98

Semantic Web Methodology and Technology Development Process

• Establish and improve a well-defined methodology vision for Semantic Technology based application development

• Leverage controlled vocabularies, et c.

Use Case

Small Team, mixed skills

Analysis

Adopt Technology Approach

Leverage Technology

Infrastructure

Rapid PrototypeOpen World:

Evolve, Iterate, Redesign, Redeploy

Use Tools

Science/Expert Review & Iteration

Develop model/

ontology

EvaluationEvaluation

99

Implementation Basics

• Review your use case with team and experts• Go into detail of your ontology; test it using the

tools you have• We will look at the use case document and

examine the actors, process flow, artifacts, etc.• You will start to develop a design and an

architecture• Keep in mind that it is more flexible to place the

formal semantics within your interfaces, i.e. between layers and components in your architecture or between ‘users’ and ‘information’ to mediate the exchange

Actors

• The initial analysis will often have many human actors

• Look to see where the human actors can be replaced with machine actors – many will require additional semantics, i.e. knowledge encoding

• If you are doing this in a team, take steps to ensure that actors know their role and what inputs, outputs and preconditions are expected

• Often, you may be able to ‘run’ the use case (really the model) before you build anything

100

Process flow

• Each element in the process flow usually denotes a distinct stage in what will need to be implemented

• Often, actors mediate the process flow• Consider the activity diagram (and often a

state diagram) as a means to turn the written process flow into a visual one that your experts can review

• Make sure the artifacts and services have an entry in the resources section 101

Preconditions

• Often the preconditions are very syntactic and may not be ready to fit with your semantically-rich implementation

• Some level of modeling of these preconditions may be required (often this will not be in your first-pass knowledge encoding, which focuses on the main process flow, i.e. goal, description, etc.)

• Beware of using other entities data and services: e.g., policies, access rights, registration, and ‘cost’

102

Artifacts

• Add artifacts that the use case generates to the resources list in the table

• It is often useful to record which artifacts are critical and which are of secondary importance

• Be thinking of provenance and the way these artifacts were produced, i.e. what semantics went into them use this information to produce suitable metadata or annotations

• Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution) 103

Reviewing the resources

• Apart from the artifacts and actor resources, you may find gaps

• Your knowledge encoding is also a resource, make it a first class citizen, i.e. give it a namespace and a URI

• Often, a test-bed with local data is very useful at the start the implementation process, i.e. pull the data, maybe even implement their service (database, etc.)

104

Back to the knowledge encoding

• Declarative: in CL, OWL (probably OWL-DL), RDF, SKOS?

• Need rules?• Need query?

• Science expert review and iteration• Means you need something that they can

review, with precise names, properties, relations, etc.

• The knowledge engineering stage is much like a software engineering process

105

Knowledge engineering

• The interplay between tools like Protégé and CMAP will be very important in implementing a knowledge base that has ‘just enough’

106

Summary

• By now, the reality of going into complete detail for the knowledge representation should be apparent

• Keeping it simple is also very important as you begin to implement

• Being prepared to iterate is essential• Now is the time to validate your ontology with

domain experts and your team, use the tools• The next stage is to choose your technology

components and build and test 107

Back shed

Vision?

• “Our vision is to develop, facilitate, and maintain sustained multi-way engagement of natural and social (?) scientists and practitioners in multi-scale local to global networks” [for X]. – Organization is required so participants (3) can

carry out mission(s)– Those participants (by defn.) may never be in

a single organization -> virtual organization (1)

Goal (2)

• We want to perform X involving all (or as many) stakeholders and we want robust science data presented in forms that various end-users can consume…

• Or similar – a point of discussion – now or later (13)

(1) Virtual Organization

• Outcomes/ values (4)

• Dynamic versus static (5)

• Evolvable/ ecosystem-like (6)

• Heterogenetic tolerance (7)

• Attributes of the organization (8)

• Roles/ responsibilities (9)

• Scale (10) or scalability

Virtual organizations – many defn.

• ‘ …a geographically distributed organization whose members are bound by a long-term common interest or goal, and who communicate and coordinate their work through information technology’ (Ahuja)

Roles and relationships

• ‘These members assume well defined roles and status relationships within the context of the virtual group that may be independent of their role and status in the organization employing them’ (Ahuja et al., 1998).

Virtual organizations as Socio-Technical Systems

Technology

Communication Patterns

OrganizationalStructure

Communication patterns

A key feature of virtual organizations is a high degree of informal communication

Because of a lack of formal rules, procedures, clear reporting relationships, and norms, more extensive informal communication is required

Credit: B. Rouse (BEVO) 2008

Mapping

• (2) goal -> use case• (3) participation -> team(s), vetting,

acceptance• (4) outcomes/ vaue -> goals, metrics,

evaluation, incentives, data/information/ knowledge projects, responses, decisions

• (5) dynamic -> agile working format, small iterations

• (6) evolution -> rapid development, evaluation and iteration (open)

Mapping (ctd.)

• (7) heterogeneity -> information modeling approach

• (8) organizational attributes -> networks (10)• (9) roles/ responsibilities -> actors in the use

case

• Application of social-technical (and socio-ecological) understandings leads to an informatics methodology … but 1st….

(10) Scale(s)

• Multiple modes – spatial, temporal, discipline, etc.

• Scale-free networks– Citation networks– The Web– Semantic networks– Depend on super nodes (11)

• Semantic networks are ones where the nodes and relations are ‘named and typed’

Scale free?

(11) Super nodes

• People (you!)

• Organizations

• Computational infrastructure

• Data and information services

• Roles/ responsibilites and resulting delegation to the smaller nodes around the super nodes

• Ecosystems need diversity, many types

• SO … partnerships, coordination, networks, work, ongoing, etc.

(12) Stimulating the network

What about meaning?

• Sustained?

• Evolved?

Named and typed relationships

And more…

(13) Method

• We also get a lot of other stuff for ‘free’– Provenance (explanation…)– Extensibility– Application integration– Terminology mediation

• Usually at this stage, we start on …– Use case(s), including activity diagram– Information modeling– Evaluation and iteration

The RPI/TWC semantic development methodology re-dux: Use cases, and beyond January 18, 2012 USGS,...

Documents

Transcript of The RPI/TWC semantic development methodology re-dux: Use cases, and beyond January 18, 2012 USGS,...