Implements a track index for maintaining links between feature point observations in a video sequence.
More...
|
| | TrackIndex () |
| |
| | ~TrackIndex () |
| |
| void | setMaxNumFrames (size_t n) |
| | Set the maximum number of frames to manage. More...
|
| |
| size_t | maxNumFrames () const |
| |
| void | add (frame_id_t id, double timestamp, const matches_t &matches, const std::vector< FeaturePoint > &points) |
| | Add observations from the current frame. More...
|
| |
| void | add (frame_id_t id, double timestamp, const matches_t &matches, const std::vector< FeaturePoint > &points, TrackIndexIdGenerator &track_index_id_generator) |
| |
| void | incrementKeyframeCount () |
| | Should be called when a keyframe is added to the track index. More...
|
| |
| void | decrementKeyframeCount () |
| | Decrement keyframe count. More...
|
| |
| void | setCurrentKeyframe () |
| | Set current frame as keyframe. More...
|
| |
| void | voidCurrentKeyframe () |
| | Void the current keyframe. More...
|
| |
| void | correspondences (std::vector< track_t * > &tracks, std::vector< const FeaturePoint * > &pa, std::vector< const FeaturePoint * > &pb, size_t a, size_t b, size_t min_length, bool use_triangulated_only=false) |
| | Get the correspondences between two frames in the frame buffer. More...
|
| |
| void | correspondences (std::vector< track_t * > &tracks, std::vector< const FeaturePoint * > &pa, std::vector< const FeaturePoint * > &pb, std::vector< const FeaturePoint * > &pc, size_t a, size_t b, size_t c, size_t min_length, bool use_triangulated_only=false) |
| | Get the triple correspondences between three frames in the frame buffer. More...
|
| |
| void | tracks (std::vector< track_t * > &tracks, std::vector< std::vector< const FeaturePoint * > > &track_points, size_t k, size_t length) |
| | Get all the tracks up to frame (t-k) where t is the most recent frame. More...
|
| |
| size_t | numFrames () const |
| | Get the number of frames in the buffer. More...
|
| |
| frame_t & | frame (size_t i) |
| | Get a frame. More...
|
| |
| frame_t & | frame_from_current (size_t n) |
| | Get a frame N frames back from current frame. More...
|
| |
| frame_t & | current () |
| | Get the most recent frame. More...
|
| |
| void | clear () |
| | Clear the index. More...
|
| |
| void | debug_print (const std::string &dir, const std::string &filename) |
| |
Implements a track index for maintaining links between feature point observations in a video sequence.
It can manage an arbitrary number of tracks. The number of frames to manage can be restricted for memory utilization. The correspondences between any pair of frames can be queried.
| void TrackIndex::correspondences |
( |
std::vector< track_t * > & |
tracks, |
|
|
std::vector< const FeaturePoint * > & |
pa, |
|
|
std::vector< const FeaturePoint * > & |
pb, |
|
|
size_t |
a, |
|
|
size_t |
b, |
|
|
size_t |
min_length, |
|
|
bool |
use_triangulated_only = false |
|
) |
| |
Get the correspondences between two frames in the frame buffer.
The time complexity is linear with the number of tracks at frame (t-a).
- Parameters
-
| [out] | pa | Point for frame (t-a) |
| [out] | pb | Point for frame (t-b) |
| [in] | a | Relative index of frame (t-a) |
| [in] | b | Relative index of frame (t-b) |
The two frames are indexed by the variables (a,b). The most recent (current) frame "t" is at index 0. The variables (a,b) are relative to the current frame so that (t-a,t-b) are the two frames where correspondences are requested such that a < b.
| void TrackIndex::correspondences |
( |
std::vector< track_t * > & |
tracks, |
|
|
std::vector< const FeaturePoint * > & |
pa, |
|
|
std::vector< const FeaturePoint * > & |
pb, |
|
|
std::vector< const FeaturePoint * > & |
pc, |
|
|
size_t |
a, |
|
|
size_t |
b, |
|
|
size_t |
c, |
|
|
size_t |
min_length, |
|
|
bool |
use_triangulated_only = false |
|
) |
| |
Get the triple correspondences between three frames in the frame buffer.
T *
- Parameters
-
| [out] | pa | Point for frame (t-a) |
| [out] | pb | Point for frame (t-b) |
| [out] | pc | Point for frame (t-c) |
| [in] | a | Relative index of frame (t-a) |
| [in] | b | Relative index of frame (t-b) |
| [in] | c | Relative index of frame (t-c) |
The three frames are indexed by the variables (a,b,c). The most recent (current) frame "t" is at index 0. The variables (a,b,c) are relative to the current frame so that (t-a,t-b,t-c) are the three frames where correspondences are requested such that a < b < c.


Empty and zero inputs will not be used
Use enter and tab to navigate inputs
We've limited you to 10 inputs because this algorithm calculates at 3n, or in other words it gets three times slower every input. This is because we check every single combination of positive, negative, and zero for each input.
V.1.1.0


I see that some plugins doesn't work as expected anymore.
So, this can be related to removed/changed functions in BBLog.
Important:
All technical changes will always be in the last DEV Version of BBLog before the live release so there is time (mostly 1-2 weeks) to check your plugin against new changes and fix problems if there be some.
There is always a topic where you can see when a new DEV version has released.
Here a list of technical things that have been changed in BBLog 4.0.0
* BBLog.alert() have been removed - BBLog natively don't need it anymore - Use BBLog.popup() instead.
* BBLog.prompt() have been removed - BBLog natively don't need it anymore - Use BBLog.popup() instead.


Nodes represent validators in the Stellar consensus network. Node colors indicate the node's status in the last observed ledger. Larger validators have more nodes depending on them for validation. Edges eminating from a node point toward the validators in that node's quorum set.


May 11, 2020
4 mins read
As a plant biologist I routinely generate a lot of seed from the plants I grow and study. Pricipally at the moment this is the seed of Arabidopsis thaliana which is very small. To keep on top of things I catalogue all my seeds and keep a spreadsheet of all my seed. The spreadsheet looks a little like this:
| Sowing_number | Species | Genotype | Vector | Date_harvested | Parent | Comment |
|---|---|---|---|---|---|---|
| A010 | Arabidopsis thaliana | Ra-0 | NA | 22/01/20 | NA | NA |
| A011 | Arabidopsis thaliana | Ct-1 | NA | 22/01/20 | NA | NA |
| A012 | Arabidopsis thaliana | Mz-0 | NA | 22/01/20 | NA | NA |
| A014 | Arabidopsis thaliana | HR-10 | NA | 22/01/20 | NA | NA |
| A015 | Arabidopsis thaliana | NFA-10 | NA | 22/01/20 | NA | NA |
| A016 | Arabidopsis thaliana | Gu-0 | NA | 22/01/20 | NA | NA |
| A018 | Arabidopsis thaliana | Sq-8 | NA | 22/01/20 | NA | NA |
This serves me well as a seed registry and corresponds to a box in my fridge where I have been storing the actual seed in 1.5 ml microcentrifuge tubes. Largly out of convinience as I use the tubes for everything and also because that is what I did in my previous lab where A. thaliana was not the main study system. However I’ve noticed that others in my lab store their A. thaliana seed in little paper packets which I think are more space efficient and may be a better storage environment if there is any moisture present. A fellow postdoc has made nice labels for all of their seed packets so I though I might too. Thus I set out to do just this!
Starting from my seed spreadsheet, which is accessible as a CSV file, I figured python would be a good tool to use and I found this neat open source library called blabel which does what I want. Essentially I just have to load the CSV file, convert it to a list of dictionaries where each dictionary represents a row and blabel does the rest. It is very flexible as it takes a HTML file to determine the size and layout of the label and a CSS file is provided to style it. I generally follow the example style. The output is a label for each row as a page of a PDF. I wrapped this into a self contained python script I call make_labels.py
(avaliable at the end of the post).
I can implement it like so:
python make_labels.py -i seed_data.csv
This is great! and produces a PDF with each page being a label. These are generally very small and I am sure they are very useful if you have a label printer. However I do not so I would like to aglomerate them all onto A4 pieces of paper I can print out, cut up and stick to my seed packets. This Stack Exchange question led me to a shell script utility called pdfjam and I found that the deprecated pdfnup script does what I’m after if I implement it like this:
bash pdfnup.sh output.pdf --nup 5x8
This fits my needs as I usually harvest seeds in batches. I will need to test them out on the printer and maybe reduce the number on a page to avoid the margins but essentially from here on I can generate new labels as I need them by feeding the make_labels.py
script new rows from my seed spreadsheet. I will then just stick them to the seed packets.
This is the make_labels.py
script:
#! /usr/bin/env python
import click
import pandas as pd
from blabel import LabelWriter
@click.command()
@click.option('-i', '--input', required=True, type=str, help="CSV file with columns that match the variables in the HTML template")
@click.option('-o', '--output', default="output.pdf", type=str, help="Name of the output PDF")
@click.option('-t', '--template', default="item_template.html", type=str, help="Name of the HTML template file", show_default="item_template.html")
@click.option('-s', '--style', default="style.css", type=str, help="Name of the CSS file", show_default="style.css")
def write_labels(input, output, template, style):
df = pd.read_csv(input)
records = df.to_dict('records')
label_writer = LabelWriter(template, default_stylesheets=(style,))
label_writer.write_labels(records, target=output)
if __name__ == '__main__':
write_labels()
This is the HTML file called item_template.html
:

Sowing number: {{ Sowing_number }}

Genotype: {{ Genotype }}

Vector: {{ Vector }}

Comment: {{ Comment }}

Date harvested: {{ Date_harvested }}

This is the CSS style.css
file:
@page {
width: 36mm;
height: 14mm;
padding: 0.5mm;
}
.label {
font-family: Verdana;
font-weight: bold;
vertical-align: middle;
display: inline-block;
font-size: 7px;
}


Bank
a
...First mobile banking solution
New Bank Account
View All Accounts
Pay Bills
Settings
Log out
Search Account ID
Search
Welcome ${user}
Create
New Bank Account
Select Account Type:
Select any...
Current
Savings
This account would serve?
Organization:
SME:
Personal:
${new account id: autogen}
Password:
By creating an account, you agree to our
Account terms and conditions
Create Bank Account


