MWCSWiki - Recent changes [en]

OKMExperiment2

2009-11-19T22:44:51Z

Project planning:

New page

=Project planning=
# Display inline relationships (TB)
## Edit page
## View page
# Add properties to inline relationships (TB)
## JavaScript
## JSP
# JSP handler for JavaScript autopopulate Ajax call: filters Jesse's mode binding matches (CD)
# CreateRelationship handler for actions: filters Jesse's mode binding matches (CD)
# Remove menu bar (TB)
# Design Knowledgebase (SD/JZ)
# Add Knowledgebase (SD/JZ)
# Craft task list (SD/JZ)
# Deploy on multiple TC's/DB's (CD)
# Complete screencast (CD)
# Clean up links
## Make links more visible (CD)
## Remove links to relationships and self (TB)
# TEST THIS!

=Use cases we want to test=
==Viewing data==
# Locate/view object
## Starting point:
### From a page that links to the object (could click to it) are the links obvious?
### From an unrelated page (must search)
## Information given:
### When given exact name of object
### When given synonym/alias of object name President Lincoln
# Locate/view attribute value
## Object contents:
### For object with single role
### For object with multiple roles
## Information given:
### When given exact name of attribute
### When given synonym of attribute
# Locate/view relationships to/from an object
## Object contents:
### For object with single role
### For object with multiple roles
## Information given:
### When given exact name of action
### When given synonym of action
## Sided-ness:
### Objects on left side Who does Chris tease?
### Objects on right side Who teases Jesse? (do they fall into the trap?)
# Locate/view objects that have a particular role
# Locate/view connected information (user must browse links to find out answer) producers of albums that band X made

==Editing data==
# Add attribute value
## Add value for object that has the role
## Add value for object that has multiple roles (including the role)
## Add value for object that has other roles, but not the role (?) think about ordering (Jessica's pattern)
## Add value for object that has no roles (?)
# Create new attribute (and value)
## New attribute with ''unique'' HRN: btw, do attributes act the same way as relationships do, as far as figuring-out-duplicates go?
### Create attribute for object that has the role
### Create attribute for object that has multiple roles (including the role)
### Create attribute for object that has other roles, but not the role
### Create attribute for object that has no roles
## New attribute whose HRN already exists (for some other role):
### Create attribute for object that has the role
### Create attribute for object that has multiple roles (including the role)
### Create attribute for object that has other roles, but not the role
### Create attribute for object that has no roles
# Add relationship (for existing action) note no separate use case for duplicate/unique action HRNs, because system does it automatically anyway?
## Left-hand side:
### Object has the role
### Object has multiple roles (including the role)
### Object has other roles, but not the role
### Object has no roles
## Right-hand side:
### Object has the role
### Object has multiple roles (including the role)
### Object has other roles, but not the role
### Object has no roles
# Create new action (and relationship)
## New action with ''unique'' HRN:
### Left-hand side:
#### Object has the role
#### Object has multiple roles (including the role)
#### Object has other roles, but not the role
#### Object has no roles
### Right-hand side:
#### Object has the role
#### Object has multiple roles (including the role)
#### Object has other roles, but not the role
#### Object has no roles
## New action whose HRN exists (for some other role pair):
### Left-hand side:
#### Object has the role
#### Object has multiple roles (including the role)
#### Object has other roles, but not the role
#### Object has no roles
### Right-hand side:
#### Object has the role
#### Object has multiple roles (including the role)
#### Object has other roles, but not the role
#### Object has no roles
# <strike>Add role to object</strike> doesn't make sense on its own
# Create new role user should see need to create SoccerPlayer role, when they've seen FootballPlayer and BaseballPlayer does it make sense to have "plays" predicate and also "SoccerPlayer" role?
# Create new object
## HRN:
### New object with ''unique'' HRN
### New object whose HRN exists for some other object
## Process:
### User is explicitly told they must create a new object
### User must discover that the object in question does not already exist

=Domain thoughts=
* Multiple singers in a band, and multiple bands on a "mix" CD; question: who are all the singers who sing on this CD...do they fall into the trap of only checking the band whose page they're on?
* Bernie Williams: plays baseball and plays guitar

Schedule for Projects

2009-11-17T17:39:49Z

Prototype 11/10/09 and 11/12/09:

← Older revision		Revision as of 17:39, 17 November 2009
(One intermediate revision not shown)

OKMDomainChanges

