Idem is a decentralized identity management app based on the decentrailzed identity foundation protocol, that allows users to verify their ID once and use many times.
A decentralised economy needs decentralised tools. The decentralised Web 3.0 vision requires an end to the centralised behemoths that deliver goods and services and prescribes genuine peer-to-peer transactions in a trustless environment.
Idem provides an independent self-sovereign identity that can digitally sign and verify a claim or authority and uses distributed ledger technology to break free from trusted third parties.
Download the white paper (Coming Soon)Users who join a digital currency exchange must verify their identity through the KYC process. Authentication ensures the supplied identification details correspond with the specific user of the system. The process is time consuming, both in terms of the length of time it takes the user to photograph and upload the required documentation, and in terms of the waiting period for the exchange to then verify the data, which can take up to a week.
Further delay is caused by the high rates of failure experienced by users. Licenses get rejected for having too much glare, edges of a document not being visible and a host of other glitches. For users who are accustomed to the instantaneousness of digital environments, these delays are frustrating.
This problem becomes exacerbated when users wish to join more than one exchange and despite having had their identity verified by their initial exchange, must go through this process each time. For the majority of digital currency users who frequently shop around for the best rates, specific tokens and other features unique to each exchange, there is a need for a more streamlined and seamless verification process.
This is the design process that the digital identity platform idem solves.
All personal data is securely stored on device.
Coming soon
Personal use by individuals will always be free.
To setup a business account, contact sales@idem.com.au


Authentication Servers
Authentication servers allow backend infrastructure to manage accounts and credentials that are used by Sensus.
Required REST Endpoints
Updating Protocols Mid-Study
Since the authentication server is able to serve up new versions of protocols mid-study, care should be taken when editing protocols for distribution. The steps below constitute the recommended approach for editing a protocol mid-study when using an authentication server.
- Delete all existing protocols from Sensus.
- Scan a study QR code to pull down the most current version of the protocol from the authentication server.
- Edit the protocol as desired.
- Run the edited protocol on your phone to test the new settings. Test for a period sufficient to exercise all desired functionality (data collection, EMAs, etc.) It is important to test changes before distributing the new protocol version to participants.
- Stop the protocol on your testing phones.
- After testing the new settings, set the protocol's identifier from within the protocol settings. Use a random identifier to mark the new version. Setting a new protocol identifier is crucial, as it signals participants' devices to update their protocols to the new version. If multiple protocols are used within a single study (e.g., one for Android and one for iOS), ensure that the identifiers match across protocols. If you need to transfer the new protocol identifier from one protocol (e.g., iOS) to another (e.g., Android), copy the new identifier (tap the "Copy Identifier" button for convenience), email it to yourself, and set the new identifier within the other protocol.
- From within Sensus on your phone(s), share the protocol(s) with the person responsible for uploading protocols into the authentication server. The best way to share the protocol is to edit it and tap the "Share" button from within the protocol settings.
- After confirming upload into the authentication server, delete the protocol from your phone, rescan the study QR code to pull down the new version from the authentication server, inspect the protocol to confirm that it reflects your edits and the new protocol identifier, and run the new version of the protocol to test it again.
There is no need to notify participants about the update. Within a few hours, their devices will notice that the protocol identifier provided by the authentication server is different from the identifier in the protocol running on their devices. When this happens, participant devices will automatically pull down the new protocol and use it to replace their existing protocols.


Owning Palette: Advanced Classes, Controls, and VIs
Requires: Labstache
Transverses an Abstract Syntax Tree (AST) obtained from the parsing process and writes the output based on the Mustache data. This is also known as "code generation" in compiling, and it is the third and final action, or process, in compiling.
| Data is the Mustache data that controls the rendering process based on its type and value. | |
| Loader is responsible for importing, or including, other Mustache templates within the root template. | |
| Abstract Syntax Tree is a grammatically generated representation of a Mustache template. | |
| Error In describes error conditions that occur before this node runs. This input provides standard error in functionality. Right-click the Error In indicator on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error. |
|
| Error Out contains error information. This provides standard error out functionality. Right-click the Error Out indicator on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error. |
|
| Output is a string of the compiled Mustache template. |
| Data is the Mustache data that controls the rendering process based on its type and value. | |
| Loader is responsible for importing, or including, other Mustache templates within the root template. | |
| Abstract Syntax Tree is a grammatically generated representation of a Mustache template. | |
| Writer In represents the destination for the compiled Mustache template. | |
| Error In describes error conditions that occur before this node runs. This input provides standard error in functionality. Right-click the Error In indicator on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error. |
|
| Writer Out is the same object from Writer In. | |
| Error Out contains error information. This provides standard error out functionality. Right-click the Error Out indicator on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error. |


| < Day Day Up > |
Dynamic SQLDynamic SQL is embedded in an application program and can change during the program's execution. Dynamic SQL statements are coded explicitly in host-language variables, prepared by the application program, and then executed. QMF and SPUFI are two examples of programs that execute dynamic SQL statements. Recall that the two types of SQL are static SQL and dynamic SQL. The primary difference between static and dynamic SQL is described capably by their names. A static SQL statement is hard-coded and unchanging. The columns, tables, and predicates are known beforehand and cannot be changed. Only host variables that provide values for the predicates can be changed. A dynamic SQL statement, conversely, can change throughout a program's execution. The algorithms in the program can alter the SQL before issuing it. Based on the class of dynamic SQL being used, the columns, tables, and complete predicates can be changed "on the fly." As might be expected, dynamic SQL is dramatically different from static SQL in the way you code it in the application program. Additionally, when dynamic SQL is bound, the application plan or package that is created does not contain the same information as a plan or package for a static SQL program. The access path for dynamic SQL statements cannot be determined before execution. When you think about it, this statement makes sense. If the SQL is not completely known until the program executes, how can it be verified and optimized beforehand? For this reason, dynamic SQL statements are not bound, but are prepared at execution. The PREPARE statement is functionally equivalent to a dynamic BIND. The program issues a PREPARE statement before executing dynamic SQL (with the exception of EXECUTEIMMEDIATE, which implicitly prepares SQL statements). PREPARE verifies, validates, and determines access paths dynamically. A program containing dynamic SQL statements still must be bound into an application plan or package. The plan or package, however, does not contain access paths for the dynamic SQL statements. DB2 provides four classes of dynamic SQL: EXECUTE IMMEDIATE, non-SELECT PREPARE and EXECUTE, fixed-list SELECT, and varying-list SELECT. The first two classes do not allow SELECT statements, whereas the last two are geared for SELECT statements. Dynamic SQL is a complex topic that can be difficult to comprehend and master. It is important that you understand all aspects of dynamic SQL before deciding whether to use it. Dynamic SQL is covered in depth in Chapter 12. |
| < Day Day Up > |


I'm a student at Washington State University studying computer science
while working on graphic design and web development
in my free time.
Feel free to view my projects, blog or just send me an email in the contact section.
August 2017 - Current
August 2008 - December 2010
Bachelor - Computer Science
I initially started attending WSU in 2008. Having been relatively successful in my highschool engineering endeavors, I decided to attend WSU
and major in mechanical engineering. Though I initially did well in my studies, I possessed a severe lack of excitement for the material which lead to a
decline in my accedemic standings. Unwilling to throw more money at an education that I had no interest in, I enlisted the Air Force. The discipline instilled
in me by the military as well as the maturity gained from the passing of time culminated in a period of tremendous personal growth.
After separating from the armed forces, I once again find myself at WSU in pursuit of a BS in computer science. Though I have many more challenges
in my life than I did in 2008, I can say with all certainty that my studies are proceeding exceptionally well.
June 2011 - September 2012
AA - Korean
While serving in the Air Force, I was employed as a Korean Cryptologic Language Analyst.
Having no prior experience with Korean, or any other foreign language, I had no idea what I was getting myself into. The program was taught by Korean nationals and though grueling at times,
invariably worth it .
Aug 2004 - June 2008
Highschool Diploma
I completed highschool with plans to become an engineer. Participated in baseball, basketball, golf and was captain of the football team.
I was also a member of the school FFA team, National Honor Society and placed second place at the
JETS/AbilityOne National Engineering
Design Challenge which was later became a part of
Technology Student Association. Following our success, Massachusetts Institute of Technology invited the team to another national competition as well as
awarding the school a grant of $10,000.
March 2018 - May 2019
Desktop Support IT Specialist
I worked at the university as an IT specialist. I troubleshot user issues as well as ensuring that all systems were up to date with
the latest software and maintaining images for department computers. In March of 2019 I was told Desktop support would no longer be employing students at the end of the semester.
Not one to sit idle, I reached out to someone I had done some work for while at Desktop support and by the end of the day had an interview scheuduled for the Crimson Service Desk.
August 2019 - August 2020
Technical Assistant II
Using the reputation I had built at Desktop support I was able to easily transition to the Crimson Service Desk.
The primary difference between the two jobs was that I was now assisting students with IT and account related issues rather
than department staff. After one semester of working at CSD I was promoted to Technical Assistant II. Unfortunately I had to leave CSD due to time
constraints caused by the Covid-19 pandemic and the switch to an online learning environment. Shortly before leaving CSD I was part of the team that
was used to model the current operations of CSD on all WSU campuses.
April 2011 - April 2017
Korean Cryptologic Language Analyst
While serving in the armed forces, my duties were those of a linguist and intelligence specialist. After completing the Korean course at the Defense
Language Institute, my first duty station was Osan Air Force Base, South Korea. I excelled at my position and within six months was promoted to Conventional
Operations Supervisor, a position generally held by a Senior Non-Commissioned Officer (SNCO). After two years in Korea, I received the Air Force Achievement medal
and departed for Fort George Meade, MD.
While stationed in Maryland, my primary job was as a Target Analyst at the National Security Agency. My duties included working on reports and handling
administrative tasks. I separated from the armed forces in 2017 and returned to Washington state after receiving the Joint Service Achievement medal.
August 2007 - September 2010
Lead Technician and Fabricator
I worked as the Lead Technician which included operation and maintenance of the
orchard’s heavy equipment. I was also responsible for fabricating anything the owner needed,
including the gates installed at the primary entrance points. Other duties primarily customer service related.
Do you have any questions? Please do not hesitate to contact me directly. I will get back to you as quickly as possible!
Colfax, WA
(210) 557 2304
colbycocking@gmail.com