You can only play a card which has the same color/number/symbol with the card in the center.
Draw Two Card (+2)
Draw Two cards (labelled +2) forces the next player to draw two cards and forfeit his/her
turn.
Reverse Card
Reverse cards reverses the flow of the game.
Skip Card
Skip cards jumps the next player of the cicle, and the player next to him plays.
Wild Card
Wild cards are cards that can alter the color during the play.
Wild Draw Four Card (+4)
Wild Draw Four cards (labelled +4) are basically a wild card and two Draw Two cards.
The user can alter the color during the play, and the next player is forced to draw four
cards and forfeit his/her turn.
Counters
Draw Two cards and Wild Draw Four cards can be stacked if you have a compatible card.
For example: if a player plays a Draw Two card at you, you can counter with another Draw
Two card, or a Draw Four card. If the player don't have such a card, he/she draws the total
number of draws involved in the process.
OBS.: A Draw Two card can be stacked with either another Draw Two or a Draw Four.
Otherwise, a Draw Four card can only be stacked with another Draw Four.


--- layout: post title: 'sed: change only first occurance of a term in a file' date: 2011-03-16 22:06:17.000000000 +00:00 type: post parent_id: '0' published: true password: '' status: publish categories: - bash tags: [] meta: _edit_last: '1' author: Noel permalink: "/sed-change-only-first-occurance-of-a-term-in-a-file/" ---
So in the example here, we look for the first line beginning with ALERT and puts 2 return chars after the line
sed -r '0,/(^ALERT.*)/s//\1\n\n/'


Class: Aws::StorageGateway::Types::ActivateGatewayInput
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
self,
Struct
|
|
|
Instance Chain:
self,
::Aws::Structure ,
Struct
|
|
| Inherits: |
Struct
|
| Defined in: | gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb |
Overview
A JSON object containing one or more of the following fields:
ActivateGatewayInput$ActivationKey
ActivateGatewayInput$GatewayName
ActivateGatewayInput$GatewayRegion
ActivateGatewayInput$GatewayTimezone
ActivateGatewayInput$GatewayType
ActivateGatewayInput$MediumChangerType
ActivateGatewayInput$TapeDriveType
Constant Summary
Instance Attribute Summary
-
#activation_key ⇒ String
rw
Your gateway activation key.
-
#gateway_name ⇒ String
rw
The name you configured for your gateway.
-
#gateway_region ⇒ String
rw
A value that indicates the Amazon Web Services Region where you want to store your data.
-
#gateway_timezone ⇒ String
rw
A value that indicates the time zone you want to set for the gateway.
-
#gateway_type ⇒ String
rw
A value that defines the type of gateway to activate.
-
#medium_changer_type ⇒ String
rw
The value that indicates the type of medium changer to use for tape gateway.
-
#tags ⇒ Array<Types::Tag>
rw
A list of up to 50 tags that you can assign to the gateway.
-
#tape_drive_type ⇒ String
rw
The value that indicates the type of tape drive to use for tape gateway.
Instance Method Summary
::Aws::Structure
- Included
| #to_hash | Alias for Aws::Structure#to_h. |
Instance Attribute Details
#activation_key ⇒ String
(rw)
Your gateway activation key. You can obtain the activation key by
sending an HTTP GET request with redirects enabled to the gateway IP
address (port 80). The redirect URL returned in the response
provides you the activation key for your gateway in the query string
parameter activationKey
. It may also include other
activation-related parameters, however, these are merely defaults --
the arguments you pass to the ActivateGateway
API call determine
the actual configuration of your gateway.
For more information, see Getting activation key in the Storage Gateway User Guide.
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#gateway_name ⇒ String
(rw)
The name you configured for your gateway.
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#gateway_region ⇒ String
(rw)
A value that indicates the Amazon Web Services Region where you want
to store your data. The gateway Amazon Web Services Region specified
must be the same Amazon Web Services Region as the Amazon Web
Services Region in your Host
header in the request. For more
information about available Amazon Web Services Regions and
endpoints for Storage Gateway, see Storage Gateway endpoints and
quotas in the Amazon Web Services General Reference.
Valid Values: See Storage Gateway endpoints and quotas in the Amazon Web Services General Reference.
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#gateway_timezone ⇒ String
(rw)
A value that indicates the time zone you want to set for the gateway. The time zone is of the format "GMT-hr:mm" or "GMT+hr:mm". For example, GMT-4:00 indicates the time is 4 hours behind GMT. GMT+2:00 indicates the time is 2 hours ahead of GMT. The time zone is used, for example, for scheduling snapshots and your gateway's maintenance schedule.
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#gateway_type ⇒ String
(rw)
A value that defines the type of gateway to activate. The type
specified is critical to all later functions of the gateway and
cannot be changed after activation. The default value is CACHED
.
Valid Values: STORED
| CACHED
| VTL
| VTL_SNOW
|
FILE_S3
| FILE_FSX_SMB
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#medium_changer_type ⇒ String
(rw)
The value that indicates the type of medium changer to use for tape gateway. This field is optional.
Valid Values: STK-L700
| AWS-Gateway-VTL
| IBM-03584L32-0402
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#tags ⇒ Array
<Types::Tag> (rw)
A list of up to 50 tags that you can assign to the gateway. Each tag is a key-value pair.
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end
#tape_drive_type ⇒ String
(rw)
The value that indicates the type of tape drive to use for tape gateway. This field is optional.
Valid Values: IBM-ULT3580-TD5
# File 'gems/aws-sdk-storagegateway/lib/aws-sdk-storagegateway/types.rb', line 115
class ActivateGatewayInput < Struct.new( :activation_key, :gateway_name, :gateway_timezone, :gateway_region, :gateway_type, :tape_drive_type, :medium_changer_type, : ) SENSITIVE = [] include Aws::Structure end


Unsplash Home
Unsplash
Photos for everyone
Home
Link 1
Link 2
Action
Another action
Something else here
Search
Submit a photo
Login
Sign up
Unsplash
The internet´s source of freely-usable images.
Powered by creators everywhere.


RZA, PETA Launching Vegan Winter Puffer Jacket Made With Recycled Ocean Plastic
RZA and PETA have teamed up on a new jacket lined with recycled ocean plastic.
by Ryan MiddletonRZA is here for the environment. He has launched a vegan winter jacket made from recycled ocean plastic.
The Wu-Tang Clan member has teamed up with PETA to make a new puffer jacket for the winter to keep you warm and feeling good about your shopping choices.
“As we evolve as a people through technology and ingenuity, we have the ability through humane ways to fashion garments that not only serve our purpose but also, more importantly, abandon the unnecessary cruelty to animals,” RZA said in a statement.
Inspired by 90’s puffer jackets, this uses recycled ocean plastic instead of geese down. The inside of the jacket is inspired by a wild weapon – the flying guillotine. The jacket is called the Flying Guillotine Puffer Jacket as the neck area reads “OUR HEADS NO LONGER BELONG TO US."
Only 100 of these are available for purchase and cost $336 a piece.


|
lwIP
2.1.3
Lightweight IP stack
|
Data Fields | |
| ip_addr_t | source_addr |
| u16_t | recv_unicast |
| struct netif * | netif |
| struct pbuf * | pbuf |
| u16_t | parse_offset |
| u16_t | tx_id |
| u16_t | questions |
| u16_t | questions_left |
| u16_t | answers |
| u16_t | answers_left |
Information about received packet
| u16_t mdns_packet::answers |
Number of answers in packet, (sum of normal, authoritative and additional answers) read from packet header
| u16_t mdns_packet::answers_left |
Number of unparsed answers
| struct netif* mdns_packet::netif |
Netif that received the packet
| u16_t mdns_packet::parse_offset |
Current parsing offset in packet
| struct pbuf* mdns_packet::pbuf |
Packet data
| u16_t mdns_packet::questions |
Number of questions in packet, read from packet header
| u16_t mdns_packet::questions_left |
Number of unparsed questions
| u16_t mdns_packet::recv_unicast |
If packet was received unicast
| ip_addr_t mdns_packet::source_addr |
Sender IP/port
| u16_t mdns_packet::tx_id |
Identifier. Used in legacy queries