2009-11-17T00:31:22Z

← Older revision		Revision as of 00:31, 17 November 2009
Line 40:		Line 40:
	SELECT ?binding WHERE {		SELECT ?binding WHERE {
	?binding rdfs:domain <leftMode.getClassUri()> .		?binding rdfs:domain <leftMode.getClassUri()> .
		+	?binding rdfs:subProperty ?action
		+	?action label ?hrn .
		+	FILTER ( ?hrn = "actionName" ) .
		+	}
		+
		+	Or maybe using HRNs for the Mode as well, such as:
		+
		+	SELECT ?binding WHERE {
		+	?binding rdfs:domain ?leftModeClass .
		+	{
		+	?leftModeClass rdfs:label ?leftModeLabel
		+	} UNION {
		+	?leftModeAction definesClass ?leftModeClass .
		+	?leftModeAction rdfs:label ?leftModeLabel .
		+	}
		+	FILTER regex(?leftModeLabel, "^leftModeName") .
	?binding rdfs:subProperty ?action		?binding rdfs:subProperty ?action
	?action label ?hrn .		?action label ?hrn .
	FILTER ( ?hrn = "actionName" ) .		FILTER ( ?hrn = "actionName" ) .
	}		}

Schedule for Projects

2009-11-16T22:52:07Z

Prototype 11/10/09 and 11/12/09:

← Older revision		Revision as of 22:52, 16 November 2009
Line 24:		Line 24:
	[http://paprika.umw.edu/~swilless/cpsc448/drupal-6.14/ ]		[http://paprika.umw.edu/~swilless/cpsc448/drupal-6.14/ ]
	[http://paprika.umw.edu/~mgoodrea/drupal-6.14/ ]		[http://paprika.umw.edu/~mgoodrea/drupal-6.14/ ]
-	*Matt J	+	*[http://paprika.umw.edu/~mjones2/drupal/drupal-6.14/ Matt J]
	*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]		*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]
	*Jonathan [http://paprika.umw.edu/~jmori2ow/448/ArtistsTop10]		*Jonathan [http://paprika.umw.edu/~jmori2ow/448/ArtistsTop10]

Schedule for Projects

2009-11-16T18:06:10Z

← Older revision		Revision as of 18:06, 16 November 2009
Line 21:		Line 21:

	*[http://paprika.umw.edu/~saylor/448/drupal/ Stacey]		*[http://paprika.umw.edu/~saylor/448/drupal/ Stacey]
-	*Sean & Matt G	+	*Sean & Matt G
		+	[http://paprika.umw.edu/~swilless/cpsc448/drupal-6.14/ ]
		+	[http://paprika.umw.edu/~mgoodrea/drupal-6.14/ ]
	*Matt J		*Matt J
	*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]		*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]

User:Swilless

2009-11-16T18:04:19Z

New user account

New page

Schedule for Projects

2009-11-16T16:10:28Z

← Older revision		Revision as of 16:10, 16 November 2009
Line 24:		Line 24:
	*Matt J		*Matt J
	*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]		*Lucy [http://paprika.umw.edu/~lbain/448/drupal/drupal-6.14/]
-	*Jonathan	+	*Jonathan [http://paprika.umw.edu/~jmori2ow/448/ArtistsTop10]

	==Beta==		==Beta==
	11/24/09		11/24/09

Schedule for Projects

2009-11-16T15:19:12Z

← Older revision		Revision as of 15:19, 16 November 2009
Line 14:		Line 14:
	*Kim [http://paprika.umw.edu/~kslay1yv/drupal-6.14]		*Kim [http://paprika.umw.edu/~kslay1yv/drupal-6.14]
	*[http://rosemary.umw.edu/~lforney/segfault Lauren & Kurt]		*[http://rosemary.umw.edu/~lforney/segfault Lauren & Kurt]
-	*Will	+	*[http://rosemary.umw.edu/~wboyd/db/designbuild/home.php Will]
	*Damon [http://paprika.umw.edu/~dande8mh/drupal-6.14]		*Damon [http://paprika.umw.edu/~dande8mh/drupal-6.14]

OKMDomainChanges

2009-11-13T20:53:33Z

← Older revision		Revision as of 20:53, 13 November 2009
Line 42:		Line 42:
	?binding rdfs:subProperty ?action		?binding rdfs:subProperty ?action
	?action label ?hrn .		?action label ?hrn .
-	FILTER { ?hrn = "actionName" } .	+	FILTER ( ?hrn = "actionName" ) .
	}		}

OKM

2009-11-13T20:09:34Z

Where is OKM?:

← Older revision		Revision as of 20:09, 13 November 2009
Line 39:		Line 39:
	*# Begin to implement [[OKMImport\|import procedure]] (later in fall)		*# Begin to implement [[OKMImport\|import procedure]] (later in fall)
	* Stacey		* Stacey
-	*# Research JavaScript toolkits (including Prototype and Ext/JS) and figure out which one(s) can do the kind of icons-on-a-canvas-connected-by-lines stuff that we need to do	+	*# <strike> Research JavaScript toolkits (including Prototype and Ext/JS) and figure out which one(s) can do the kind of icons-on-a-canvas-connected-by-lines stuff that we need to do </strike>
	*# Download (http://www.imdb.com/interfaces#plain) and import (from IMDB) other movie attributes that we can have the user operate on during analysis. I'm thinking some nominal ones (studio, producer, writer, director) and numeric ones (year, gross earnings, production cost).		*# Download (http://www.imdb.com/interfaces#plain) and import (from IMDB) other movie attributes that we can have the user operate on during analysis. I'm thinking some nominal ones (studio, producer, writer, director) and numeric ones (year, gross earnings, production cost).
-	*# Download and install Firebug. Also, look at jslint.org: it is an extremely useful tool in javascript debugging.	+	*# <strike> Download and install Firebug. Also, look at jslint.org: it is an extremely useful tool in javascript debugging. </strike>
	* Jessica		* Jessica
	*# <strike>Write email to KR conference</strike>		*# <strike>Write email to KR conference</strike>

OKMDomainChanges

2009-11-13T19:45:21Z

← Older revision		Revision as of 19:45, 13 November 2009
(One intermediate revision not shown)
Line 23:		Line 23:

	Every Concept has a URI ending in something like "type#id," like "http://rosemary.umw.edu/okmobject#123." An OkmObject corresponds to a general resource. Fields and Actions correspond to properties. OkmModes correspond to classes. Each ModeBinding identifies a particular combination of class:predicate:class, and corresponds to a subproperty of the Action's property, whose domain is the left Mode and whose range is the right Mode. The two types of OkmMode handle this differently: a Role corresponds directly to a class, but an Action already corresponds to a property. Therefore, every Action also defines a resource representing the class of relationships involving that Action's property. To get an OkmMode's class's URI, use getClassUri. Fields correspond to properties, with the OkmMode's class as the domain. Relationships and FieldValues correspond to statements, which can be asserted or denied.		Every Concept has a URI ending in something like "type#id," like "http://rosemary.umw.edu/okmobject#123." An OkmObject corresponds to a general resource. Fields and Actions correspond to properties. OkmModes correspond to classes. Each ModeBinding identifies a particular combination of class:predicate:class, and corresponds to a subproperty of the Action's property, whose domain is the left Mode and whose range is the right Mode. The two types of OkmMode handle this differently: a Role corresponds directly to a class, but an Action already corresponds to a property. Therefore, every Action also defines a resource representing the class of relationships involving that Action's property. To get an OkmMode's class's URI, use getClassUri. Fields correspond to properties, with the OkmMode's class as the domain. Relationships and FieldValues correspond to statements, which can be asserted or denied.
		+
		+
		+	'''Process for HRN/URI Reasoning'''
		+
		+	In order to implement automatic resolution of which URI is meant, the system needs to handle the following cases:
		+	# The user clicks "Add property" outside of any Role, then enters an action, then an object.
		+	# The user clicks "Add property" inside of a Role, then enters an action, then an object.
		+	# The user clicks "Add property" inside of a Role, then swaps, then enters an action, then an object.
		+	# The user clicks "Add property" inside of a Relationship, then enters an action, then an object.
		+
		+
		+	So what we're going to do is create ModeBindingStore, which lets us look up a ModeBinding via URI OR given a partial match. For example, ModeBindingStore.instance().get(OkmMode leftMode, String actionName) will return a list of ModeBindings defined for the left mode and any Action with the given HRN.
		+
		+	This will be accomplished using a persistence class Reasoner which will be able to convert these requests into SPARQL queries, such as:
		+
		+	SELECT ?binding WHERE {
		+	?binding rdfs:domain <leftMode.getClassUri()> .
		+	?binding rdfs:subProperty ?action
		+	?action label ?hrn .
		+	FILTER { ?hrn = "actionName" } .
		+	}

OKMInterface

2009-11-13T18:25:16Z

← Older revision		Revision as of 18:25, 13 November 2009
Line 9:		Line 9:

	[[OKMImport\|Import]]		[[OKMImport\|Import]]
-
-	~~[[Current_Okm_domain_model\|Class Diagram]]~~

	[[OKMDomainChanges\|Current Domain]]		[[OKMDomainChanges\|Current Domain]]
-
-
-	~~[[Current_Okm_domain_model\|Class Diagram]]~~

OKMDomainChanges

2009-11-13T18:24:52Z

New page

[[OKMInterface|Back]]

[http://rosemary.umw.edu/~jhatfiel/okm/doc javadoc]

[[Image:Domain_v22.png]]

'''Brief overview of OKM domain model and persistence as of 12/13/09'''

A Concept is an object with a name and URI. It essentially represents a resource in the Semantic Web. Subclasses are Field, FieldValue, ModeBinding, OkmMode, OkmObject, Relatable, and User. A ConceptStore provides a way to access a given type of Concept. Subclasses are ActionStore, FieldValueStore, OkmObjectStore, RelationshipStore, RolePlayerStore, RoleStore, and UserStore. Both Concept and ConceptStore are abstract classes.

An OkmObject is a noun, with its own page, like "Abraham Lincoln." A Role is a type, like "President." A RolePlayer represents an object acting in a role.

Two kinds of data can be represented in the system: Relationships (object properties) and FieldValues (datatype properties). A Relatable (an abstract class) represents something that can participate in Relationships or have FieldValues: either a RolePlayer or a Relationship. A Relatable refers to an OkmMode: either an Action or a Role (a RolePlayer refers to a Role, and a Relationship refers to an Action).

A ModeBinding is a combination of OkmMode : Action : OkmMode which represents the schema fact that the Action is defined for the left and right OkmModes, whether they are Roles or Actions. For example, "Assassin:assassinate:President" or "assassinate:withWeapon:Weapon".
An OkmMode has a list of Fields, which represent the datatype properties defined for the Role or Action. A Relatable should only have a particular FieldValue if its Mode has the corresponding Field. FieldValue, the subclasses of which describe different data types, refers to its Field. For example, the Action "assassinate" might have the Field "inYear", allowing the Relationship "JohnWilkesBooth assassinate AbrahamLincoln" to have "inYear 1865", where 1865 is a DateValue.

The Statement interface represents a statement a user can assert or deny. Its implementing classes are Relationship and the FieldValue subclasses (DateValue, DblValue, FieldValue, IntValue).

'''Implementation in RDF'''

Every Concept has a URI ending in something like "type#id," like "http://rosemary.umw.edu/okmobject#123." An OkmObject corresponds to a general resource. Fields and Actions correspond to properties. OkmModes correspond to classes. Each ModeBinding identifies a particular combination of class:predicate:class, and corresponds to a subproperty of the Action's property, whose domain is the left Mode and whose range is the right Mode. The two types of OkmMode handle this differently: a Role corresponds directly to a class, but an Action already corresponds to a property. Therefore, every Action also defines a resource representing the class of relationships involving that Action's property. To get an OkmMode's class's URI, use getClassUri. Fields correspond to properties, with the OkmMode's class as the domain. Relationships and FieldValues correspond to statements, which can be asserted or denied.

OKMInterface

2009-11-13T18:20:51Z

← Older revision		Revision as of 18:20, 13 November 2009
(One intermediate revision not shown)
Line 9:		Line 9:

	[[OKMImport\|Import]]		[[OKMImport\|Import]]
		+
		+	[[Current_Okm_domain_model\|Class Diagram]]
		+
		+	[[OKMDomainChanges\|Current Domain]]
		+
		+
		+	[[Current_Okm_domain_model\|Class Diagram]]

← Older revision		Revision as of 18:25, 13 November 2009
Line 9:		Line 9:

	[[OKMImport\|Import]]		[[OKMImport\|Import]]
-
-	~~[[Current_Okm_domain_model\|Class Diagram]]~~

	[[OKMDomainChanges\|Current Domain]]		[[OKMDomainChanges\|Current Domain]]
-
-
-	~~[[Current_Okm_domain_model\|Class Diagram]]~~