Bucket list
Home
james947
Log out
@james947
My profile
Bucket lists
Add New Activities
MY LIST
Live life to the Fullest
{% for post in post %}
{{post.title}}
{{post.date_posted}}
{{post.description}}
Edit Activity
Delete Activity
{% endfor %}


The API¶
This part details the various API endpoints that can be used within YETI.
API bindings:
- Python: pyeti
Observables, Indicators and Entities¶
Observables¶
-
POST
/api/observable/bulk
¶ Bulk-add observables
Bulk-add Observables from an array of strings.
Request JSON Object: - [{string – observable, tags: [string]}] observables: Array of Strings representing observables (URLs, IPs, hostnames, etc.)
- refang (boolean) – If set, the observables will be refanged before being added to the database
-
DELETE
/api/observable/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/observable/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/observable/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/observable/
¶ Create a new Observable
Create a new Observable from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
- refang (boolean) – If set, the observable will be refanged before being added to the database
-
DELETE
/api/tag/
(id)¶ Deletes a Tag
Also remove the tag from any tagged elements.
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/tag/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/tag/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/tag/merge
¶ Merge one or more tags
Merge one or more tags into a single tag. This is useful for replacing one or several tags with other tags.
Request JSON Object: - merge ([String]) – Array of Strings (tag names) representing tags to be merged.
- merge_into (String) – The tag to merge into
- make_dict (boolean) – Create a Tag dictionary out of this merge.
In the future, tags included in the
merge
object will be automatically replaced by the tag specified inmerge_into
.
-
POST
/api/tag/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/tag/
(id)¶ Create a new Tag
Edit an existing Tag according to the JSON object passed in the
POST
data. If the name of a tag is changed, it will repeat the change in all Observables associated with this tag.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
Indicators¶
-
DELETE
/api/indicator/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/indicator/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/indicator/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/indicator/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/indicator/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
Entities¶
-
GET
/api/entity/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
GET
/api/entity/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
DELETE
/api/entity/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
POST
/api/entity/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/entity/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
Searching¶
-
POST
/api/observablesearch/
¶ Launches a simple search against the database
This endpoint is mostly used by paginators in Yeti.
Request JSON Object: - params (object) – JSON object specifying the
page
,range
andregex
variables. - params.page (integer) – Page or results to return (default: 1)
- params.range (integer) – How many results to return (default: 50)
- params.regex (boolean) – Set to true if the arrays in
filter
are to be treated as regular expressions (default: false) - filter (object) – JSON object specifying keys to be matched in the database. Each key must contain an array of OR-matched values.
Request Headers: - Accept – must be set to
application/json
- Content-Type – must be set to
application/json
- params (object) – JSON object specifying the
-
POST
/api/indicatorsearch/
¶ Launches a simple search against the database
This endpoint is mostly used by paginators in Yeti.
Request JSON Object: - params (object) – JSON object specifying the
page
,range
andregex
variables. - params.page (integer) – Page or results to return (default: 1)
- params.range (integer) – How many results to return (default: 50)
- params.regex (boolean) – Set to true if the arrays in
filter
are to be treated as regular expressions (default: false) - filter (object) – JSON object specifying keys to be matched in the database. Each key must contain an array of OR-matched values.
Request Headers: - Accept – must be set to
application/json
- Content-Type – must be set to
application/json
- params (object) – JSON object specifying the
-
POST
/api/entitysearch/
¶ Launches a simple search against the database
This endpoint is mostly used by paginators in Yeti.
Request JSON Object: - params (object) – JSON object specifying the
page
,range
andregex
variables. - params.page (integer) – Page or results to return (default: 1)
- params.range (integer) – How many results to return (default: 50)
- params.regex (boolean) – Set to true if the arrays in
filter
are to be treated as regular expressions (default: false) - filter (object) – JSON object specifying keys to be matched in the database. Each key must contain an array of OR-matched values.
Request Headers: - Accept – must be set to
application/json
- Content-Type – must be set to
application/json
- params (object) – JSON object specifying the
Feeds and Exports¶
-
GET
/api/export/
(string: id)/content
¶ Return export content
Returns a given export’s content.
Query Parameters: - id (ObjectID) – Export ID
Response Headers: - X-Yeti-Export-MD5 – The MD5 hash of the exported content. Use it to check the export’s integrity
-
DELETE
/api/export/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/export/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/export/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/export/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/export/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/export/
(string: id)/refresh
¶ Refresh an export
Manually executes an export if it is not already exporting.
Query Parameters: - id (ObjectID) – Export ID
Response JSON Object: - id (ObjectID) – The export’s ObjectID
-
POST
/api/export/
(string: id)/toggle
¶ Toggle an export
Toggles an export. A deactivated export will not execute when called (manually or scheduled)
Query Parameters: - id (ObjectID) – Export ID
Response JSON Object: - id (ObjectID) – The export’s ObjectID
- status (boolean) – The result of the toggle operation (
true
means the export has been enabled,false
means it has been disabled)
-
DELETE
/api/exporttemplate/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/exporttemplate/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/exporttemplate/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/exporttemplate/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/exporttemplate/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
DELETE
/api/feed/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/feed/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/feed/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/feed/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/feed/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/feed/
(id)/refresh
¶ Runs a Feed
Query Parameters: - id (ObjectID) – Feed ID
Response JSON Object: - id (ObjectId) – Feed ID
-
POST
/api/feed/
(id)/toggle
¶ Toggles a Feed
Feeds can be individually disabled using this endpoint.
Query Parameters: - id (ObjectID) – Analytics ID
Response JSON Object: - id (ObjectID) – The Analytics’s ObjectID
- status (boolean) – The result of the toggle operation (
true
means the export has been enabled,false
means it has been disabled)
Analysis¶
-
POST
/api/analysis/match
¶ Match observables against Yeti’s intelligence repository.
Takes an array of observables, expands them and tries to match them against specific indicators or known observables.
To “expand” an observable means to enrich the query. For instance, if the arrays of observables contains the URL
http://google.com
, the “expanded” observable array will also include the hostnamegoogle.com
.Request JSON Object: - observables ([string]) – An array of observables to be analyzed
Response JSON Object: - entities ([Entity]) – Related
Entity
objects - known ([Observable]) –
Observable
objects that are already present in database - matches ([Indicator]) –
Indicators
that matched observables - matches[].observable (Observable) – The
Observable
object that matched theIndicator
- unknown (string) – Array of observable strings that didn’t match any
Indicators
and are unknown to Yeti
-
GET
/api/analysis/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
GET
/api/analysis/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
DELETE
/api/analysis/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
POST
/api/analysis/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/analysis/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
DELETE
/api/analytics/oneshot/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/analytics/oneshot/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
POST
/api/analytics/oneshot/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/analytics/oneshot/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/analytics/oneshot/
(id)/run
¶ Runs a One-Shot Analytics
Asynchronously runs a One-Shot Analytics against a given observable. Returns an
AnalyticsResults
instance, which can then be used to fetch the analytics resultsQuery Parameters: - id (ObjectID) – Analytics ID
Form Parameters: - ObjectID id – Observable ID
Response JSON Object: - object – JSON object representing the
AnalyticsResults
instance
-
POST
/api/analytics/oneshot/
(id)/toggle
¶ Toggles a One-shot Analytics
One-Shot Analytics can be individually disabled using this endpoint.
Query Parameters: - id (ObjectID) – Analytics ID
Response JSON Object: - id (ObjectID) – The Analytics’s ObjectID
- status (boolean) – The result of the toggle operation (
true
means the export has been enabled,false
means it has been disabled)
-
DELETE
/api/analytics/scheduled/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/analytics/scheduled/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/analytics/scheduled/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/analytics/scheduled/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/analytics/scheduled/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/analytics/scheduled/
(id)/refresh
¶ Runs a Scheduled Analytics
Query Parameters: - id (ObjectID) – Scheduled Analytics ObjectID
Response JSON Object: - id (ObjectID) – ID of refreshed Scheduled Analytics
-
POST
/api/analytics/scheduled/
(id)/toggle
¶ Toggles a Scheduled Analytics
Scheduled Analytics can be individually disabled using this endpoint.
Query Parameters: - id (ObjectID) – Analytics ID
Response JSON Object: - id (ObjectID) – The Analytics’s ObjectID
- status (boolean) – The result of the toggle operation (
true
means the export has been enabled,false
means it has been disabled)
Investigation¶
-
DELETE
/api/investigation/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/investigation/
(id)¶ Get details on a specific element
Query Parameters: - id (ObjectID) – Element ID
-
GET
/api/investigation/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/investigation/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/investigation/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set
-
DELETE
/api/neighbors/
(id)¶ Deletes the corresponding entry from the database
Query Parameters: - id (ObjectID) – Element ID
Response JSON Object: - deleted (string) – The deleted element’s ObjectID
-
GET
/api/neighbors/
¶ List all corresponding entries in the database. Do not use on large datasets!
-
POST
/api/neighbors/
¶ Create a new element
Create a new element from the JSON object passed in the
POST
data.Request JSON Object: - params (object) – JSON object containing fields to set
-
POST
/api/neighbors/
(id)¶ Modify an element
Edit an existing element according to the JSON object passed in the
POST
data.Query Parameters: - id (ObjectID) – Element ID
Request JSON Object: - params (object) – JSON object containing fields to set