Copyright © 2011 Joshua Shinavier. Some rights reserved.
RDFAgents is a messaging protocol for real-time, peer-to-peer knowledge sharing on the Semantic Web. It is patterned after, and designed to interoperate with Linked Data, but extends Linked Data principles to support a "word of mouth" style of information discovery over a variety of communications protocols. It is geared towards ubiquitous Semantic Web computing, lightweight devices with variable network connectivity, and highly reactive, event-driven interfaces to Semantic Web services.
This specification defines a data model based on RDF and Named Graphs, a messaging infrastructure based on the FIPA agent standards, and a pair of closely related interaction protocols: one for request-response queries, and another for subscription-based information streams.
This is neither a FIPA standard nor a W3C recommendation. Please direct any comments to<EMAIL_ADDRESS>describes
query form
As the Semantic Web becomes a ubiquitous resource, it has to adapt to computing platforms which are less and less like a rack-mounted Web server and to user interfaces which are less and less like a Web browser. For mobile devices with intermittent network connectivity, such as phones and navigation systems, message-oriented protocols are often more appropriate than the request-response model of HTTP. For applications which demand particularly low latency, such as real-time multimedia, connection-oriented protocols are best. Moreover, it is increasingly important for end-user applications to "talk back" to the Semantic Web, reversing the usual client and server roles in order to broadcast information to their peers.
All of the above are motivation for a message-oriented, transport-agnostic, and peer-to-peer style of information sharing in the manner of agent-based systems. In order to integrate these environments with Semantic Web data and services, this specification introduces a high-level messaging protocol which combines current Semantic Web best practices with FIPA (Foundation for Intelligent Physical Agents), the most widely adopted body of standards for agent-based systems.
Among the many variations on the theme of Semantic Web agents, this protocol focuses specifically on transmitting declarative Semantic Web information from point A to point B while preserving a provenance trail. It takes a minimalist approach to information discovery and retrieval which adapts the "follow your nose" mechanism of Linked Data to a peer-to-peer, conversational mode of interaction supporting RDF data streams as well as one-shot requests for resource descriptions.
This section (Introduction) provides an overview of the rest of the specification and introduces the conventions used throughout.
Section 2 (Data model) of the specification describes the various constituents of the data model (RDF, Named Graphs, RDF Datasets, and the special performative role of the default graph of a dataset) which underlies information sharing in RDFAgents. The representation of agents and graphs in RDF is described, along with a convention for sending and receiving information to and from other agents while recording provenance and attribution metadata.
Section 3 (Messaging) introduces the FIPA infrastructure upon which RDFAgent is based, describes the various types of messages which are used in the protocol, and defines rules and formats for transmitting RDF content.
Section 4 (Interaction protocols) describes the Query and Publish-Subscribe interaction protocols which guide the flow of a conversation between two agents (in a request-response pattern or a subscription-based pattern, respectively). Exceptions to the normal interaction flow are also specified.
Section 5 (FIPA compliance) describes the relationship between an RDFAgents implementation and the FIPA standards to which it conforms. Mandatory features of FIPA which are minimized in RDFAgents, as well as optional features which are omitted, are described along with additional constraints imposed by RDFAgents above and beyond FIPA.
Section 6 (Usage patterns) discusses several practical aspects of agent-based knowledge sharing, including reasoning over the RDFAgents provenance trail, publishing data (answering queries) in a way analogous to Linked Data on the Web, and integrating agents with other RDF streaming technologies.
Appendix A (Domain language and ontology) defines the FIPA domain ontology and the language of S-expressions according to which RDFAgents queries and error explanations are formatted. Appendix B (References), Appendix C (Acknowledgements), and Appendix D (Changes) are self-explanatory.
Unless otherwise noted in the section heading, all sections and appendices in this document are normative.
In this document, all examples assume the following namespace prefix bindings:
| Prefix | URI |
|---|---|
dc: |
http://purl.org/dc/terms/ |
ex: |
http://example.org/ |
foaf: |
http://xmlns.com/foaf/0.1/ |
rdfg: |
http://www.w3.org/2004/03/trix/rdfg-1/ |
sioc: |
http://rdfs.org/sioc/ns# |
swp: |
http://www.w3.org/2004/03/trix/swp-2/ |
xsd: |
http://www.w3.org/2001/XMLSchema# |
All examples of RDF Datasets (i.e. collections of named graphs) in this document use TriG, a particularly human-readable RDF serialization format supporting Named Graphs. For simplicity, namespace declarations are omitted from the beginning of each example; all namespaces are assumed to be defined as above. For example, the following:
{ ex:rdfnews a foaf:Agent . }
is an abbreviation for:
@prefix ex: <http://example.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . { ex:rdfnews a foaf:Agent . }
Examples of SPARQL also omit namespace declarations. For example:
SELECT ?agent ?address WHERE { ?agent foaf:mbox ?address . }
Examples of messages and content expressions in FIPA's Agent Communication Language are given using their string representation (see [FIPA SC00070I]). They resemble nested lists as in Lisp. For example, here is a simple ACL message:
(inform-done :sender (agent-identifier :name http://example.org/rdfnews :addresses (sequence xmpp:rdfnews@example.org)) :receiver (set (agent-identifier :name http://example.org/consumer :addresses (sequence xmpp:consumer@example.org))) :protocol fipa-subscribe :conversation-id 089f5b468e)
Information sharing in RDFAgents is based on the exchange of RDF data and Named Graph metadata. For details on the RDF and the Named Graph data models, see [RDF Concepts] and [Named Graphs], respectively. More specifically, agents exchange collections of named graphs, or RDF Datasets, which are defined as in SPARQL (see [SPARQL]). An RDF Dataset consists of zero or more graphs (where each graph contains zero or more statements), each named by an IRI, as well as a single unnamed graph which plays a special role in RDFAgents.
RDFAgents recognizes only one basic relationship between an agent and a graph: that of assertion.
The propositional attitude of assertion is inherited from FIPA's inform
and related communicative acts (see [FIPA SC00037J]) and is equated with the act of
publishing an RDF graph on the Semantic Web.
An agent which asserts a graph thereby asserts the truth of each RDF statement in the graph
as a proposition about the world.
For each message sent or received by an agent, there is a distinguished, default graph of statements which are subject to the propositional attitude of the message. Statements included in the default graph of an assertional message (see below) are thereby asserted to be true by the sender of the message, while the attitude of the sender towards any graph apart from the default graph is a matter of vocabulary, community convention, and interpretation by the receiver, and is not specified by RDFAgents.
The default graph of a message cannot be referred to, and no two messages share the same default graph. As a result, the information directly asserted in a message cannot be qualified with additional metadata, and is to be interpreted as a claim of absolute truth. On the other hand, provenance metadata may be attached to the information asserted in a previous message through the mechanism of graph renaming described below.
An agent in RDFAgents is not only an actor capable of exchanging messages with other agents, but also a first-class entity in the Semantic Web descriptions, or RDF Datasets, carried by messages. Agents are capable of referring to themselves and to each other, an agent's FIPA identity (which is used for the addressing and routing of messages) being bound in a one-to-one fashion with its Semantic Web identity.
An agent in RDFAgents must identify itself with a single, globally unique Semantic Web URI, and supply this as its FIPA name in each message it sends (see below for details on FIPA agent identifiers). The agent may also use this URI in self-referential descriptions. When an agent receives an assertional message from another agent, it associates the FIPA name of the sender with the corresponding URI.
RDFAgents uses a vocabulary drawn from the Named Graphs [NG], Friend of a Friend [FOAF], and Semantic Web Publishing [SWP] ontologies in order to make statements about named graphs and agents. SWP serves to annotate graphs with provenance metadata, capturing "who said what" relationships between graphs and agents, while FOAF serves to associate agents with their contact information, supporting a "word of mouth" style of agent and information discovery.
Graphs are represented as instances of
rdfg:Graph
,
while agents are represented as instances of
foaf:Agent
.
An asserted graph is also implicitly a warrant or warrant graph in the sense of SWP:
it constitutes a relationship between a set of statements and the authority or agent which
asserted them.
This relationship is expressed with the
swp:assertedBy
and
swp:authority
properties.
Finally, agents are annotated with FIPA contact information using the
foaf:mbox
property
(typically used with mailto
URIs, but compatible with other URI schemes
such as http
and xmpp
).
Note: several features of the Semantic Web Publishing vocabulary are not required by this specification, although some are suitable for implementation-specific extensions. For example, there is no built-in method of digitally signing named graphs, and SWP's notion of the validity period of a warrant is not used. Like the RDF/XML documents of the Web of Data, the information asserted in messages has no temporal or contextual qualifications.
Although there are several types of messages exchanged by agents (see below),
only assertional messages
(i.e. messages with RDF content and which use the FIPA inform-ref
performative)
carry Semantic Web information.
Each assertional message sent by an agent carries an RDF Dataset for which there are two distinguished resources:
This will be referred to as the sender's dataset. It is the RDF Dataset which is visible in serial form as the content of the message. Upon accepting an assertional message, the receiving agent must apply the following transformation to the sender's dataset:
rdfg:Graph
,
and add a swp:assertedBy
link from the graph to itself
foaf:Agent
and add a foaf:mbox
link
from the sender to each of its transport addresses
(see below)
swp:authority
link
from the previously-default graph to the sender
Optional metadata may be included, as well, such as a timestamp or a certificate. All new metadata belongs to the new default graph.
The result of this transformation, called the receiver's dataset, is independent of the communicative act itself, yet captures the informational content and assertional intent of the message. It also serves to record a provenance trail which gives credit to information providers while supporting information consumers in deciding which information to accept, and in discovering further information. In an application, the receiver's dataset can be added to a local RDF store for query answering, or sent verbatim to other agents, who may either trust to its accuracy or verify it by contacting the sender directly.
Example of a sender's dataset (of agent ex:rdfnews
):
{ ex:article137 a sioc:Post ; dc:title "1st Beijing International Film Festival kicked off on Saturday" ; dc:created "2011-04-25T10:43:35.000Z"^^xsd:dateTime ; sioc:topic <http://dbpedia.org/resource/Beijing> . }
A corresponding receiver's dataset (of agent ex:syndicator
):
<urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> { ex:article137 a sioc:Post ; dc:title "1st Beijing International Film Festival kicked off on Saturday" ; dc:created "2011-04-25T10:43:35.000Z"^^xsd:dateTime ; sioc:topic <http://dbpedia.org/resource/Beijing> . } { <urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> a rdfg:Graph ; swp:assertedBy <urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> ; swp:authority ex:rdfnews . ex:rdfnews a foaf:Agent ; foaf:mbox<EMAIL_ADDRESS>. }
A second-degree receiver's dataset (of agent ex:consumer
):
<urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> { ex:article137 a sioc:Post ; dc:title "1st Beijing International Film Festival kicked off on Saturday" ; dc:created "2011-04-25T10:43:35.000Z"^^xsd:dateTime ; sioc:topic <http://dbpedia.org/resource/Beijing> . } <urn:uuid:3e9abe24-7dad-42ae-9a2a-a2502e1385f3> { <urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> a rdfg:Graph ; swp:assertedBy <urn:uuid:be0c72c6-2b8f-4134-b309-690039f8c419> ; swp:authority ex:rdfnews . ex:rdfnews a foaf:Agent ; foaf:mbox<EMAIL_ADDRESS>. } { <urn:uuid:3e9abe24-7dad-42ae-9a2a-a2502e1385f3> a rdfg:Graph ; swp:assertedBy <urn:uuid:3e9abe24-7dad-42ae-9a2a-a2502e1385f3> ; swp:authority ex:syndicator . ex:syndicator a foaf:Agent ; foaf:mbox<EMAIL_ADDRESS>. }
RDFAgents is layered on top of the FIPA standards, which specify most aspects of agent management and message exchange. Most of this section will discuss only those aspects of agent messaging which are unique to RDFAgents (for more information on FIPA, see Section 5).
Agents operate within an RDFAgents platform, which is a concrete implementation of this specification and the underlying FIPA standards. An RDFAgents platform can be realized as a lightweight extension of an existing FIPA implementation such as JADE or FIPA-OS. An agent is an entity capable of sending and receiving messages, possibly obeying one or more well-defined interaction protocols. Agents communicate by exchanging messages which represent speech acts, encoded in the FIPA agent communication language (FIPA ACL).
RDFAgents uses a reduced expressivity subset, fipa-sl2
,
of FIPA's standard Semantic Language [FIPA SC00008I],
for agent communication.
The Semantic Language can be serialized using S-expression syntax,
as in the Lisp family of programming languages,
and permits the expression of propositions or statements of truth,
actions representing speech acts,
and references to objects in the domain of discourse.
For each FIPA message there is a distinct performative, which identifies the type of communicative act constituted by the message (see [FIPA SC00037J]). The performatives used within RDFAgents include:
agree
: agrees to a subscription requestcancel
: requests the cancellation of a subscriptionfailure
: indicates an error in query answering or stream processinginform-done
: acknowledges cancellation of a subscriptioninform-ref
: informs an agent of an update or the result of a querynot-understood
: indicates a communication errorquery-ref
: poses a queryrefuse
: refuses a query or a subscription requestsubscribe
: requests a subscription to a stream of updates
Of these, only inform-ref
, query-ref
, and subscribe
deal with Semantic Web content (queries and datasets).
The ability to send messages to other agents in an asynchronous,
transport-agnostic fashion is built in to any concrete FIPA implementation.
In order to send a message, an agent needs the recipient's name, which in RDFAgents is a URI,
and one or more transport addresses, which are also URIs.
An agent can "reply" to a message in an already-initiated interaction
by using the name and transport addresses supplied in the sender
field of the that message.
In order to initiate an interaction, however, an agent needs to have acquired the identity of the recipient from some other source. A simple way to find other agents is to issue a SPARQL query over all accepted statements, e.g. in order to contact the authority responsible for a previously asserted graph:
SELECT ?graph ?agent ?address WHERE { ?graph swp:assertedBy ?warrant . ?warrant swp:authority ?agent . ?agent foaf:mbox ?address . }
This gives the agent enough information to send a message, provided that graph metadata was recorded in the manner specified above and at least one of the relevant transport protocols is supported.
Agents should supply all of their contact information, i.e. transport addresses, in each message sent, so as to give the other party (as well as second-hand information consumers) as many options as possible for initiating new interactions.
Note that the initiator of an interaction in either the Query or Publish-Subscribe protocol
must supply a globally unique conversation-id
for use in every message in the interaction.
This allows an agent to carry on any number of concurrent conversations with other agents,
and to make good use of records of past conversations.
The propositional content of a message is expressed in a FIPA content language,
for which RDFAgents uses either fipa-sl2
or one of a number of special-purpose languages based on RDF document formats,
depending on role played by the message.
For example, an agent uses fipa-sl2
to subscribe to a stream of updates about a Semantic Web resource,
while the content of the updates it receives is expressed in TriG, N-Quads, or another RDF format.
In general, RDF content is used only for assertional messages,
which represent claims about the world.
Messages for all other purposes
(for example, posing a query, requesting or confirming a subscription)
use fipa-sl2
or nothing at all.
FIPA SL content in RDFAgents is explicitly grounded in a domain ontology with the name
rdfagents
(see below for details),
while RDF content is implicitly grounded in the universal representational space of the Semantic Web.
Throughout this specification, when a message is required to use the rdfagents
domain ontology,
its content is understood to be expressed in the fipa-sl2
content language, and vice versa.
This must be indicated in each message through the use of the FIPA
language
and ontology
parameters
(see [FIPA SC00061G]).
RDFAgents defines the following RDF-based content languages:
rdf-ntriples
: the language of expressions in N-Triples [N-Triples],
a line-based, plain-text format for RDF graphs.
In RDFAgents, every N-Triples triple represents a statement in the default graph.
rdf-turtle
: the language of expressions in the Turtle [Turtle]
plain-text format.
All statements belong to the default graph.
rdf-n3
: the language of expressions in the N3-rdf subset
of Notation3 [Notation3],
itself a superset of N-Triples and Turtle.
All statements belong to the default graph.
rdf-xml
: the language of expressions in RDF/XML [RDF/XML],
the most widely supported RDF format.
All statements belong to the default graph.
rdf-nquads
: the language of expressions in the N-Quads [N-Quads] format,
which extends N-Triples with context.
In RDFAgents, the optional context component of an N-Quads tuple must be a graph name.
If a tuple has a context component,
it represents a statement in the graph thus named.
Otherwise, it represents a statement in the default graph.
rdf-trig
: the language of expressions in the TriG [TriG] format,
which expressly supports Named Graphs and RDF Datasets.
The unnamed graph (if any) in a TriG document is identified with the default graph in RDFAgents.
rdf-trix
: the language of expressions in the TriX [TriX] XML-based format
with support for graph names.
Named and unnamed graphs are handled as in rdf-trig
.
An RDFAgents platform must support at least one of the above languages,
where supporting a language means that the platform can both parse and write the full range of valid
expressions in the language, to and from the corresponding RDF Datasets.
However, an RDFAgents platform need not support all of the above.
For the sake of interoperability,
it is recommended that the rdf-xml
and rdf-nquads
languages be supported,
at a minimum.
Agents may use additional RDF-based content languages which are understood, a priori, by both
participants in a conversation.
For example, an agent which receives a request for query results in "rdf-json
"
may choose to respond with a content expression in the
Talis RDF/JSON format.
However, it is up to the requester to validate the response against the expected format.
It is assumed that, for each supported RDF content language,
an RDFAgents implementation conserves the meaning of every RDF Dataset expressible in the language
(i.e. produces an equivalent RDF Dataset) when mapping it to a serial form and back again.
However, the various RDF content languages differ in expressiveness with respect to Named Graphs:
four of them cannot express named graphs at all,
while rdf-nquads
cannot express an empty named graph or default graph.
The following rules address these differences.
When mapping an RDF Dataset into the RDF content of a message:
When mapping the RDF content of a message into an RDF Dataset:
rdf-nquads
content in which every statement is a quad),
let there be an empty default graph
A FIPA agent potentially follows any number of interaction protocols, which govern the flow of a conversation in various contexts. For example, there are FIPA standard protocols for making requests, proposing actions, and negotiating contracts. RDFAgents deals with two, closely related protocols in particular: a Query protocol for simple request-response information sharing and a Publish-Subscribe protocol for event-driven information streams.
Both protocols distinguish between a pair of roles corresponding to an information consumer and an information provider, and every RDFAgent agent must be capable of playing all four roles interchangeably. However, an agent's function in a given role may be minimal, e.g. as a Publish-Subscribe provider which simply refuses all subscription requests.
Both interaction protocols may be used in combination with any transport protocol supported by the underlying FIPA implementation and which supports ordered delivery of messages (this is true, for example, of the HTTP and XMPP protocols).
The Query protocol allows an agent to request a single chunk of information from another agent.
It is based on the FIPA standard Query Interaction Protocol [FIPA SC00027H]
identified by fipa-query
.
Figure 1: the Query interaction protocol
The Query protocol involves two otherwise equal participants which assume the roles of a consumer
requesting information from a provider.
The consumer initiates a Query interaction by posing a query to the provider in the form of a FIPA
query-ref
message,
where the query is expressed using an RDFAgents query form (see below)
in the fipa-sl2
content language.
Upon receipt of the query, the provider either agrees or refuses to evaluate it.
If the provider refuses, it sends a refuse
message to the consumer
whose content is an explanation in the fipa-sl2
content language, completing the interaction.
If the provider agrees, it chooses whether to send an agree
notification to the consumer
or to proceed directly to the evaluation of the query.
After the answer to the query (an RDF Dataset) has been determined,
the provider completes the interaction with an inform-ref
message
carrying the dataset in one of the RDF content languages.
describes
query form
This version of RDFAgents supports exactly one type of query, called describes
,
which accepts a single RDF resource and returns an RDF Dataset of information about it.
This is similar to SPARQL's DESCRIBE query form
in that the way in which the provider selects an appropriate chunk of information describing the given resource is
unspecified.
The relationship of a describes
query result to its argument is analogous to the relationship of
an associated RDF description with a dereferenceable HTTP URI in Linked Data.
The query form is used in combination with the optional X-rdfagents-accept
message parameter, which
specifies the desired RDF content language for the message.
Built-in content languages include
rdf-n3
,
rdf-nquads
,
rdf-ntriples
,
rdf-trig
,
rdf-trix
,
rdf-turtle
, and
rdf-xml
, as described above,
but any string is acceptable.
When the consumer thus specifies a language, the provider must either return results in the specified language,
or raise an exception in the form of a failure
message if that language is not supported
(see below for more information on exceptions).
Otherwise, the query result may use any one of the built-in RDF content languages listed
above.
Example of a query message:
(query-ref :sender (agent-identifier :name http://example.org/consumer :addresses (sequence xmpp:consumer@example.org)) :receiver (set (agent-identifier :name http://example.org/rdfnews :addresses (sequence xmpp:rdfnews@example.org))) :protocol fipa-query :conversation-id c976b710a5 :language fipa-sl2 :ontology rdfagents :X-rdfagents-accept rdf-trig :content "((any ?dataset (describes ?dataset (resource :uri http://dbpedia.org/resource/Beijing))))")
Query result:
(inform-ref :sender (agent-identifier :name http://example.org/rdfnews :addresses (sequence xmpp:rdfnews@example.org)) :receiver (set (agent-identifier :name http://example.org/consumer :addresses (sequence xmpp:consumer@example.org))) :protocol fipa-query :conversation-id c976b710a5 :language rdf-trig :content " @prefix dc: <http://purl.org/dc/terms/> . @prefix ex: <http://example.org/> . @prefix sioc: <http://rdfs.org/sioc/ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . { ex:article137 a sioc:Post ; dc:title \"1st Beijing International Film Festival kicked off on Saturday\" ; dc:created \"2011-04-25T10:43:35.000Z\"^^xsd:dateTime ; sioc:topic <http://dbpedia.org/resource/Beijing> . }")
In RDFAgents, the inform-ref
message which supplies the query result
has the same propositional force as an inform
message
(see [FIPA SC00037J]):
it is an assertion by the provider that the content of the message is a true proposition,
or in RDFAgents terms,
that all statements in the default graph of the sender's dataset are true.
Furthermore, it is an assertion not only to the consumer which issued the query,
but to all potential information consumers,
making the act of sending such a message analogous to that of publishing a document on the Semantic Web.
After constructing the receiver's dataset for the query result, the consumer may pass it on to any other agent, at any time, simply by including it in the sender's dataset of another message.
At any point in a Query interaction,
the consumer or provider can inform the other party that it did not understand what was communicated,
possibly ending the interaction.
This is accomplished with a not-understood
message which optionally contains an error explanation
in the rdfagents
domain ontology.
If the provider understands the query but fails to produce a query result,
it must send a failure
message to the consumer with an explanation in the
rdfagents
domain ontology, ending the interaction.
See below for more information on error explanations.
In addition, a Query interaction may be cancelled by the consumer at any time
(i.e. after issuing the query and before receiving a query result) by initiating the FIPA Cancel meta-protocol
using a cancel
message.
The Publish-Subscribe protocol enables event-driven streams from information providers to information consumers
according to topics of interest.
It is based on the FIPA standard Subscribe Interaction Protocol [FIPA SC00035H]
identified by fipa-subscribe
.
Figure 2: the Publish-Subscribe interaction protocol
The Publish-Subscribe protocol involves two otherwise equal participants
which assume the roles of a consumer or subscriber requesting a stream of informative updates from a provider
or publisher.
A Publish-Subscribe interaction begins with the consumer issuing a subscription request
in the form of a FIPA subscribe
message.
The language, ontology and content of this message
are subject to the same constraints as a query in the Query protocol,
the only difference being the performative and the protocol
field of the message.
In particular, the subscription request must contain a describes
functional term
in the fipa-sl2
content language whose argument is the topic of the desired stream.
Upon receipt of the subscription request, the provider either agrees or refuses to
register a corresponding subscription.
If the provider refuses, it sends a refuse
message to the consumer
whose content is an explanation in the fipa-sl2
content language, completing the interaction.
If the provider agrees, it must send an agree
notification as its first message to the
consumer in the current interaction (i.e. before it sends any updates).
Updates are communicated by the provider to the consumer in the same manner as Query results,
using inform-ref
messages carrying RDF Datasets.
The only difference between Query results and Publish-Subscribe updates
(apart from the protocol
field) is that there is at most one result per query,
while there are any number of updates per subscription.
Unless an exception occurs (see below),
the subscription remains active until it is cancelled by the consumer with a cancel
message,
which the provider acknowledges with an inform-done
message before terminating the subscription
and thereby completing the interaction.
At that point, no further updates should be sent.
 }")
As in the Query protocol, an inform-ref
message containing an update
has the same propositional force as an inform
message:
it is an assertion by the provider, to all potential consumers,
that all statements in the default graph of the sender's dataset are true.
This provides a method of publishing data streams on the Semantic Web which is analogous to the publishing of
RDF documents.
After constructing the receiver's dataset for the update, the consumer may pass it on to any other agent, at any time, simply by including it in the sender's dataset of another message.
Exceptions to the Publish-Subscribe protocol are analogous to those of the Query protocol (see above). A depiction of the FIPA Cancel meta-protocol is included in Figure 2 because the eventual cancellation of a subscription is a normal and expected event, unlike the cancellation of a query.
The FIPA Abstract Architecture [FIPA SC00001L] defines architectural elements of agent platforms and their relationships, and provides guidelines for the instantiation and interoperability of agent systems.
In order for a concrete architectural specification to be FIPA compliant, it must have certain properties. First, the concrete architecture must include mechanisms for agent registration and agent discovery and inter-agent message transfer. These services must be explicitly described in terms of the corresponding elements of the FIPA Abstract Architecture.
Any concrete implementation of RDFAgents, or RDFAgents platform, must realize the mandatory elements of the FIPA Abstract Architecture. The following subsections will describe additional constraints imposed by RDFAgents with respect to FIPA compliance, and discuss optional elements of FIPA which are not required by RDFAgents. All elements of FIPA not discussed in this specification are to be considered independent of RDFAgents, and may be realized in implementation-specific ways.
FIPA defines an agent identifier (AID) as an extensible collection of parameter-value pairs comprising a name or globally unique identifier for the agent, zero or more transport addresses at which the agent can receive messages, and zero or more resolvers or name resolution service addresses.
At creation or registration time, a FIPA agent must be given an agent name which has a durable relationship with the agent it identifies and which is chosen in such a way as to ensure global uniqueness. An agent name should have no semantics:
It should not encode any actual properties of the agent itself, nor should it disclose related information such as agent transport-description or location. It should also not be used as a form of authentication of the agent. [FIPA SC00001L]
To facilitate the RDF description of agents, the name of an RDFAgents agent must be a valid absolute URI, preferably (but not necessarily) a Semantic Web URI which is drawn from a URI space controlled by its owner. For example, the name may be an HTTP URI associated with an RDF description of the agent which can be obtained by dereferencing the URI, in the manner of Linked Data.
The resource denoted by the agent name is explicitly typed as an instance of
foaf:Agent
in the receiver's dataset of every assertional message it sends.
The Semantic Web URI of a foaf:Person
may be used as an agent name
only if the agent and the person thus identified are identical for the purpose of information exchange.
This may be the case, for example, when an agent acting as a personal assistant is given the task of sending and
receiving
messages on behalf of its owner.
Note, however, that any discoverable contact information of the person which is not valid contact information of the
agent may lead to unwanted and ineffectual messages from other agents.
Additionally, it should be kept in mind that the contact information of an agent is shared freely in RDFAgents,
much as URIs are shared in Linked Data,
while the sharing of personal contact information is subject to concerns of privacy and spam control.
A transport address is a physical address at which an agent can be contacted. It is usually specific to a particular protocol (for example, HTTP or XMPP). A given agent may support multiple methods of communication and therefore may have multiple transport addresses. Since an agent's transport addresses are used as authoritative contact information in RDF descriptions of the agent (see above), they are required to be compatible with such use.
The EBNF syntax of a FIPA transport address is the same as that of a URL given in [RFC 2396].
It is thereby also a URI, and can be used as a resource name in RDF descriptions of the agent.
The the scheme part of the transport addresses of an agent in RDFAgents should correspond
to a well-known messaging protocol (e.g. http
or xmpp
),
and its scheme-specific part should serve to identify the recipient in an unambiguous, global fashion.
Every agent in an RDFAgents platform requires at least one transport address.
For compatibility with foaf:mbox
(an inverse functional property), no two agents may share the same transport address(es).
The agent platform itself does not require a transport address, as it does not need to send or receive messages.
RDFAgents does not mandate the use of FIPA's resolvers parameter of the agent ID (although it does not probihit its use), which aids in discovering additional transport addresses of an agent. No specialized lookup services are provided for agent names. Instead, transport addresses are extracted from the RDF descriptions of agents. An RDFAgents platform must be capable of extracting contact information from RDF Datasets according to the RDFAgents vocabulary (see the example SPARQL query above) and mapping the URIs thus discovered to transport addresses. Any URIs which are not valid URLs (and therefore not valid transport addresses) are simply to be discarded.
For example, the following RDF description provides sufficient information for the sending of a message over
XMPP to the agent identified by<EMAIL_ADDRESS>on Jabber:
{ ex:rdfnews foaf:mbox<EMAIL_ADDRESS>. }
In order to make use of this information,
an RDFAgents platform must know that the xmpp
URI scheme corresponds to the XMPP protocol,
and it must have access to a XMPP message transport service
(preferably, one with a connection to a public XMPP server).
FIPA Agent Management [FIPA SC00023K] provides the normative framework within which FIPA agents exist and operate. It establishes the logical reference model for the creation, registration, location, communication, migration and retirement of agents. A mandatory component of this model is the agent management system, or AMS, which exerts supervisory control over access to and use of the platform. It provides agent identifiers to agents and maintains a directory of identifiers, providing a white pages service for all agents.
However, the AMS is no more than an internal component of a conforming RDFAgents implementation; this specification is concerned only with peer-to-peer communication between platforms (as opposed to intra-platform communication), and there is no operation within RDFAgents which requires the sending of a message to the AMS of a remote platform.
RDFAgents neither requires nor prohibits the use of FIPA's optional directory facilitator, which maintains an index of agents in a platform and provides a yellow pages service for agents. The role of the directory facilitator is considered to be fulfilled in RDFAgents by the "word of mouth" mechanism of service discovery via RDF descriptions.
All FIPA agents must have access to at least one message transport service,
or concrete implementation of a protocol for sending and receiving messages.
The ways in which transport addresses are mapped to transport protocols
(e.g. as an xmpp:
URI is mapped to the XMPP protocol),
as well as the ways in which an agent chooses from among different transport addresses for the same agent,
are not specified in FIPA or RDFAgents.
RDFAgents does not make use of FIPA's experimental RDF content language [FIPA XC00011B]. This language predates Named Graphs (using RDF reification for statement metadata, instead) and differs in intent from RDFAgents, which separates the representation of knowledge in RDF with Named Graphs from the representation of actions in FIPA's built-in Semantic Language.
RDFAgents defines the rules by which provenance information is to be recorded throughout the process of information exchange, creating an "A says that B says X" pattern of nested assertions. It does not specify how an agent should reason upon the provenance trail in order to decide which information to accept as true. There are many possible options, and this choice is best left to the application. However, some straightforward strategies are illustrated in the following. Given an RDF Dataset such as the receiver's dataset of a message, the problem in each case is to either accept or reject each graph in the dataset, merging the accepted graphs into a single graph of accepted statements.
Strategy #1: It's All Good. Accept all graphs. This is the simplest possible strategy (apart from "None of it is Good", that is), and the one used by most applications which consume heterogeneous Semantic Web data. In the absence of a clear set of conventions for expressing provenance metadata, all one can do is to accept information arbitrarily and hope for the best. This strategy ignores not only the variable trustworthiness of information providers, but also the fact that graphs may be provided (or quoted) in a message without necessarily being asserted. Nonetheless, it may be good enough for some applications, such as data browsers and crawlers.
Strategy #2: The Grapevine. This strategy is a little more sophisticated than the above, in that it only accepts graphs which have been explicitly asserted... or which have been asserted to have been asserted, and so on. It proceeds as follows.
swp:assertedBy
statements in the graph(s) just accepted.Strategy #3: Authoritative Sources. To add an element of trust to the above, we can select not only asserted graphs, but also the agents who asserted them, e.g. by using this SPARQL query in step (2):
SELECT ?graph ?agent WHERE { ?graph swp:assertedBy ?warrant . ?warrant swp:authority ?agent . }
For each result, we apply some criterion to agent
(perhaps looking it up in a global whitelist of trusted peers or blacklist of known spammers)
and reject graph
if the agent fails to meet this criterion.
In more application-specific contexts, additional metadata relating to belief and trust could be used
in order to support a Web of Trust among communicating agents.
The describes
query operation supported by RDFAgents is purposely similar to
the convention of dereferencing HTTP URIs on the Web of Data.
This is a particularly simple way of interacting with Semantic Web datasets which has nonetheless proven effective.
However,
The Semantic Web isn't just about putting data on the web. It is about making links, so that a person or machine can explore the web of data. With linked data, when you have some of it, you can find other, related, data.
In order to support such "follow your nose" information discovery, agents need a set of best practices for publishing data in a way which facilitates exploration. By analogy to the four Linked Data principles, the following are suggested:
For example, if an information consumer asks the agent named http://example.org/info
about the thing named http://dbpedia.org/resource/Beijing
,
that agent should respond with an RDF Dataset about the city of Beijing.
The description may include links to related things such as China,
Beijing universities and historical landmarks, and so on.
Furthermore, if the agent has information about Beijing from other sources,
such as a news service http://foo.com/news
or a weather service http://bar.net/weather
,
some of that information may be included in the dataset along with appropriate attribution metadata.
This gives the information consumer the option of contacting those sources directly
in order to get more detailed or more up-to-date news or weather information about Beijing.
For more information on Linked Data, see the [Linked Data Book].
The similarity of the Query and Publish-Subscribe interaction protocols makes them nearly interchangeable from the point of view of the information consumer. An agent which ordinarily requests a single RDF description of a resource, in the manner of a Linked Data client, can just as well subscribe to an open-ended stream of information about that resource, responding to updates in the same way that it responds to query results. For an agent, the gap between "static" and "real-time" Semantic Web data is a small one.
On the data provider's side, there are a number of existing tools for generating Semantic Web data streams, among them C-SPARQL, a SPARQL dialect for continuous queries, SPARQLPuSH, which transports RDF updates over HTTP, and services such as TwitLogic which produce RDF streams based on specific real-time data sources.
The RDFAgents domain ontology, identified by rdfagents
,
provides a simple model of queries and error explanations for use in FIPA messages.
It is used in combination with a grammar of legal S-expressions in the fipa-sl2
content language.
A URI reference
is constructed with the resource
function,
whose only parameter, uri
, expects a URI in the form of a Unicode string (encoded as in
[RDF Concepts]).
Example of a URI reference:
(resource :uri http://example.org/ArthurDent)
Literals
are constructed with the function literal
using one required parameter, label
,
which expects the label of the literal as the quoted form of a string encoded in Unicode Normal Form C
(as described in [RDF Concepts]),
and optional parameters language
and datatype
,
which expect a language tag (see [RFC 3066]) and a URI reference, respectively.
Example of a literal:
(literal :label 42 :datatype (resource :uri http://www.w3.org/2001/XMLSchema#integer))
Blank nodes cannot be referred to directly.
The describes
query form completes an Identifying Reference Expression
(IRE, as in [FIPA SC00008I]) for an RDF Dataset
describing some resource.
For details on usage, see above.
Its two parameters are the variable of the IRE and a functional term for the resource (URI reference or literal) to
be described.
Example of a query:
((any ?dataset (describes ?dataset (resource :uri http://example.org/ArthurDent))))
An error is any event or circumstance which departs from the ordinary flow of
an interaction and requires explanation.
Any not-understood
, failure
, or refuse
message which is sent
in the course of an RDFAgents interaction represents an error condition,
and should contain an error explanation in the rdfagents
ontology.
This is not a firm requirement, however, as such messages may occur in the lower levels of a FIPA implementation,
beyond the control of a lightweight RDFAgents implementation.
With all three of these performatives, the content of the message is a tuple containing an action expression (for example, the content of a previous message which was not understood) and an error explanation giving a reason for the failure.
An error explanation in the rdfagents
ontology consists of a functional term identifying the type of error
which has occurred, as well as a single argument providing a natural-language description of the error.
The following error types are supported:
external-error
: indicates an error which the agent attributes to the other party in the
interaction.
Used when no more specific error type is appropriate, similar to the 400 HTTP response status code.
interaction-expired
: indicates that the agent no longer considers the present interaction
to be in progress (for example, if an implicit subscription lease has timed out).
internal-error
: indicates an error which the agent attributes to itself.
Used when no more specific error type is appropriate, similar to the 500 HTTP response status code.
invalid-content
: indicates that a content entity failed a syntactic or semantic constraint
(for example, on account of a badly-formatted query)
invalid-message
: indicates a high-level problem with a message received
(for example, missing content or an unknown protocol).
not-implemented
: indicates a non-implemented feature which is necessary in order to
continue normally (for example, an unsupported RDF content language)
unavailable
: indicates that the agent is currently busy or otherwise unable to continue
normally with the current interaction, without regard to the form or content of a particular message
The type-specific error message may include additional, implementation-specific arguments.
Example error explanation:
(invalid-content "function 'descrbies' is not defined")
This work has been supported by the Tetherless World Constellation and Franz Inc. in collaboration with the Institute of Automation, Chinese Academy of Sciences. Special thanks go to Jim Hendler, Deborah L. McGuinness, Peter Fox, Yanwu Yang, Daniel Zeng, and Jans Aasman for their valuable feedback.
The format of this document is based on W3C and Buzzword.org.uk specifications.


SPEENGHAR TRAVEL AGENCY
Home
Debt Amount
Credit Amount
Login
to
Check Balance
Debit Amount
DATE
VOUCHER NUMBER
From BANK
United Bank Limited
Allied Bank Limited
Habib Bank Limited
Muslim Commercial Bank Limited
Bank Alfalah Limited
Faisal Bank Limited
Albarak Bank Limited
National Bank Limited
Al-Habib Bank Limited
Khushali Bank Limited
SILK Bank Limited
SUMMIT Bank Limited
Account #
To BANK
United Bank Limited
Allied Bank Limited
Habib Bank Limited
Muslim Commercial Bank Limited
Bank Alfalah Limited
Faisal Bank Limited
Albarak Bank Limited
National Bank Limited
Al-Habib Bank Limited
Khushali Bank Limited
SILK Bank Limited
SUMMIT Bank Limited
Account #
DEBIT AMOUNT
Transfer Amount
Credit Amount
DATE
VOUCHER NUMBER
From BANK
United Bank Limited
Allied Bank Limited
Habib Bank Limited
Muslim Commercial Bank Limited
Bank Alfalah Limited
Faisal Bank Limited
Albarak Bank Limited
National Bank Limited
Al-Habib Bank Limited
Khushali Bank Limited
SILK Bank Limited
SUMMIT Bank Limited
Account #
To BANK
United Bank Limited
Allied Bank Limited
Habib Bank Limited
Muslim Commercial Bank Limited
Bank Alfalah Limited
Faisal Bank Limited
Albarak Bank Limited
National Bank Limited
Al-Habib Bank Limited
Khushali Bank Limited
SILK Bank Limited
SUMMIT Bank Limited
Account #
DEBIT AMOUNT
Transfer Amount


Katerina Skroumpelou
Upstream, Greece
@psybercity
github.com/mandarini
Slides: https://mandarini.github.io/ngUPPres
Code from presentation:
https://github.com/mandarini/map-user
https://github.com/mandarini/map-dashboard


Extracts first-level classes from ANTLR4 ParseTree
Extracts first-level classes from ANTLR4 ParseTree
Extract classes defined as field (nested ones)
Extract class fields from ANTLR4 ParseTree, stop at any ClassDeclaration
Extracts first-level classes from ANTLR4 ParseTree
Extracts first-level classes from ANTLR4 ParseTree
Extracts all local variable declarations from ANTLR4 ParseTree with no statement pass
Extracts first-level classes from ANTLR4 ParseTree
Extracts first-level supers from ANTLR4 ParseTree
Extracts first-level classes from ANTLR4 ParseTree
Extracts all local variable declarations from ANTLR4 ParseTree
Tool for complicated inheritance problems.
Parse tree properties extractors


bud UVB temperature break set UVA growth Populus males phenology elevated Male females plants treatments {border-style dormancy leaf buds female px;} #ffffff;} Plant effects male delayed effect enhanced experimental (day Bud autumn change climate radiation removal species order Tree bud‐removed spring values Physiology, control responses study treatment tremula year aspen compared earlier field levels plant stages tree used (Figure Ultraviolet cessation data development individuals intact light px; significant temperature, temperatures {font-family °′N, (), Botany, Figure However, Li, Nybakken, Tanino, closed font-size forced forest growing vegetative woody Biology, Climate Environmental Experimental Julkunen‐Tiitto, June Junttila, Olsen, UVA, cathayana different double; frames model photoperiod studies years (Table (days (e.g., Betula Finland Korpelainen, Picea Randriamanana, Research, Salix Strømme Temperature UVAT, University ambient average border-color border-width changes climatic combination combined conducted differences enhancement females. green increase individual induction lamps males. number plantlets plots recorded score solid; time timing warming {font-style {font-weight °′E, (pp. Andersen, Canadian Cell Change Chao, Eastern Environment, Forest Horvath, Hänninen, Julkunen‐Tiitto Kalcsits, Lindroth, McDowell, McMahon, Norway Nybakken Peng, Randriamanana Science, UVB, UVBT, Wang, abscisic axillary bold clone concentration controlled courier; em; environmental factors following forcing having included individuals, individuals— interactions length males, myrsinifolia northern phase plot pt;} radiation. removed responsive result scoring seedlings sensors setup subsequent sugar temperate trees trees. ultraviolet‐B


Bases: cgsdata.CGSdatastructure.CGSdatasubstructure
An AVRO schema
Bases: object
A CGS data structure
Bases: object
A CGS data substructure (CGS=Centralized genomic system) A data substructure can be any database schema provided that it is contained on the same database. For instance, you cannot have a data substructure that has a MySQL table and a HBase table, all tables must be contained in the same database (here it would be either in MySQL or HBase, but not both).
Bases: cgsdata.CGSdatastructure.CGSdatasubstructure
An HBase table in the Hadoop framework
Bases: cgsdata.CGSdatastructure.CGSdatasubstructure
A metastore table in the Hadoop framework that can be further queried by Hive, Impala, Pig, etc
Attributes:
Bases: cgsdata.CGSdatastructure.CGSdatasubstructure
A MySQL substructure
The source file could be a sql dump or a yaml file
Attributes:
Bases: exceptions.Exception
Bases: exceptions.Exception
The goal of this function is to build a new data structure. Credentials for each data substructure is created on the fly in the ~/.cgs/cgs_config_file This file should be protected: chmod 600 ~/.cgs/cgs_config_file
Usage: python CGSdatastructure.py <datastructure_path>
Ex: python CGSdatastructure.py /my/datastructure/path/


Assignment 4 and task 1
This script manually inserts the rectangles to the people and moon. ID: U1610131 Name: Madiyor Abdukhashimov
importing opencv library - to be able to import opencv you need to install it using pip. The process of installation is provided in README.md
import cv2
read the image from the images/ directory
image = cv2.imread('images/moonphcamera.jpg')
place the red rectangle onto people.
people_and_moon = cv2.rectangle(
img=image, # the image that we have loaded
pt1=(72, 80), # starting point for rectangle
pt2=(208, 307), # ending point for rectangle
color=(0, 0, 255), # the red color that we are sending
thickness=3, # the size for the line of rectangle
)
place the rectangle onto the Moon
people_and_moon = cv2.rectangle(
img=people_and_moon, # the image that has moon and people
pt1=(392, 126), # the starting point for rectangle
pt2=(432, 160), # the ending poin for rectangle
color=(0, 0, 0), # the color of rectangle
thickness=1, # the size for the line of rectangle
)
display the image
cv2.imshow('people_and_moon_selected', people_and_moon)
save the file
cv2.imwrite('results/task1/people_and_moon_selected.jpeg', people_and_moon)
wait 5 seconds
cv2.waitKey(5000)


Post Event
Post Opportunity
Upload
Post Anonymously
Post
Visible to campus
Campus
Only Students
Only Faculty
My Connections
Event Date & Time
Photo From Your Computer
Choose File
No file chosen
Photo From Web
Upload
Post
Visible to campus
Campus
Only Students
Only Faculty
My Connections
Deadline for Application
Upload Application
Choose File
No file chosen
Submission Link/Email
Upload
Post
Visible to campus
Campus
Only Students
Only Faculty
My Connections


$var title: Startujemy naszą zabawę/walkę
Oto podstawowa struktura dla kazdego robota:
class Robot:
def act(self, gra):
return [<jakaś akcja>, <params>]
Na początku gry, system tworzy jedną instancję twojej klasy Robot
.
Oznacza to, że zmienne klasy i moduły zmienne globalne są wspólne dla robotów.
W każdej rundzie serwer wywołuje dla każdego robota metodę act
jeden raz w celu określenia jego następnej akcji.
(Ponownie, prosimy o zapoznanie się z regułami - naprawdę warto.)
Metoda powinna wrócić jednego z elementów:
At the beginning of the game, the system creates one instance of your
Robot
class. This means that class variables and your module's
global variables are shared between calls. Every turn the system calls
that single instance's act
method once for each of your robots
to determine its next action. (Again, please read the rules first.) The method
should return one of:
['move', (x, y)]
['attack', (x, y)]
['guard']
['suicide']
If act
throws an exception or returns an invalid command,
the robot will simply guard, but if it times out too many times then it
will be forced to surrender the match. Please see
Security for those details.
Every robot, including self
, has the following properties
exposed:
location
— the robot's location as a tuple (x, y)hp
— the robot's health as an intplayer_id
— the robot's player_id (what "team" it belongs to)robot_id
— a unique number identifying each robot (only available for robots on your team)For example, to access the current robot's HP, you would write self.hp
.
Every turn, the system calls your act
method, passing it a game
parameter set to the following structure:
{
# a dictionary of all robots on the field mapped
# by {location: robot}
'robots': {
(x1, y1): {
'location': (x1, y1),
'hp': hp,
'player_id': player_id,
# only if the robot is on your team
'robot_id': robot_id
},
# ...and the rest of the robots
},
# number of turns passed (starts at 0)
'turn': turn
}
game
and every robot in game['robots']
are
instances of a special type of dict where you can access values using
attributes. This is to make writing code faster. So, the following are
equivalent:
game['robots'][location]['hp']
game['robots'][location].hp
game.robots[location].hp
Here's a quick example to print out the location of any robots that are on your team:
class Robot:
def act(self, game):
for loc, robot in game.robots.items():
if robot.player_id == self.player_id:
print loc
Here's a simple robot to use as a starting point. It looks for any enemies around and attacks them. Otherwise, it tries to move to the center.
import rg
class Robot:
def act(self, game):
# if we're in the center, stay put
if self.location == rg.CENTER_POINT:
return ['guard']
# if there are enemies around, attack them
for loc, bot in game.robots.iteritems():
if bot.player_id != self.player_id:
if rg.dist(loc, self.location) <= 1:
return ['attack', loc]
# move toward the center
return ['move', rg.toward(self.location, rg.CENTER_POINT)]
As you can see, there is a module called rg
being used. We'll look at this next.
Implementation detail: only one instance of your robot is created each game, so you can store persistent data in your instance variables.


Introduction to Tcl
The Tcl package contains the Tool
Command Language, a robust general-purpose scripting language.
This package is known to build and work properly using an LFS-9.1
platform.
Package Information
Additional Downloads
User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/tcl
Installation of Tcl
This package is also installed in LFS during the bootstrap phase.
As it is not installed during Chapter 6 of LFS, installation
instructions are included here in BLFS.
If you downloaded the optional documentation, unpack the tarball by
issuing the following command:
tar -xf ../tcl8.6.10-html.tar.gz --strip-components=1
Install Tcl by running the
following commands:
export SRCDIR=`pwd` &&
cd unix &&
./configure --prefix=/usr \
--mandir=/usr/share/man \
$([ $(uname -m) = x86_64 ] && echo --enable-64bit) &&
make &&
sed -e "s#$SRCDIR/unix#/usr/lib#" \
-e "s#$SRCDIR#/usr/include#" \
-i tclConfig.sh &&
sed -e "s#$SRCDIR/unix/pkgs/tdbc1.1.1#/usr/lib/tdbc1.1.1#" \
-e "s#$SRCDIR/pkgs/tdbc1.1.1/generic#/usr/include#" \
-e "s#$SRCDIR/pkgs/tdbc1.1.1/library#/usr/lib/tcl8.6#" \
-e "s#$SRCDIR/pkgs/tdbc1.1.1#/usr/include#" \
-i pkgs/tdbc1.1.1/tdbcConfig.sh &&
sed -e "s#$SRCDIR/unix/pkgs/itcl4.2.0#/usr/lib/itcl4.2.0#" \
-e "s#$SRCDIR/pkgs/itcl4.2.0/generic#/usr/include#" \
-e "s#$SRCDIR/pkgs/itcl4.2.0#/usr/include#" \
-i pkgs/itcl4.2.0/itclConfig.sh &&
unset SRCDIR
To test the results, issue: make
test.
Now, as the root
user:
make install &&
make install-private-headers &&
ln -v -sf tclsh8.6 /usr/bin/tclsh &&
chmod -v 755 /usr/lib/libtcl8.6.so
If you downloaded the optional documentation, install it by issuing
the following commands as the root
user:
mkdir -v -p /usr/share/doc/tcl-8.6.10 &&
cp -v -r ../html/* /usr/share/doc/tcl-8.6.10
Command Explanations
$([ $(uname -m) = x86_64 ] &&
echo --enable-64bit)
: This switch is used to enable 64
bit support in Tcl on 64 bit
operating systems.
make
install-private-headers: This command is used to
install the Tcl library interface
headers used by other packages if they link to the Tcl library.
ln -v -sf tclsh8.6
/usr/bin/tclsh: This command is used to create a
compatibility symbolic link to the tclsh8.6 file as many packages
expect a file named tclsh.
sed -e ...: The
Tcl package expects that its
source tree is preserved so that packages depending on it for their
compilation can utilize it. These sed remove the references to the
build directory and replace them with saner system-wide locations.


This profile sets expectations for use of the DataElement resource within the Structured Data Capture implementation guide. This includes identifying which core elements and extensions must be supported.
The focus of this profile is on those characteristics of Data Elements which are necessary to support the definition of forms (questionnaires) that can support auto-population or pre-population of content on the basis of referenced data elements.
For the purposes of this profile, Supported means that clients SHALL be capable of processing the element/extension and use the information to control the display and information capture associated with the DataElement. It means that servers SHALL be capable of persisting those elements and returning them in response to requests.
This profile relies on the use of a number of other profiles, some required, others available for use "when necessary":
| Profiles: | |
| SDC-Element | Sets expectations for data elements registered or used as part of the structured data capture project |
In some environments, it may be necessary for a questionnaire to support multiple languages. The rendering tool would select the appropriate language based on a configuration setting, or perhaps would display all available languages and the user would read the one they are familiar with. Systems MAY choose to provide support for identifying language and translations. If they do, they SHALL do so using the generic language and translation extensions FHIR defines based on the ISO21090 data type specification:
These extensions can be used on absolutely any string element on Questionnaire, ValueSet, one of the data types or any other resource. The base string should be the primary language of the questionnaire. It is what will be rendered by systems that do not support the translation extension or by systems whose language preference is other than one of the languages provided.
The ISO 19763 specification permits declaring language on questionnaire titles, descriptions, display names for codes and many other strings. It also supports capturing multiple variants of these strings with distinct languages. These capabilities can be mirrored using the above extensions.
While DataElement.stringency has been introduced, a formal set of rules defining exactly what level of "tightness" must exist for a stringency code, and in particular, what the rules are for data elements intended for use in auto-population/pre-population has not yet been defined. For example, if a data element supports a subset of the answer codes that the question does, is that acceptable? Must the question text be word-for-word identical? Is it acceptable if the data element length is shorter than the permitted length for the question? Is it acceptable if units of measure are not an exact match so long as conversion factors are known?
Opinions on these and related questions of stringency are welcome.
| C-CDA-Gender | XML | JSON | FHIR Gender with mapping to C-CDA |
Additional examples of this profile can be found as contained resources within the following examples:
| SDC-LOINC USSG Family History | XML | JSON | LOINC US Surgeon General family history including data elements & value sets. Note: This example isn't strictly valid against SDC as data elements do not have definitions and don't include mappings to SDC-approved specificaitons for auto-population |
Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.


parse_pdf
(server_address
:str
, file_path
:Path
, port
:str
=''
, timeout
:int
=60
)
This function if successful returns the JSON output of the
science parse server as a dictionary. Else if a Timeout Exception
or any other Exception occurs it will return None. If any of the
exceptions do occur they will be logged as an error.
- server_address: Address of the server e.g.
http://<IP_ADDRESS>
- file_path: Path to the pdf file to be processed.
- port: The port to the server e.g. 8080
- timeout: The amount of time to allow the request to take.
returns A dictionary with the following keys:
['abstractText', 'authors', 'id', 'references', 'sections', 'title', 'year']
Note not all of these dictionary keys will always exist if science parse
cannot detect the relevant information e.g. if it cannot find any references
then there will be no reference key.
Note See the example on the main page of the documentation for a
detailed example of this method.


Unlike the
values
/call-with-values
mechanism of R5RS, this
SRFI uses an explicit representation for multiple return values as a
single value, namely a procedure. Decomposition of multiple values is
done by simple application. Each of the two macros, mu
and
nu
, evaluates to a procedure that takes one procedure
argument. The mu
and nu
can be compared with
lambda
. While lambda
expression that consists
of <formals> and <body> requires some actual arguments later
when the evaluated lambda
expression is called,
mu
and nu
expressions that consist of
<expression>s corresponding to actual arguments of
lambda
require <formals> and <body>, that is, an
evaluated lambda
expression, later when the evaluated
mu
and nu
expressions are called.
This SRFI also introduces new
let
-syntax depending on mu
and nu
to manipulate multiple values, alet
and alet*
that are compatible with let
and let*
of R5RS
in single value bindings. They also have a binding form making use of
values
and call-with-values
to handle multiple
values. In addition, they have several new binding forms for useful
functions such as escape, recursion, etc.


I look here in Battlelog source code and i belive that "Leave Platoon" link still works in Disabled Platoons. But how i don't know how to make functions in js, i can't test this.
It's useful if you want leave any disabled platoon, 'cause this is disabled but still counts in platoons' limit (5).
BrainFooLong
Administrator
This should not be a thing for better battlelog.
Greetz Roland


| Fig 1 |
Mean scores representing the degree of knowledge about four ... |
| Fig 2 |
Mean scores representing the level to which respondents trus ... |
| Fig 3 |
Ranking in order of relative importance (from the most to th ... |
| Fig 4 |
Mean scores representing the degree of support for, or oppos ... |
| Fig 5 |
A conceptual framework highlighting the variables that affec ... |


News
1.2.4
- Accept lists for app.post(url, params=[...])
- Allow to use url that starts with the SCRIPT_NAME found in extra_environ
- Fix #16 Default
content-type is now correctly set to application/octet-stream
- Fix #14 and #18 Allow to use
.delete(params={})
- Fix #12
1.2.3
- Fix #10,
now TestApp.extra_environ doesn’t take precedence over a WSGI
environment passed in through the request.
- Removed stray print
1.2.2
- Revert change to cookies that would add " around cookie values.
- Added property webtest.Response.pyquery() which returns a
PyQuery object.
- Set base_url on resp.lxml
- Include tests and docs in tarball.
- Fix sending in webob.Request (or webtest.TestRequest) objects.
- Fix handling forms with file uploads, when no file is selected.
- Added extra_environ argument to webtest.TestResponse.click().
- Fixed/added wildcard statuses, like status="4*"
- Fix file upload fields in forms: allow upload field to be empty.
- Added support for single-quoted html attributes.
- TestResponse now has unicode support. It is turned on by default
for all responses with charset information. This is backward
incompatible change if you rely (e.g. in doctests) on parsed
form fields or responses returned by json and lxml methods
being encoded strings when charset header is in response. In order
to switch to old behaviour pass use_unicode=False flag to
TestApp constructor.
1.2.1
- Added method TestApp.request(), which can be used for
sending requests with different methods (e.g., MKCOL). This
method sends all its keyword arguments to
webtest.TestRequest.blank() and then executes the request.
The parameters are somewhat different than other methods (like
webtest.TestApp.get()), as they match WebOb’s attribute
names exactly (the other methods were written before WebOb existed).
- Removed the copying of stdout to stderr during requests.
- Fix file upload fields in forms (#340) – you could
upload files with webtest.TestApp.post(), but if you use
resp.form file upload fields would not work (from rcs-comp.com
and Matthew Desmarais).
1.2
- Fix form inputs; text inputs always default to the empty string, and
unselected radio inputs default to nothing at all. From Daniele
Paolella.
- Fix following links with fragments (these fragments should not be
sent to the WSGI application). From desmaj.
- Added force_value to select fields, like
res.form['select'].force_value("new_value"). This makes it
possible to simulate forms that are dynamically updated. From
Matthew Desmarais.
- Fixed webtest.Response.mustcontain() when you pass in a
no=[strings] argument.
1.1
- Changed the __str__ of responses to make them more doctest
friendly:
- All headers are displayed capitalized, like Content-Type
- Headers are sorted alphabetically
- Changed __repr__ to only show the body length if the complete
body is not shown (for short bodies the complete body is in the
repr)
- Note: these are backward incompatible changes if you are using
doctest (you’ll have to update your doctests with the new format).
- Fixed exception in the .delete method.
- Added a content_type argument to app.post and app.put,
which sets the Content-Type of the request. This is more
convenient when testing REST APIs.
- Skip links in <script>...</script> tags (since that’s not real
markup).
1.0.2
- Don’t submit unnamed form fields.
- Checkboxes with no explicit value send on (previously they
sent checked, which isn’t what browsers send).
- Support for <select multiple> fields (from Matthew Desmarais)
1.0.1
—
- Fix the TestApp validator’s InputWrapper lacking support for
readline with an argument as needed by the cgi module.
1.0
- Keep URLs in-tact in cases such as
app.get('http://www.python.org') (so HTTP_HOST=www.python.org,
etc).
- Fix lxml.html import, so lxml 2.0 users can get HTML lxml
objects from resp.lxml
- Treat <input type="image"> like a submit button.
- Use BaseCookie instead of SimpleCookie for storing cookies
(avoids quoting cookie values).
- Accept any params argument that has an items method (like
MultiDict)


CallumBennett-Dev is a developer working with C, C#, Haskell, HTML, JavaScript and CSS. He is currently learning Haskell, Swift, and C.


new pipeline(initData, http, isolatedConfig, requestContext, locales, cacheHitFn)
context to merge the two environments
| Name | Type | Description |
|---|---|---|
initData |
||
http |
||
isolatedConfig |
||
requestContext |
||
locales |
||
cacheHitFn |
function |
optional
called to send a cached data |
Methods
-
addCacheKey(evidence)
isomorphic/pipeline.js, line 314 -
Adds evidence to cache key. Use this to build up the cache key used to xxx
Name Type Description evidence
string addition evidence used to build the cache key
-
addToHead(field, val)
isomorphic/pipeline.js, line 100 -
Add header to the http response.
Please refer to isomorphicHttp#addToHead for full list of supported tags
Examples:
this.addToHead('title', 'My page title here') this.addToHead('meta', {name: 'description', content:'My SEO SERP description'})
Name Type Description field
val
-
privatebuildMergeObjFromNamespace(obj){*}
isomorphic/pipeline.js, line 236 -
Name Type Description obj
-
getJSON(calcHash, skipJSON){*}
isomorphic/pipeline.js, line 567 -
Name Type Description calcHash
skipJSON
-
isRenderRequired(){boolean}
isomorphic/pipeline.js, line 503 -
Returns if the the render should be aborted
This can be caused by the pipeline being aborted via an operation like a redirect or manual response. Additional if the caching layer does not require a render this will return false.
-
namespace(namespace, fromRoot){*}
isomorphic/pipeline.js, line 197 -
create a new namespace
Name Type Description namespace
fromRoot
-
serveFromCache(dirtyRead, transformCtxFn, next)
isomorphic/pipeline.js, line 363 -
Use pipeline cache to .
let the pipeline lookup
Name Type Description dirtyRead
number use a potentially dirty version to ttl (in ms) if 0 do not server from the cache or -1 to force render
transformCtxFn
transformCtxFn optional used to modify serialize data
next
sendCachedCB -
set(coordinator, obj)
isomorphic/pipeline.js, line 278 -
Name Type Description coordinator
obj
-
setCacheInterface(cacheInterface)
isomorphic/pipeline.js, line 539 -
Set the cache interface this pipeline should use.
Name Type Description cacheInterface
-
signatureCacheData(evidence)
isomorphic/pipeline.js, line 332 -
Adds evidence to around cached data
Use this to help pellet skip full react renders. For example if the cached version was rendered with props {a:1, b:2} and the data from componentConstruction has not changed is safe to skip the render because the markup will be the same. This can safe pellet from having to render react markup and keep using the cached version.
If you do not use this pellet will use the props
Name Type Description evidence
-
statusCode(code){*}
isomorphic/pipeline.js, line 123 -
Get or Set the http status code
Examples:
this.statusCode() this.statusCode(404)
Name Type Description code
-
toJSON(){string}
isomorphic/pipeline.js, line 606 -
Returns a JSON string and a hash
Returns:
the JSON string
-
updateCache(html, next){boolean}
isomorphic/pipeline.js, line 444 -
Update the cache with both the html and serialize data if we do not need to update the cache
Name Type Description html
next
callback Returns:
we need to update the cache


--- layout: post title: AmoebaDB 25 Released category: [AmoebaDB] ---
We are pleased to announce the release of AmoebaDB Release 25


--- layout: post title: 'constrained creativity process update: post 101' date: '2016-09-01T07:22:40-04:00' tags: [] tumblr_url: http://lqb2writes.tumblr.com/post/149789303082/constrained-creativity-process-update-post-101 ---
this morning i wrote my 100th post. i’m spending about 30 minutes per post these days. 20-25 on writing and 5-10 on research and light editing.
i never thought this is where this experiment would be on sept 1st (i’m way farther than i anticipated). given that, i’m pretty pumped about how this could continue to grow.


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/simp.20only.20.5B.5D.html ---
I have a proof which finishes with simp, exact h
, which is not ideal. The goal is the equality of two structures, and one of the fields is another structure; everything is a prop other than two non-defeq terms, which are equal because of h
. I never quite know how to prove these things (I'm proving an ext
lemma for G-module homomorphisms) so I tried squeeze_simp
and it told me to use simp only []
. And lo and behold, simp only []
does work. What does it do?
You can have a look at the proof term by replacing simp
with this:
do { g ← tactic.main_goal, `[simp only []], tactic.trace g },
It will tell you what rules it uses without being asked to.
I have a proof which finishes with
simp, exact h
Doesn't simpa
work here?
Simon Hudon said:
You can have a look at the proof term by replacing
simp
with this:do { g ← tactic.main_goal, `[simp only []], tactic.trace g },It will tell you what rules it uses without being asked to.
eq.mpr (id (eq.trans mk.inj_eq add_monoid_hom.mk.inj_eq)) ?m_1
That function is not in []
!
Patrick Massot said:
I have a proof which finishes with
simp, exact h
Doesn't
simpa
work here?
It does -- thanks. simp [h]
didn't.
The simplifier has built-in support to simplify constructor equalities, which should work for arbitrary inductive types (but in practice it sometimes fails so we have extra simp lemmas in mathlib):
example (a b c d : ℕ) : [a, b] = [c, d] ↔ a = c ∧ b = d := by simp
Last updated: Apr 24 2020 at 19:02 UTC


An alternative app store by free developers for free devices. The database of apps is hosted https://banana-hackers.gitlab.io/store-db , further can be added by a pull request.
Your privacy is important to us, that's why we try to collect only the data that we need to provide the service to you.
We rely on gitlab pages for hosting the data, this service might store cookies and save your ip address https://about.gitlab.com/privacy/
We only link to the app packages, we don't host them ourselves so when downloading apps you will download them from thirdparty servers who can then see your ip address.
When using the app we fetch the download count for all apps from our ratings server. This request might be logged, but we don't explicitly store your ip address.
When downloading apps a request to the download counter will be made to increase it, this request contains:
When fetching the ratings for an app the server gets the requested appname and the ip address but it is not explicitly saved.
When rating apps we store your nickname and your ratings on our server to make the service possible.
Besides from counting downloads we don't do any analytics. But the apps you download might do it, have ads or even track you. We try to label apps that have tracking and/or advertisement.
This service is community maintained and provided on a best-effort basis. We try our best make sure the data is correct, but we do not give any warranties that the information is correct. Use this service on your own risk.
If you see an app that violates you rights or does bad stuff with your device, please report it on gitlab issues


This is paragraph, fullspace in horizontal
This is paragraph, with attribute id = paragraphID
This is paragraph, with attribute class = paragraphClass
Span 1 Span 2 Span 3
Inclined Text Bolded TextDiv 1
Div 2
Paragraph 1
Paragrph 2.1
Paragrph 2.2
child 1
child 2


1
There was
olive on my pizza.
an
2
The
3
I put the letter in
envelope before posting it.
an
4
Anna saw
snake in her garden.
a
5
My mother is
artist.
an
6
“What is
time now?” Peter asked.
the
7
Susan had
glass of water before going to bed.
a
8
The


{% load djng_tags %} {% angularjs %}
etcd is a distributed key-value store that provides a reliable way to store data across a cluster of machines. There are basically three roles for each node. a Leader that issues an instruction, a Follower that follows it in order, and a Candidate that appears temporarily when there is no Leader. etcd gracefully handles leader elections during will tolerate machine failure, including the leader.
Settings