DFTCalc by FMT
Home
Documentation
Dependencies
Installation
Manual
Summary
Usage
Additional Info
Web-Tool
DFTCalc Web-Tool
Your Dynamic Fault Tree Calculator


Checks if a section exists within the specified .ini file.
Returns 1 if the section exists and 0 if it does not exist.
| Box Name | Type | Description |
|---|---|---|
| File Name | String | Name of the file. Will create one if it doesn’t exist. Do not include the path. |
| Section | String | The section to check. |
| Variable | String | Variable to save the result in. |


Injector
Warning: this project is not considered to be feature complete.
Before:
let applicationController = ApplicationController(
persistanceService: persistanceService,
analyticsService: analyticsService,
remoteConfigurationService: remoteConfigurationService,
authenticationController: authenticationController,
networkProvider: provider
)
After:
let applicationController = try injector.inject(ApplicationController.init)
Please check out playground included with project for more examples.
But wait, there is more
Simple injection:
let chicken = 🐔()
injector.set(chicken)
// later in your code
let chicken: 🐔 = injector.get()
chicken.cockadoodle()
Explicit type specification
protocol 🍌💕 {
func peel()
}
struct 🐵: 🍌💕 {
}
struct 🐨: 🍌💕 {
}
injector.set(🐵())
injector.set(🐨())
let banana: 🍌💕 = injector.get(type: 🐨.self)!
banana.peel()
Automatic injection
Injector
can inject all the arguments for specified function using previously registered instances:
struct 🦁 {
let heart: ❤
let innerKitten: 😺
init(heart: ❤, innerKitten: 😺) {
self.heart = heart
self.innerKitten = innerKitten
}
}
injector.set(❤())
injector.set(😺())
let lion = try injector.inject(🦁.init)
lion.meow()
If any of parameters is not registered with injector
, it will throw an InjectorError.TypeNotFound(T)
with first type injector failed to find.
You are not limited to initializer, you can use any method (with up to 30 arguments)
Current Limitations
inject
will get confused. As a possible workaround, you can define a convinience class function that doesn’t have anyComplexity
Complexity ofget
method is currently O(n). PRs on improving this one are very much welcome. The only limitation is not to use Objective-C runtime magic.
Thanks
Installation
Carthage
github "zats/Injector"
Then run carthage update
.
Follow the current instructions in Carthage’s README for up to date installation instructions.
CocoaPods
Add the following to your Podfile:
pod 'SwiftInjector'
You will also need to make sure you’re opting into using frameworks:
use_frameworks!
Then run pod install
with CocoaPods 0.36 or newer.


1. Overview
Figures, images and strings can be treated as on-layer objects. An on-layer object is created from a class derived from the HuTime.OnLayerObjectBase class. Unlike cases where figures, images and strings are displayed using a method of HuTime.Drawing, an on-layer object behaves as one object and therefore can receive events, etc. The on-layer object is useful for small numbers. However, you should preferably use methods of HuTime.Drawing if you want to use a large number of figures, images and strings, in terms of resource consumption.
| Function | On-layer Object | Object Drawn by HuTime.Drawing |
|---|---|---|
| Redrawing | Is redrawn by the redraw method on an object basis. | Is redrawn by executing the display method of HuTime.Drawing again. Alternatively, execute the redraw method of the layer. |
| Redraw timing | Redrawing is specified automatically if it is added to a layer. You can also define processBeforeRedraw or processAfterRedraw for the object. | Is manually specified on processBeforeRedraw or processAfterRedraw of the layer. |
| Stack order on the screen | Specifies it with the zIndex property. | Specifies it with the order of drawing. |
| Visible/invisible control | Specifies it with the visible property. | Has no control mechanism by default. You should provide some form of control over the action for displaying the object that is described in processBeforeRedraw or processAfterRedraw of the layer. |
| Event reception | Can receive events directly. They are incorporated into the entire event flow process. | Cannot receive events directly. They are received by layers and then determined. |
| Resource consumption | Consumes a certain amount of resources as a single object. | Consumes a few resources. |
List of on-layer objects (classes derived from the OnLayerObject class). The OnLayerObjectBase is defined as an abstract class, and is not used in practice.
2. Types of On-layer Objects and Constructors
Unlike when objects are drawn by the HuTime.Drawing method, the constructor is not used to specify the layer or canvas on which the object is drawn. This is performed when the object is added to the layer. The constructor for each object has the following common arguments:
- style
- Type: FigureStyle object (StringStyle object in HuTime.String)
- Specifies the format of the figure or string.
- rotate
- Type: Number
- The angle of rotation of the figure (in degrees). This can be optionally specified. If omitted, it is set to 0. The figure is rotated around the center of the figure itself. It cannot be specified for some figures, such as circle objects.
Line (Polyline)
HuTime.Line(style, positions)
Specify the positions of nodes for the line as an array of Position objects. Unlike polygons, this method does not close the path. The rotation angle (rotate) cannot be specified.
- positions
- Type: HuTime.PositionBase array.
- A collection of positions of nodes for the line.
Polygon
HuTime.Polygon(style, positions)
Specify the vertex position of the polygon as an array of Position objects. This method connects the last position with the first position in the array, and closes the path. The rotation angle (rotate) cannot be specified.
- positions
- Type: HuTime.PositionBase array.
- A collection of vertex positions of the polygon.
Square
HuTime.Square(style, position, width [, rotate])
Specify the center of the square as the position using a Position object, and the size as the width (the length of a side) in pixels. When the rotation angle (rotate) is set to 45, a rhombus is drawn.
- position
- Type: HuTime.PositionBase
- The center position of the square.
- width
- Type: Number
- The width of the square (in pixels). It corresponds to the length of the side.
Rectangle
HuTime.Rect(style, position1, position2 [, rotate])
Specify the positions of two diagonal vertices of the rectangle as the position and size using Position objects.
- position1
- Type: HuTime.PositionBase
- The position of one vertex of the rectangle, which is one endpoint of a diagonal joining two opposite vertices.
- position2
- Type: HuTime.PositionBase
- The position of another vertex of the rectangle, which is the other endpoint of the diagonal joining two opposite vertices.
Circle
HuTime.Circle(style, position, width)
Specify the center of the circle as the position using a Position object, and the size as the width (the diameter) in pixels. The rotation angle (rotate) cannot be specified.
- position
- Type: HuTime.PositionBase
- The center position of the circle.
- width
- Type: Number
- The width of the figure (in pixels). It corresponds to the diameter of the circle.
Circular Arc
HuTime.Arc(style, position, radius, startAngle, endAngle)
Specify the center of the circle of which the circular arc is part as the position using a Position object, and the radius of the circle (in pixels) and the angles of the start and end positions (in degrees) as the size and shape. The rotation angle (rotate) cannot be specified.
- position
- Type: HuTime.PositionBase
- The center position of the circle of which the circular arc is part.
- radius
- Type: Number
- The radius of the circle of which the circular arc is part (in pixels).
- startAngle
- Type: Number
- The start angle of the circular arc (in degrees).
- endAngle
- Type: Number
- The end angle of the circular arc (in degrees).
Sector
HuTime.Pie(style, position, radius, startAngle, endAngle)
Specify the center of the circle of which the sector is part as the position using a Position object, and the radius of the circle (in pixels) and the angles of the start and end positions (in degrees) as the size and shape. The rotation angle (rotate) cannot be specified.
- position
- Type: HuTime.PositionBase
- The center position of the circle of which the sector is part.
- radius
- Type: Number
- The radius of the circle of which the sector is part (in pixels).
- startAngle
- Type: Number
- The start angle of the sector (in degrees).
- endAngle
- Type: Number
- The end angle of the sector (in degrees).
Triangle
HuTime.Triangle(style, position, width [, rotate])
Specify the center of the triangle (the center of gravity) as the position using a Position object, and the width (the length of the base) as the size in pixels.
- position
- Type: HuTime.PositionBase
- The position of the center (the center of gravity) of the triangle.
- width
- Type: Number
- The width of the triangle (in pixels). It corresponds to the length of the base.
3. Key Properties and Methods of On-layer Objects
Properties
- id
- Type: String
- Default value: null
- The ID for uniquely identifying the object.
- name
- Type: String
- Default value: null
- The name of the object.
- visible
- Type: Boolean
- Default value: true
- Whether the object is visible or invisible. If true, it is visible.
- zIndex
- Type: Number
- Default value: 0
- The stack order of the object. An object with a greater value appears at an upper position.
Methods
redraw()
Redraws the object.
- Return value
- None
addEventListener(type, handler [, useCapture])
Adds event handling.
- Return value
- None
- type
- Type: String
- The string that represents the type of the event.
- handler
- Type: Function (function(ev))
- The function to handle the event. The ev argument is an event object (type: HuTime.Event).
- useCapture
- Type: Boolean
- Specify which phase of the event is used. If true, the capture phase is used; if false, the bubbling phase is used. If omitted, it is set to false (the bubbling phase).
dispatchEvent(ev)
Triggers the event from the on-layer object.
- Return value
- None
- ev
- Type: HuTime.Event object
- The event object for the event to be triggered. ev.target is set to the source on-layer object.
4. Adding an Object to a Layer
You can add an object to a layer by using the appendObject method of the layer. Also, you can remove an object from a layer by using the removeObject method of the layer. One layer can have only one object on it. Thus, when you execute appendObject on the object that has been placed on a different layer, it is removed from the layer to which it already belongs.
layer.appendObject(obj [, canvas])
layer.removeObject(obj)
- layer
- Type: HuTime.Layer
- The layer to which the object is added or from which it is removed.
- obj
- Type: HuTime.OnLayerObjectBase
- The object to be added or removed.
- canvas
- Type: canvas element
- The canvas on which the figure is drawn. This can be optionally specified. If omitted, it is set to layer.canvas. It is used when you want to draw a figure on a Layer object with multiple canvas elements, such as timeline layer or chart layer.
An example of displaying on-layer objects (see the sample code below).
Sample code (click here for a running example):
<!DOCTYPE html>   <meta charset="UTF-8">  <title>Sample Code</title>

5. Event Handling of On-layer Objects
You can define an action that receives an event directly and deals with it for an on-layer object. How the event is handled is added by the addEventListener method. In the sample code below, the color of the circle changes when you click the gray rectangle that is displayed as an on-layer object.
Sample code (click here for a running example):
<!DOCTYPE html>   <meta charset="UTF-8">  <title>Sample Code</title>


Package org.apache.cayenne
Interface DataObject
- All Superinterfaces:
Persistent
,Serializable
- All Known Implementing Classes:
BaseDataObject
,CayenneDataObject
,HybridDataObject
public interface DataObject extends Persistent
Defines basic methods for a persistent object in Cayenne.
-
Field Summary
Fields Modifier and Type Field Description static long
DEFAULT_VERSION
-
Method Summary
Modifier and Type Method Description void
addToManyTarget(String relationshipName, DataObject target, boolean setReverse)
Adds an object to a to-many relationship.long
getSnapshotVersion()
Returns a version of a DataRow snapshot that was used to create this object.Object
readNestedProperty(String path)
Returns a value of the property identified by a property path.Object
readProperty(String propName)
Returns a value of the property identified by propName.Object
readPropertyDirectly(String propertyName)
Returns mapped property value as curently stored in the DataObject.void
removeToManyTarget(String relationshipName, DataObject target, boolean unsetReverse)
Removes an object from a to-many relationship.void
setSnapshotVersion(long snapshotVersion)
void
setToOneTarget(String relationshipName, DataObject value, boolean setReverse)
Sets to-one relationship to a new value.void
writeProperty(String propertyName, Object value)
Sets the property to the new value.void
writePropertyDirectly(String propertyName, Object val)
Modifies a value of a named property without altering the object state in any way, and without triggering any database operations.Methods inherited from interface org.apache.cayenne.Persistent
getObjectContext, getObjectId, getPersistenceState, setObjectContext, setObjectId, setPersistenceState
-
Field Details
-
DEFAULT_VERSION
static final long DEFAULT_VERSION- See Also:
- Constant Field Values
-
-
Method Details
-
writePropertyDirectly
Modifies a value of a named property without altering the object state in any way, and without triggering any database operations. This method is intended mostly for internal use by Cayenne framework, and shouldn't be called from the application code. -
readPropertyDirectly
Returns mapped property value as curently stored in the DataObject. Returned value maybe a fault or a real value. This method will not attempt to resolve faults, or to read unmapped properties. -
readNestedProperty
Returns a value of the property identified by a property path. Supports reading both mapped and unmapped properties. Unmapped properties are accessed in a manner consistent with JavaBeans specification.Property path (or nested property) is a dot-separated path used to traverse object relationships until the final object is found. If a null object found while traversing path, null is returned. If a list is encountered in the middle of the path, CayenneRuntimeException is thrown. Unlike
readPropertyDirectly(String)
, this method will resolve an object if it is HOLLOW.Examples:
- Read this object property:
String name = (String)artist.readNestedProperty("name");
- Read an object related to this object:
Gallery g = (Gallery)paintingInfo.readNestedProperty("toPainting.toGallery");
- Read a property of an object related to this object:
String name = (String)painting.readNestedProperty("toArtist.artistName");
- Read to-many relationship list:
List exhibits = (List)painting.readNestedProperty("toGallery.exhibitArray");
- Read to-many relationship in the middle of the path:
List<String> names = (List<String>)artist.readNestedProperty("paintingArray.paintingName");
- Since:
- 1.0.5
- Read this object property:
-
readProperty
Returns a value of the property identified by propName. Resolves faults if needed. This method can safely be used instead of or in addition to the auto-generated property accessors in subclasses of CayenneDataObject. -
writeProperty
Sets the property to the new value. Resolves faults if needed. This method can be safely used instead of or in addition to the auto-generated property modifiers to set simple properties. Note that to set to-one relationships usesetToOneTarget(String, DataObject, boolean)
.- Parameters:
propertyName
- a name of the bean property being modified.value
- a new value of the property.
-
addToManyTarget
Adds an object to a to-many relationship. -
removeToManyTarget
Removes an object from a to-many relationship. -
setToOneTarget
Sets to-one relationship to a new value. Resolves faults if needed. This method can safely be used instead of or in addition to the auto-generated property modifiers to set properties that are to-one relationships.- Parameters:
relationshipName
- a name of the bean property being modified - same as the name of ObjRelationship.value
- a new value of the property.setReverse
- whether to update the reverse relationship pointing from the old and new values of the property to this object.
-
getSnapshotVersion
long getSnapshotVersion()Returns a version of a DataRow snapshot that was used to create this object.- Since:
- 1.1
-
setSnapshotVersion
void setSnapshotVersion(long snapshotVersion)- Since:
- 1.1
-


Watch as different Sub-Continent's stream their Talent.
Or Stream your own Talent and Be a StreamWarrior.
And open yourself to a world of amazing features
Make Profile, Earn Coins, Watch talents,
Record Live Videos, Send Gifts, Chat with Talents
And Much More.


Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This report discusses an effort to apply the Resource Description Framework (RDF) to iCalendar data in order to integrate calendar data with other Semantic Web data such as social networking data, syndicated content, and multimedia meta-data. We demonstrate the effectiveness of a test-driven approach to vocabulary development and we discuss a number of social as well as technical issues.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This draft discusses the state of the art in the RDF calendar task force of the Semantic Web Interest Group in the Semantic Web Activity. This work began at the Semantic Web calendaring workshop in October 2002. While a number of issues remain open, the design is backed by a few dozen test cases and it is increasingly useful and stable. Please send comments to<EMAIL_ADDRESS>a mailing list with public archive.
Publication as an Interest Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The Web did two things for sharing information with documents: first, HTML and TCP/IP provided a neutral answer to the questions about which word processor's format to use, which operating system, and which networking technology; second, the Web integrated individual documents into a whole information system so that if the information was already in the Web somewhere, you could just link to it. HTML is feature-poor when compared to other document formats, but the integration benefits of linking outweigh the costs.
Fifteen years later, this works pretty well for documents. If you have a document and someone asks you to provide it to each of a dozen different people that each use different kinds of computers, you can just put it on the Web in HTML and be reasonably sure they can all read it. But the integration problem is still there for data. When a soccer coach distributes a schedule for the season, each of the players has to re-key the information for their calendar system if they want their computer to help them manage conflicts. When an airline sends itineraries, each passenger manually processes them.
The problem is addressed at least in part by an Internet standardst for calendar data, iCalendar[RFC2554]. But it's not clear that iCalendar provides sufficient integration benefits to outweigh the cost of migrating to open systems from more mature closed calendaring systems. At a Semantic Web calendaring workshop in October 2002, we explored the additional benefits of applying the Resource Description Framework (RDF) to iCalendar data, allowing us to linked it with social networking data (FOAF), syndicated content (RSS), multimedia metadata (dublin core, musicbrainz) etc.
The iCalendar specification is fairly large, with 142 sections and a number of complex interactions. The widely available software seems to cover much of the useful functionality, but not every aspect of the specification; for example, we have not seen tool support for exception rules. Meanwhile, at the workshop, we did have a number of actual iCalendar data files, representing real-world events, that had been converted to RDF either manually or with scripts. The resulting RDF/XML analogs served useful purposes to at least some of the participants and seemed to be correct, by inspection, to all present. This provided critical mass to begin maintaining a test suite
A particularly rewarding aspect of this collaboration is exploring language and culture boundaries. Even though there is a six hour time gap between Chicago and London, office hours overlap regularly, and while the difference in dialect and etiquette is often entertaining, it is rarely an obstacle to understanding. Our colleagues from Japan are much more able to converse in English than we are in Japanese. Even so, without the benefit of non-verbal clues, remote conversations are particularly challenging. Email offers the chance to read and compse at your own pace, but the the timezone gaps between America, Europe, and Asia effective impose a 24 hour round-trip time that is a real barrier to conversation. Internet Relay Chat (IRC) allows near-real-time feedback and clarification as well as the clarity of written text and a chance to reflect at least a few minutes to digest one message and compose another, but only if all parties can devote their attention at the same time.
We use an archived mailing list<EMAIL_ADDRESS>, as
the forum of record,
with any significant work that happens by chance
in IRC reported there after the fact. We also conduct a form of meeting over
IRC, called with advanced notice of a week or so, where some conscious effort
is given to agenda management, due process for decision making, follow-up on
actions, and the like. We have given the name ScheduledTopicChat to
this collaboration pattern. RdfCalendarMeetings
serves as an index of meeting records.
At a glance, converting iCalendar data to RDF is quite straightforward; in iCalendar terms, an event is a component with various properties:
BEGIN:VEVENT UID:20020630T230445Z-3895-69-1-7@jammer DTSTART;VALUE=DATE:20020703 DTEND;VALUE=DATE:20020706 SUMMARY:Scooby Conference LOCATION:San Francisco END:VEVENT
and RDF/XML has analagous class and property constructs:
<Vevent> <uid>20020630T230445Z-3895-69-1-7@jammer</uid> <dtstart>2002-07-03</dtstart> <dtend>2002-07-06</date> Scooby Conference <location>San Francisco</location> </Vevent>
The terms Vevent
, uid
, etc. in the RDF/XML
example above are actually abbreviations. The Vevent
element is
dominated by an element with namespace declarations:
<rdf:RDF xmlns="http://www.w3.org/2002/12/cal#"> ... <Vevent> <uid>20020630T230445Z-3895-69-1-7@jammer</uid> <dtstart>2002-07-03</dtstart> <dtend>2002-07-06</date> Scooby Conference <location>San Francisco</location> </Vevent>
The result is that the element name Vevent
is short for a
full URI http://www.w3.org/2002/12/cal#Vevent
.
iCalendar data typically consists of a CALENDAR
component with VEVENT
components and such inside it. An initial design identified the calendar
object with the RDF/XML document ala
<Vcalendar rdf:about=""> ... </Vcalendar>
i.e. "this document is a Vcalendar with ... ." But we ran into a case of iCalendar data with more than one calendar in a file. There was some discrepancy among implementations as to whether this was good data; mozilla did not seem to accept it, but this was reported as a bug#179985 and indeed, section 4.4 iCalendar Object says
The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together.
So we decided2003-02-12
to drop rdf:about=""
from our icalendar<->RDF mapping.
iCalendar syntax has no name for the relationship between an outer component and an inner component; it just uses the position in the syntax to express the relationship. Syntactic position in RDF only tells the "part of speech," i.e. subject, predicate, or object of a relationship, so we needed a name for this relationship. We decided2003-02-12 to use ical:component to relate calendars to events.
We have explored using the iCalendar uid property to make URIs for event components2003-08-19. It's not clear whether events in separate files bearing the same uid should be considered identical or merely different views of the same event. For example, if they are identical, they have the same alarms. One approach that seems to work well is to use the uid as a fragment identifier rather than as a full URI.
While these examples suggest that the mapping is straightforward, they also demonstrate one of the early issues: capitalization. In iCalendar, component and property names are case insensitive and conventionally written in all caps. But due to internationalization and simplicity considerations, XML names and URIs are case sensitive, and RDF class and property names inherit constraints from XML and URIs. In addition, the established convention is that RDF class names are capitalized and RDF property names begin with a lower case letter, and both use camelCase to join words.
The first attempts to convert iCalendar data to RDF were perl scripts of a hundred lines or so that just manipulated the punctuation. But this approach breaks down when the punctuation of a property depends on the name of the propertyp. Soon it became clear that there were details beyond capitalization that varied from property type to property type; the conversion process needed information from a schema.
Capitalization is one of many issues that had a number of efforts to relate iCalendar and RDF (A quick look at iCalendar by Tim Berners-Lee in 2001, hybrid.rdf by Miller and Arick in 2001, ical2rdf.pl by Connolly in 2002) had explored independently. At the workshop 2002, we agreed to work together on a shared RDF Schema, that is: a shared document in the Web that provides definitions, of a sort, for a number of related terms. After consideration of preserving the investment in each of the existing iCalendar schemas, it seemed the data that referenced them might have been composed with an expectation that those schemas would not change. We chose a new namespace name, http://www.w3.org/2002/12/cal#.
The issues around managing changes to an RDF schema are similar to
managing changes in other documents: should you update the content in place,
or should you keep the old version there and put the new version at a
different place in the Web? We chose a process that is reasonably simple and
has proven to be quite robust and scalable: the schema is subject to
change, with notice and appeal; that is: all changes to the schema
are announced to the www-rdf-calendar
mailing list; if anyone
objects within a week, the change is rolled back for further discussion.
The regular structure of the iCalendar specification, with components and properties, suggests declaring corresponding RDF classes and properties in an RDF schema should be straightforward. But an attempt to do it manually ( hybrid.rdf by Miller and Arick in 2001) proved unwieldy.
We explored using rules to generate a schema from our example data. Rules such as "if something is related to semething else by ?P, then ?P is a Property" and "if something is a ?C, then ?C is a Class" can be expressed in Notation3 rule syntax:
{ [] ?P []. } => { ?P a r:Property }. { [] a ?C } => { ?C a s:Class }.
This approach worked to enumerate the classes and properties we were using in our test data, but it did not provide important schema information such as value types.
The iCalendar specification has a very regular structure for value types and such:
<IP_ADDRESS> Date/Time Start Property Name: DTSTART Purpose: This property specifies when the calendar component begins. Value Type: The default value type is DATE-TIME. The time value MUST be one of the forms defined for the DATE-TIME value type. The value type can be set to a DATE value type.
We converted this structured plain text to XHTML with semantic markup for two reasons:
A python program, slurpIcalSpec.py, produces XHTML including typed links from properties to value types:
- Property Name
DTSTART- Purpose
This property specifies when the calendar component begins.- Value Type
The default value type isDATE-TIME
. The time value MUST be one of the forms defined for the DATE-TIME value type. The value type can be set to a DATE value type.
The markup uses semantic class names and link relationships:
<h2 id="sec<IP_ADDRESS>"><IP_ADDRESS> Date/Time Start

Property Name

 DTSTART

Purpose

 This property specifies when the calendar component begins.

Value Type

The default value type is DATE-TIME
 . The time value MUST be one of the forms defined for the DATE-TIME value type. The value type can be set to a DATE value type.

An XSLT transformation, webize2445.xsl, turns this into RDF/OWL:
<rdf:Description rdf:ID="dtstart"> <rdfs:label>DTSTART</rdfs:label> <rdfs:comment>This property specifies when the calendar component begins.</rdfs:comment> <rdfs:comment> default value type: DATE-TIME</rdfs:comment> <spec:valueType>DATE-TIME</spec:valueType> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Value_DATE-TIME"/> <owl:Class rdf:about="#Value_DATE"/> <owl:Class rdf:about="#Value_DATE"/> </owl:unionOf> </owl:Class> </rdfs:range>
This approach does not produce schema information for the
component
property discussed above, nor for
properties such as interval
and byday
used in
recurrence rules. Those should be added in due course.
The schema also currently lacks information about which properties are functional or inverse-functional, which are needed for certain diff/sync techniques2004-03-23. Unfortunately, adding that information conflicts with certain OWL DL restrictions, and makes it harder to use OWL DL checking tools with this schema. This remains an open issue.
Another python program, compDecls.py, reads the schema and prints it as a python data structure for use in our iCalendar to RDF conversion utilitytd, fromIcal.py:
('Vevent', {"ATTACH": ('attach', 'URI', 0, None), "CATEGORIES": ('categories', "TEXT", 0, None), "SUMMARY": ('summary', "TEXT", 0, None), "DTEND": ('dtend', 'DATE-TIME', 0, None), "DTSTART": ('dtstart', 'DATE-TIME', 0, None),
The iCalendar syntax allows extension tokens in a number of places. Ideally, we would like to ground these extension tokens in URI space as well, but none of the approaches we have tried is completely satisfactory.
One approach was to specify a namespace for x- tokens on the command line, at conversion time. The drawbacks of this approach are
iCalendar data is labelled with a product ID that serves a similar role to an XML namespace name, though it is not expressed as a URI. We decided2003-02-26 to institute an ical product registry. When we found some extensions used by some product, we would publish a schema for those extensions using a URI starting with 'http://www.w3.org/2002/12/cal/prod/' followed by a function of the product id.
The drawback of this approach is that it does not seem to be worth the trouble. In practice, we seem to be more content to just disregard the extended properties. Handling extensions remains an outstanding issue in our test suite2003-08-20.
Now that we have explored the schema and extension tokens, let's look at the calendar data itself.
Consider the case of a shop with regular hours. Contemporary directory services provide telephone numbers and street addresses, complete with automated driving directions. But you still have to pick up the phone and call them to find out when they're open. Typical shop hours can be expressed using recurring events in iCalendar. The bus-hrs.rdf test expresses "Open 11:30a-11:30p Wed-Sun; Open Tue 4-11p" in RDFttl:
@prefix : <http://www.w3.org/2002/12/cal/icaltzd#> . @prefix NY: <http://www.w3.org/2002/12/cal/tzd/America/New_York#> . <#20030314T052745Z-25601-69-1-8@dirk> a :Vevent; :class "PUBLIC"; :dtend "2003-03-12T23:00:00"^^NY:tz; :dtstart "2003-03-12T11:30:00"^^NY:tz; :rrule [ :byday "SU,WE,TH,FR,SA"; :freq "WEEKLY"; :interval "1" ]; :summary "Open 11:30a-11:30p Wed-Sun". <#20030314T052656Z-25601-69-1-0@dirk> a :Vevent; :class "PUBLIC"; :dtend "2003-03-11T23:00:00"^^NY:tz; :dtstart "2003-03-11T16:00:00"^^NY:tz; :rrule [ :byday "TU"; :freq "WEEKLY"; :interval "1" ]; :summary "Open Tue 4-11p".
There is a question of whether timezone rules should be given by reference or by copy. Some data from early releases of Apple's iCal application lacked explicit VTIMEZONE components, but the specification is clear that they are required and this was acknowledged as a bug in Apple's iCal2003-03-12 and has since been fixed. So the bus-hrs.rdf file includes timezone rules:
NY:tz a :Vtimezone; :daylight [ :dtstart "1970-04-05T02:00:00"^^:dateTime; :rrule [ :byday "1SU"; :bymonth "4"; :freq "YEARLY"; :interval "1" ]; :tzname "EDT"; :tzoffsetfrom "-0500"; :tzoffsetto "-0400" ]; :standard [ :dtstart "1970-10-25T02:00:00"^^:dateTime; :rrule [ :byday "-1SU"; :bymonth "10"; :freq "YEARLY"; :interval "1" ]; :tzname "EST"; :tzoffsetfrom "-0400"; :tzoffsetto "-0500" ]; :tzid "/softwarestudio.org/Olson_20011030_5/America/New_York"; x-lic:location "America/New_York" .
While those rules are an accurate model of the timezone in New York at least as far back as 1970, the Energy Policy Act of 2005 is intended to change them in 2006. While the Olson database is likely to reflect these changes in due course, the copies in all the iCalendar data out there will fail to accurately represent the timezone rules for New York.
One approach, exemplified by the datetime design pattern in the microformats community, is to not use iCalendar timezones, but only UTC datesdelt.
Another approach is to put the timezone rules in the Web, establish change
control policies with some minimum notice, and pass timezones around by
reference. As a step in this direction, we have published each entry in a
version of the Olsen database in our RDF Calendar workspace. For example,
NY:tz
, i.e.
http://www.w3.org/2002/12/cal/tzd/America/New_York#tz
. We are
considering some way to connect this data to the relevant political
decision-making processes. Ultimately, it would be best if the respective
policitcal organizations published the data by themselves.
There are a few other issues to note from the example above, some of which are resolved:
and some of which are not:
NY:tz
timezone is used as a datatype. Earlier,
we used separate properties for time and timezone, which is initially
appealing but problematic for reasons that are detailed in the InterpretationProperties
pattern.
...2002/12/cal/ical#
schema. This design is using a
somewhat experimental2005-03-30
namespace name, ...2002/12/cal/icaltzd#
.We hope to find a consensus with a number of parties on issues around timezones and recurring events:
The iCalendar specification includes two features related to places. The location property "... defines the intended venue for the activity defined by a calendar component." That is, it gives a name of the place where the event occurs. For example:
<#20020630T230445Z-3895-69-1-7@jammer> a :Vevent; :summary "X3 Conference"; :location "San Francisco"; :description "can't wait!\n"; :dtstart "2002-07-03"^^XML:date; :dtend "2002-07-06"^^XML:date; :uid "20020630T230445Z-3895-69-1-7@jammer" .
The geo property takes a list of 2 floats: latitude and longitude. For example:
geo:CDC474D4-1393-11D7-9A2C-000393914268 a :Vevent; :summary "meeting 23"; :geo ( 40.442673 -79.945815 ); :dtstart "2003-01-08T13:00:00"^^New:tz; :dtend "2003-01-08T14:00:00"^^New:tz .
The relationship of these properties to the Basic Geo (WGS84 lat/long)
Vocabulary also in development in the Semantic Web Interest Group has
been discussed, but not conclusively. Note that location
relates
an event to the name of a place, not the place itself; likewise,
geo
relates an event to a pair of coordinates, not a place. If
we take :place
to be a property that relates an event to a place
where it occurscyc, It seems reasonable to
relate them using rules such as:
{ ?E cal:geo (?LAT ?LONG) } <=> { ?E :place [ geo:lat ?LAT; geo:long ?LONG ] }. { ?E cal:location ?TXT } <=> { ?E :place [ rdfs:label ?TXT ] }.
The vehicle for our exploration of schema and data issues is a test suite. At this point, we have a schema supported by a useful, if not complete, collection of tests and conversion tools:
$testcase.ics
file that is judged
to be a correct iCalendar file (i.e. it conforms to RFC 2445 and one or
more popular iCalendar tool consumes it correctly and/or allows the user
to produce it) and a corresponding $testcase.rdf
file that
is judged to agree. For example, cal01.ics
and
cal01.rdf
are one test case.$testcase.ics
to a
temporary $testcase-actual.rdf
file.$testcase.rdf
, the
expected results, using an RDF graph comparison tool.$testcase.rdf
to
$testcase-temp.ics
.$testcase-temp.ics
to $testcase-actual.rdf
.$test-case-actual.rdf
to the expected results,
$testcase.rdf
, using an RDF graph comparison tool.$testcase.rdf
is logically consistent with the
schema.The following table shows, for each component and property, the test case files that use that property on that type of component:
| Component | Property | Value Type | $testcase.rdf |
|---|---|---|---|
| VALARM | ACTION | TEXT | 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf, |
| VALARM | DESCRIPTION | TEXT | TestTermin.rdf, cal01.rdf, cal02.rdf, |
| VALARM | TRIGGER | DURATION | 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | ATTENDEE | CAL-ADDRESS | 20030115mtg.rdf, 20030122mtg.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | CATEGORIES | TEXT | cal01.rdf, cal02.rdf, tag-bug.rdf, |
| VEVENT | CLASS | TEXT | MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | COMMENT | TEXT | gkexample.rdf, |
| VEVENT | DESCRIPTION | TEXT | 20030205mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf, tag-bug.rdf, |
| VEVENT | DTEND | DATE-TIME | 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, mtg.rdf, openingHours.rdf, querymeetings.rdf, tag-bug.rdf, |
| VEVENT | DTSTAMP | DATE-TIME | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, |
| VEVENT | DTSTART | DATE-TIME | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, mtg.rdf, openingHours.rdf, querymeetings.rdf, tag-bug.rdf, |
| VEVENT | DURATION | DURATION | 20030115mtg.rdf, |
| VEVENT | EXDATE | DATE-TIME | tag-bug.rdf, |
| VEVENT | LAST-MODIFIED | DATE-TIME | bus-hrs.rdf, |
| VEVENT | LOCATION | TEXT | TestTermin.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | ORGANIZER | CAL-ADDRESS | 20030115mtg.rdf, 20030122mtg.rdf, TestTermin.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | PRIORITY | INTEGER | TestTermin.rdf, |
| VEVENT | RRULE | RECUR | bus-hrs.rdf, cal01.rdf, cal02.rdf, gkexample.rdf, openingHours.rdf, tag-bug.rdf, |
| VEVENT | SEQUENCE | integer | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, |
| VEVENT | SUMMARY | TEXT | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, tag-bug.rdf, |
| VEVENT | TRANSP | TEXT | TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, |
| VEVENT | UID | TEXT | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, MozexportAsCalendar.rdf, TestTermin.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, tag-bug.rdf, |
| VTIMEZONE | LAST-MODIFIED | DATE-TIME | Todos1.rdf, |
| VTIMEZONE | TZID | TEXT | 20030115mtg.rdf, 20030122mtg.rdf, 20030205mtg.rdf, 20030212mtg.rdf, 20030226mtg.rdf, 20030312mtg.rdf, 20030326mtg.rdf, 20030409mtg.rdf, 20030410querymtg.rdf, 20030416geomtg.rdf, 20030423mtg.rdf, Chiefs.rdf, Todos1.rdf, bus-hrs.rdf, cal01.rdf, cal02.rdf, mtg.rdf, querymeetings.rdf, |
| VTODO | COMPLETED | DATE-TIME | Todos1.rdf, |
| VTODO | DTSTAMP | DATE-TIME | Todos1.rdf, |
| VTODO | DTSTART | DATE-TIME | Todos1.rdf, |
| VTODO | DUE | DATE-TIME | Todos1.rdf, |
| VTODO | PRIORITY | INTEGER | Todos1.rdf, |
| VTODO | SEQUENCE | integer | Todos1.rdf, |
| VTODO | STATUS | TEXT | Todos1.rdf, |
| VTODO | SUMMARY | TEXT | Todos1.rdf, |
| VTODO | UID | TEXT | Todos1.rdf, |
There are a number of related calendar data format projects.
XCalendar is a simple syntactic conversion of iCalendar to XML. For events with simple attribute-value properties it produces results very similar to RDF case; the differences are syntactic (capitalization) or have to do with the model RDF imposes.
An XSLT transformation from xCalendar to iCalendar is provided.
We have considered a syntactic profile of RDF calendar that would meet the same requirements, but we have not managed to develop a tool to produce this profile given an arbitrary RDF calendar graph as input.
RSS Events is a proposed module for RSS 1.0. It uses a simple vocabulary inspired by iCalendar:
<item rdf:about="http://conferences.oreilly.com/p2p/"> <title>The O'Reilly Peer-to-Peer and Web Services Conference</title> <link>http://conferences.oreilly.com/p2p/</link> <ev:type>conference</ev:type> <ev:organizer>O'Reilly</ev:organizer> <ev:location>Washington, DC</ev:location> <ev:startdate>2001-09-18</ev:startdate> <ev:enddate>2001-09-21</ev:enddate> </item>
It uses the homepage of an event as the url for the description of the event.
While the RDF Calendar vocabulary is still a work-in-progress, it provides anyone with RDF or XML tools a useful alternative to dealing with the character-level syntax of iCalendar. Our test-driven approach to Semantic Web vocabulary development has allowed us to manage changes as we explored and resolved a variety of issues. The "subject to change with notice and appeal" change policy for our schema seems to work well.
We have exploited the graph model of RDF in our round-trip testing work, but explorations into comparisons, especially for the purpose of synchronizing changes, are at an early stage. See Delta: an ontology for the distribution of differences between RDF graphs for one approach.
We are still in relatively early stages of mixing calendar data with other Semantic Web data. As an illustrative example, consider using the FOAF vocabulary to describe an attendee of an event:
[] a :Vevent ; :attendee [ a foaf:Person ; :calAddress<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>; foaf:name "My name" ] ; :dtend "2002-06-30T10:30:00"^^NY:tz ; :dtstart "2002-06-30T09:00:00"^^NY:tz ; :summary "Tree Conference" .
The iCalendar specification has some prohibitions against publishing email addresses. This is one of many privacy considerations with calendar data.
Queries and rules to relate photos to events via metadata such as date-taken is another promising area of work.
hCalendar is an emerging microformat, i.e. a set of semantic XHTML markup conventions. It is based on iCalendar. The approach to human-readability is interesting; for example:
October 5
We are working on a glean-hcal.xsl, a transformation from hCalendar to RDF Calendar. Using hCalendar with GRDDL is particularly promising, though it goes beyond the scope of this report.
Note that open source implementaitons of the following transformations are available, either from the RDF Calendar workspace or projects nearby:
| from iCalendar | hCalendar | RDF Calendar | |
|---|---|---|---|
| to iCalendar | X2V | toIcal.py | |
| hCalendar | |||
| RDF Calendar | fromIcal.py | glean-hcal.xsl |
We are greatful to Masahide Kanzaki for his RDF calendar service, to Olivier Gutknecht and Paul Cowles for their commercial product development perspective, and the collaborators in www-rdf-calendar, including Julian Reschke, Doug Royer, Tim Berners-Lee, Dave Thewlis, Karl Dubost, Charles McCathieNevile, Michael Arick, Norman Walsh, Tim Hare, and Dan Brickley.


Contoso
Validate data
Description of the action this button takes
Submit data
Description of the action this button takes
Find more samples online...


fun Range(start: Int, amount: Int): ArrayList<Int>
Generates a sequence of amount integers starting with value start
start
amount


--- layout: doco title: "MicroView Arduino Library - MVSPIClass Class Reference" category: API description: "MicroView Arduino Library Documentation" tags: [microview, library, functions, documentation] comments: true ---
Static Public Member Functions | |
| static void | wait () |
| Wait for SPI serial transfer complete. | |
| static void | transfer (byte _data) |
| Transfer data byte via SPI port. | |
| static void | packetBegin () |
| Set up to begin a SPI packet transmit. More... | |
| static void | packetEnd () |
| End a SPI packet transmit. More... | |
| static void | attachInterrupt () |
| static void | detachInterrupt () |
| static void | begin () |
| SPI Initialisation. More... | |
| static void | end () |
| End SPI. | |
| static void | setBitOrder (uint8_t) |
| Set SPI bit order. More... | |
| static void | setDataMode (uint8_t) |
| Set SPI data mode. More... | |
| static void | setClockDivider (uint8_t) |
| Set clock divider. More... | |
|
static |
SPI Initialisation.
Setup SCK, MOSI, SS and DC pins for SPI transmission.
|
static |
Set up to begin a SPI packet transmit.
Set up SPI for transmitting.
Pepare the SPI interface for transmitting on or more bytes of commands and/or data.
|
static |
End a SPI packet transmit.
End a SPI packet transmission.
End a SPI packet transmission:
|
static |
Set SPI bit order.
Set SPI port bit order with LSBFIRST or MSBFIRST.
|
static |
Set clock divider.
Set the clocl divider of the SPI, default is 4Mhz.
rate: SPI_CLOCK_DIV2 SPI_CLOCK_DIV4 SPI_CLOCK_DIV8 SPI_CLOCK_DIV16 SPI_CLOCK_DIV32 SPI_CLOCK_DIV64 SPI_CLOCK_DIV128
|
static |
Set SPI data mode.
Set the SPI data mode: clock polarity and phase. mode - SPI_MODE0, SPI_MODE1, SPI_MODE2, SPI_MODE3.


This div has a static position.
This div has a relative position with a top of 20px and 50 px left from the first div.
This div has an absolute position, with a top of 240px and left 30px.
This div has a fixed position, with a top of 100px and left 200px.


6 Curricular Requirements
The College Board Syllabus Development Guide lists the following curricular requirements for AP Research:
CR1a: Students develop and apply discrete skills identified in the learning objectives within the Big Idea 1: Question and Explore.
CR1b: Students develop and apply discrete skills identified in the learning objectives within the Big Idea 2: Understand and Analyze.
CR1c: Students develop and apply discrete skills identified in the learning objectives within the Big Idea 3: Evaluate Multiple Perspectives.
CR1d: Students develop and apply discrete skills identified in the learning objectives within the Big Idea 4: Synthesize Ideas.
CR1e: Students develop and apply collaboration skills identified in the learning objectives within the Big Idea 5: Team, Transform, and Transmit.
CR1f: Students develop and apply reflection skills identified in the learning objectives within the Big Idea 5: Team, Transform, and Transmit.
CR1g: Students develop and apply written and oral communication skills identified in the learning objectives within the Big Idea 5: Team, Transform, and Transmit.
CR2a: Students develop an understanding of ethical research practices.
CR2b: Students develop an understanding of the AP Capstone Policy on Plagiarism and Falsification or Fabrication of Information.
CR3: In the classroom and independently (while possibly consulting any expert advisors), students learn and employ research and inquiry methods to develop, manage, and conduct an in-depth investigation of an area of personal interest, culminating in an academic paper of 4,000-5,000 words that includes the following elements:
- Introduction
- Method, Process, or Approach
- Results, Product, or Findings
- Discussion, Analysis, and/or Evaluation
- Conclusion and Future Directions
- Bibliography
CR4a: Students document their inquiry processes, communicate with their teachers and any expert advisors, and reflect on their thought processes.
CR4b: Students have regular work-in-progress interviews with their teachers to review their progress and to receive feedback on their scholarly work as evidenced by the PREP.
CR5: Students develop and deliver a presentation (using an appropriate medium) and an oral defense to a panel on their research processes, method, and findings (College Board, n.d.).
References
College Board. (n.d.). Syllabus Development Guide: AP Research. https://secure-media.collegeboard.org/digitalServices/pdf/ap/ap-course-audit/ap-research-syllabus-development-guide.pdf.


James Lundblad of the Ptolemy group is developing the ACS domain with Sanders, a Lockheed Martin company.
A key feature of the ACS domain is to make it easier to generate different implementations of a simulation. The ACS domain uses the Corona/Core approach, which was created by Jose Pino and Tom Parks while they were at UC Berkeley. In the Corona/Core design, a star has one Interface, named the Corona, and one or more implementations, named Cores.
The ACS domain will help in automating the FPGA design process; it will help in transforming an SDF graph into a reasonable FPGA implementation. Initially, an Annapolis Microsystems Wildforce board will be the target.
Sanders has a web page describing the project at:
http://www.sanders.com/adv_tech/aam.htm
The Adaptive Computing Systems (ACS) Domain uses a different style of
star than the rest of Ptolemy. ACS splits a star into a single
interface (called a Corona), and one or more implementations, called
Cores.


Consider the class Student below.
Create an instance of the class Student.
Create another instance and give the student the name "Alice", who has 65 books.
You also want to create a student called "Burt" with 32 books.


org.monte.media.math
Class ExtendedReal
java.lang.Object
java.lang.Number
org.monte.media.math.ExtendedReal
- All Implemented Interfaces:
- java.io.Serializable
public class ExtendedReal
- extends java.lang.Number
Represents an extended-real number as specified by IEEE 754.
An extended-real number uses 80 bits to represent a floating point
number. It is able to represent numbers ranging from 3.37*10^-4932
up to 1.18*10^4932.
Bit layout
79 78-64 63 62-0
Sign Biased Exponent Integer Fraction
For the single-real and double-real formats, only the fraction part
of the significand is encoded. The integer is assumed to be 1 for
all numbers except 0 and denormalized finite numbers. For the
extended-real format, the integer is contained in bit 64, and the
most significant fraction bit is bit 62. Here, the integer is
explicitly set to 1 for normalized numbers, infinites, and NaNs,
and to 0 for zero and denormalized numbers.
The exponent is encoded in biased format. The biasing constant is
16'383 for the extended-real format.

- Version:
- 0.1 2000-10-06 Conversions from bit array, and to double only.
- Author:
- Werner Randelshofer, Hausmatt 10, CH-6405 Goldau, Switzerland.
- See Also:
- Serialized Form
| Methods inherited from class java.lang.Number |
byteValue, shortValue |
| Methods inherited from class java.lang.Object |
clone, finalize, getClass, notify, notifyAll, wait, wait, wait |
MAX_VALUE
public static final ExtendedReal MAX_VALUE
MIN_VALUE
public static final ExtendedReal MIN_VALUE
NaN
public static final ExtendedReal NaN
NEGATIVE_INFINITY
public static final ExtendedReal NEGATIVE_INFINITY
POSITIVE_INFINITY
public static final ExtendedReal POSITIVE_INFINITY
ExtendedReal
public ExtendedReal(byte[] bits)
ExtendedReal
public ExtendedReal(double d)
isNaN
public boolean isNaN()
isInfinite
public boolean isInfinite()
doubleValue
public double doubleValue()
- Specified by:
doubleValue
in class java.lang.Number
floatValue
public float floatValue()
- Specified by:
floatValue
in class java.lang.Number
intValue
public int intValue()
- Specified by:
intValue
in class java.lang.Number
longValue
public long longValue()
- Specified by:
longValue
in class java.lang.Number
hashCode
public int hashCode()
- Overrides:
hashCode
in class java.lang.Object
equals
public boolean equals(java.lang.Object obj)
- Overrides:
equals
in class java.lang.Object
equals
public boolean equals(ExtendedReal obj)
toString
public java.lang.String toString()
- FIXME: Loss of precision, because we currently convert to double before
we create the String.
- Overrides:
toString
in class java.lang.Object


First Name (required)
Last Name (required)
Email (required)
Phone (Mobile)
Phone (Work)
Address
Twitter
Save Back


home
|
about
|
sponsors
|
calendar
| resources |
contact
Resources
We are working on compiling a list of resources for those interested in all things Icelandic. If you have something to add, visit the
contact
page and send us an email!
Icelandic Language
Food and Cooking
Travel


| Application Date | {{ enrolment.appliedDate | formatDate }} | Name | {{ enrolment.enrollee.firstName }} {{ enrolment.enrollee.lastName }} | Status |
|
Approval Date | {{ enrolment.approvedDate | formatDate }} |
|
|---|
No {{ filteredStatus?.name }} Enrolments


Barry
Barry is a dark comedy about a depressed, low-rent hitman from the Midwest. Lonely and dissatisfied in his life, he reluctantly travels to Los Angeles to execute a hit on an aspiring actor. Barry follows his "mark" into an acting class and ends up finding an accepting community in a group of eager hopefuls within the LA theater scene. He wants to start a new life as an actor, but his criminal past won't let him walk away - can he find a way to balance both worlds?


{% extends "metasearch/base.html" %} {% block title %}Page not found -- MetaSearch{% endblock %} {% block content %}
OOPS... It seems that the requested page could not be found. Have you entered the right URL? Go back to start page


Since my DreamHost hosting is out-of-date, I moved SQYBI.com to Linode VPS. However it will take a period of time to write a new blog application and import old data. Please be patient, SQYBI.com will come back!
You may be interested in this: SQYBI.com @ Github


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.apache.xml.dtm.ref.CoroutineManager
public class CoroutineManager
Support the coroutine design pattern.
A coroutine set is a very simple cooperative non-preemptive multitasking model, where the switch from one task to another is performed via an explicit request. Coroutines interact according to the following rules:
Coroutines can be thought of as falling somewhere between pipes and subroutines. Like call/return, there is an explicit flow of control from one coroutine to another. Like pipes, neither coroutine is actually "in charge", and neither must exit in order to transfer control to the other.
One classic application of coroutines is in compilers, where both the parser and the lexer are maintaining complex state information. The parser resumes the lexer to process incoming characters into lexical tokens, and the lexer resumes the parser when it has reached a point at which it has a reliably interpreted set of tokens available for semantic processing. Structuring this as call-and-return would require saving and restoring a considerable amount of state each time. Structuring it as two tasks connected by a queue may involve higher overhead (in systems which can optimize the coroutine metaphor), isn't necessarily as clear in intent, may have trouble handling cases where data flows in both directions, and may not handle some of the more complex cases where more than two coroutines are involved.
Most coroutine systems also provide a way to pass data between the source and target of a resume operation; this is sometimes referred to as "yielding" a value. Others rely on the fact that, since only one member of a coroutine set is running at a time and does not lose control until it chooses to do so, data structures may be directly shared between them with only minimal precautions.
"Note: This should not be taken to mean that producer/consumer problems should be always be done with coroutines." Queueing is often a better solution when only two threads of execution are involved and full two-way handshaking is not required. It's a bit difficult to find short pedagogical examples that require coroutines for a clear solution.
The fact that only one of a group of coroutines is running at a time, and the control transfer between them is explicit, simplifies their possible interactions, and in some implementations permits them to be implemented more efficiently than general multitasking. In some situations, coroutines can be compiled out entirely; in others, they may only require a few instructions more than a simple function call.
This version is built on top of standard Java threading, since that's all we have available right now. It's been encapsulated for code clarity and possible future optimization.
(Two possible approaches: wait-notify based and queue-based. Some folks think that a one-item queue is a cleaner solution because it's more abstract -- but since coroutine _is_ an abstraction I'm not really worried about that; folks should be able to switch this code without concern.)
%TBD% THIS SHOULD BE AN INTERFACE, to facilitate building other implementations... perhaps including a true coroutine system someday, rather than controlled threading. Arguably Coroutine itself should be an interface much like Runnable, but I think that can be built on top of this.
| Field Summary | |
|---|---|
(package private) static int |
ANYBODY
|
(package private) java.util.BitSet |
m_activeIDs
"Is this coroutine ID number already in use" lookup table. |
(package private) int |
m_nextCoroutine
Internal field used to confirm that the coroutine now waking up is in fact the one we intended to resume. |
(package private) static int |
m_unreasonableId
Limit on the coroutine ID numbers accepted. |
(package private) java.lang.Object |
m_yield
Internal field used to hold the data being explicitly passed from one coroutine to another during a co_resume() operation. |
(package private) static int |
NOBODY
|
| Constructor Summary | |
|---|---|
CoroutineManager()
|
| Method Summary | |
|---|---|
java.lang.Object |
co_entry_pause(int thisCoroutine)
In the standard coroutine architecture, coroutines are identified by their method names and are launched and run up to their first yield by simply resuming them; its's presumed that this recognizes the not-already-running case and does the right thing. |
void |
co_exit_to(java.lang.Object arg_object,
int thisCoroutine,
int toCoroutine)
Make the ID available for reuse and terminate this coroutine, transferring control to the specified coroutine. |
void |
co_exit(int thisCoroutine)
Terminate this entire set of coroutines. |
int |
co_joinCoroutineSet(int coroutineID)
Each coroutine in the set managed by a single CoroutineManager is identified by a small positive integer. |
java.lang.Object |
co_resume(java.lang.Object arg_object,
int thisCoroutine,
int toCoroutine)
Transfer control to another coroutine which has already been started and is waiting on this CoroutineManager. |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
|---|
java.util.BitSet m_activeIDs
static final int m_unreasonableId
java.lang.Object m_yield
static final int NOBODY
static final int ANYBODY
int m_nextCoroutine
| Constructor Detail |
|---|
public CoroutineManager()
| Method Detail |
|---|
public int co_joinCoroutineSet(int coroutineID)
Each coroutine in the set managed by a single CoroutineManager is identified by a small positive integer. This brings up the question of how to manage those integers to avoid reuse... since if two coroutines use the same ID number, resuming that ID could resume either. I can see arguments for either allowing applications to select their own numbers (they may want to declare mnemonics via manefest constants) or generating numbers on demand. This routine's intended to support both approaches.
%REVIEW% We could use an object as the identifier. Not sure it's a net gain, though it would allow the thread to be its own ID. Ponder.
coroutineID
- If >=0, requests that we reserve this number.
If <0, requests that we find, reserve, and return an available ID
number.
public java.lang.Object co_entry_pause(int thisCoroutine) throws java.lang.NoSuchMethodException
thisCoroutine
- the identifier of this coroutine, so we can
recognize when we are being resumed.
java.lang.NoSuchMethodException
- if thisCoroutine isn't
a registered member of this group. %REVIEW% whether this is the
best choice.public java.lang.Object co_resume(java.lang.Object arg_object, int thisCoroutine, int toCoroutine) throws java.lang.NoSuchMethodException
arg_object
- A value to be passed to the other coroutine.thisCoroutine
- Integer identifier for this coroutine. This is the
ID we watch for to see if we're the ones being resumed.toCoroutine
- Integer identifier for the coroutine we wish to
invoke.
java.lang.NoSuchMethodException
- if toCoroutine isn't a
registered member of this group. %REVIEW% whether this is the best choice.public void co_exit(int thisCoroutine)
thisCoroutine
- Integer identifier for the coroutine requesting exit.public void co_exit_to(java.lang.Object arg_object, int thisCoroutine, int toCoroutine) throws java.lang.NoSuchMethodException
arg_object
- A value to be passed to the other coroutine.thisCoroutine
- Integer identifier for the coroutine leaving the set.toCoroutine
- Integer identifier for the coroutine we wish to
invoke.
java.lang.NoSuchMethodException
- if toCoroutine isn't a
registered member of this group. %REVIEW% whether this is the best choice.
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |