Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
GRDDL is a mechanism for Gleaning Resource Descriptions from Dialects of Languages. The GRDDL specification introduces markup for declaring that an XML document includes gleanable data and for linking to an algorithm, typically represented in XSLT, for gleaning the RDF data from the document.
The markup includes a namespace-qualified attribute for use in general-purpose XML documents and a profile-qualified link relationship for use in valid XHTML documents. The GRDDL mechanism also allows an XML namespace document (or XHTML profile document) to declare that every document associated with that namespace (or profile) includes gleanable data and for linking to an algorithm for gleaning the data.
A corresponding GRDDL specification provides complete technical details. A GRDDL Primer demonstrates the mechanism on XHTML documents which include widely-deployed dialects, more recently known as microformats.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a Working Group Note, developed by the GRDDL Working Group.
As of the publication of this Working Group Note the GRDDL Working Group has completed work on this document. Changes from the previous Working Draft are indicated in a log of changes. Comments on this document may be sent to<EMAIL_ADDRESS>(with public archive). Further discussion on this material may be sent to the Semantic Web Interest Group mailing list<EMAIL_ADDRESS>(also with public archive).
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
There are many dialects of XML in use by documents on the web. There are dialects of XHTML, XML and RDF that are used to represent everything from poetry to prose, purchase orders to invoices, spreadsheets to databases, schemas to scripts, and linked lists to ontologies. Some are formally defined and others allow for more freedom of interpretation. Recently, two progressive encoding techniques, RDFa and microformats, have emerged to overlay additional semantics onto valid XHTML documents. These techniques offer simple, open data formats built upon existing and widely adopted standards.
While this breadth of expression is quite liberating, inspiring new dialects to codify both common and customized meanings, it can prove to be a barrier to understanding across different domains or fields. How, for example, does software discover the author of a poem, a spreadsheet, or an ontology? And how can software determine whether any two of these authors in fact refer to the same person?
Any number of the XML documents on the web may contain data whose value would increase dramatically if they were accessible to systems which might not directly support such a wide variety of dialects but which do support RDF.
The Resource Description Framework[RDFC04] provides a standard for making statements about resources in the form of a subject-predicate-object expression. One way to represent the fact "The Stand's author is Stephen King" in RDF would be as a triple whose subject is "The Stand," whose predicate is "has the author," and whose object is "Stephen King". The predicate, "has the author" expresses a relationship between the subject (The Stand) and the object (Stephen King). Using URIs to uniquely identify the book, the author and even the relationship would facilitate software design because not everyone knows Stephen King or even spells his name consistently. (see RDF primer)
RDF includes an abstract syntax and an XML concrete syntax (RDF/XML). Software tools that use RDFS can generally read data encoded as RDF/XML
GRDDL is a mechanism for Gleaning Resource Descriptions from Dialects of Languages; that is, for extracting RDF data from XML documents by way of transformation algorithms, typically represented in XSLT. The results of the transformations will usually be RDF/XML documents, although other RDF syntaxes may be used.
For example, Dublin Core metadata can be written in an HTML dialect[RFC2731] that has a clear correspondence to an encoding in RDF/XML[DCRDF]. The following HTML and RDF excerpts illustrate the correspondence.
HTML :
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Some Document</title> <meta name="DC.Subject" content="ADAM; Simple Search; Index+; prototype" /> ... </head> ... </html>
RDF/XML :
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > <rdf:Description rdf:about=""> <dc:subject>ADAM; Simple Search; Index+; prototype</dc:subject> </rdf:Description> </rdf:RDF>
The transformation algorithm to convert between the different formats can be specified using XSLT, in this case dc-extract.xsl.
This document collects a number of motivating use cases together with their goals and requirements for extracting RDF data from XML documents. These use cases also illustrate how XML and XHTML documents can be decorated with microformats, Embedded RDF or RDFa statements to support GRDDL transformations in charge of extracting valuable data that can then be used to automate a variety of tasks.
The companion GRDDL Working Draft is a concise technical specification of the GRDDL mechanism and its XML syntax. It specifies the GRDDL syntax to use in valid XHTML and well-formed XML documents, as well as how to encode GRDDL into namespaces and HTML profiles.
The companion document, the GRDDL Primer Working Draft, is a progressive tutorial on the GRDDL mechanism with illustrated examples taken from the GRDDL Use Cases Working Draft.
The seven use cases detailed below could be summarized as:
This collection of use cases only considers cases where the initial sources are well-formed XML documents. Other kinds of sources are outside the scope of the GRDDL working group.
Jane is trying to coordinate a meeting with her friends Robin, David and Kate. They each live in separate cities but often bump into each other at different conferences throughout the year. Jane wants to find a time when all of her friends are in the same city.
Despite their different formats, the calendars of all four friends can be used as GRDDL source documents and converted to RDF. Once expressed as RDF the data can be merged and queried using tools such as the SPARQL query language.
Jane uses a GRDDL-aware agent to automatically extract data from each page, load this data in an RDF store and combine it in a single model. She then writes a query to filter the events down to those dates when all four friends are in the same city.
Jane is delighted to find that all four of them will be at conferences in LA at the beginning of September and she immediately starts looking for restaurants to book for their night out.
Browsing the calendar of her friends, Jane noticed various conferences, talks, and other gatherings of social groups in her area. These groups publish their calendars in various HTML-based formats: microformats, eRDF, RDFa, or some home-grown ways of expressing calendar information.
These calendars are source documents and thus Jane could easily add all of these events to her own calendar. However, Jane does not want to add all these events to her calendar. She wants to pick and choose which events to attend. She wants to browse this list of events and each time she finds an event she is interested in, she wants to be able to select it and copy-paste it to her calendar.
To enable this copy-paste, Jane's browser includes a GRDDL-aware agent and supports a default RDF-in-HTML embedding scheme called RDFa. The GRDDL transformation specified in the page indicates how to transform this XHTML into XHTML+RDFa, while preserving the style and layout of the page.
Thus, Jane's RDFa-aware browser can perform the transform even before rendering the XHTML. The rendered XHTML+RDFa provides a copy- paste functionality via, right-clicking on an event right in the rendered XHTML+RDFa.
See also: microformat, Embedded RDF, RDFa, RSS 1.0.
Kayode, a developer for a clinical research data management system, uses XML as the main representation format for their computer-based patient record. He currently edits the XML remotely via forms and submits the XML document to a unique URI for each such record over HTTP. But elsewhere Kayode has found RDF queries useful for investigative querying.
He wants to use a content management system which includes a mechanism to automatically replicate an XML document into equivalent, named RDF graphs for persistence in synchrony with any changes to the document.
The expense of dual representation as single-purpose XML vocabulary and RDF includes space and synchrony problems, but the primary value is being able to query both as XML and as RDF. The corresponding XML documents can be transformed into other non-RDF formats, evaluated by XPath and XPointer expressions, cross-linked by XLink or XInclude, and structurally validated by RELAX NG (or XML Schema). With the RDF query facility Kayode can ask speculative questions using standard healthcare ontologies for patient records, such as the HL7 OWL ontology.
Kayode realizes a GRDDL approach can alleviate the expense of maintaining a dual representation by allowing a computer-based patient record or any XML-based collection of clinical research data to be queried semantically by associating a GRDDL profile to the specific XML vocabulary.
Using RDF helps manage research projects assigned to residents. Kayode finds RDF especially helpful while trying to determine an initial search criteria for a patient population relevant to a particular study. Each study has a set of classifications specific to the study that they express in an ontology or using rules.
Kayode designs a web-based user interface that works with a GRDDL-aware agent which picks computer-based patient records from a remote server. Each is a source document associated with transforms that extract clinical data as RDF expressed in a universally supported vocabulary for a computer-based patient record.
The resident physicians then ask speculative questions of the resulting RDF graph or apply the study-specific rules on the resulting RDF to classify the data according to his domain of interest, such as specific diagnoses and pathological observations.
For Kayode, having an RDF representation of the clinical data provides him advantages over just using a single-purpose XML vocabulary, in particular an additional level of interpretation and ability to integrate data from diverse sources. The inherent difficulties of using multiple XML vocabularies over domains such as clinical data make the mapping to a unified ontology even more valuable.
See also: GALEN / Open GALEN, 4Suite, HCLSIG HL7 OWL Ontology
Stephan wishes to buy a guitar, so he decides to check reviews. There are various special interest publications online which feature musical instrument reviews. There are also blogs which contain reviews by individuals. Among the reviewers there may be friends of Stephan, people whose opinion Stephan values (e.g. well-known musicians and people whose reviews Stephan has found useful in the past). There may also be reviews purposively planted by instrument manufacturers which offer very biased views.
Stephan visits a site offering a review service and enters his preference for guitar reviews which gave a high rating for the instrument. This initial request is answered with a list of all the relevant review titles/summaries together with information about the reviewers.
From this list Stephan chooses only the reviewers he trusts, and on submitting these preferences is finally presented with a set of full reviews which match his criteria.
Reviews published using hReview microformats can be discovered using existing search services. These source documents can be consumed by a GRDDL-aware agent to extract the RDF which is then aggregated together in a store. Information about the reviewers can also be aggregated from various sources including hCard and XFN microformats and autodiscovered FOAF profiles possibly harvested through links in Stephan's own profile. The filtering may be achieved by running SPARQL queries against the aggregated data, presented to the user through regular HTML form interfaces.
See also: hReview, hCard, XFN.
The Company DC4Plus uses its web site to publish its catalogue of products and services as well as a number of digital documents both on their public web site (white papers, user guides and technical manuals of products and brochures) and on their intranet (internal reports and administrative forms). Product after product, DC4Plus is growing a digital library as part of its web site.
Adeline is an IT manager at DC4Plus. She is concerned by the tension between, on one hand, the natural heterogeneity and distribution of all these electronic documents and, on the other hand, the need to have an integrated and unified view of all these productions. She believes there is a need to automate the detection, indexing and search capabilities for these documents. Moreover several corporate documents follow a standard process before being published and there is a growing demand from users and managers to be able to automate this process and follow the status of each document.
Adeline first focuses on the Technical Reports published by the different divisions of DC4Plus. These reports are published following a well-defined process. She proposes a system that relies on Semantic Web technologies to allow her company to streamline the publication paper trail of Technical Reports, to maintain an RDF-formalized index of these specifications and to create a number of tools using this newly available data.
Adeline's implementation of this vision at DC4Plus can be given in five steps:
This system relies on shared templates for publishing documents and including RDFa annotations to mark important data. A GRDDL-aware agent extracts this metadata as RDF. By crawling the published reports and applying the associated GRDDL transformations to them, a complete and up-to-date RDF index is built from resources distributed over the organization's website. This RDF index is then used to create a central yet flexible authoritative repository.
Adeline believes that this scenario can be generalized to any organization interested in maintaining a portal to a digital library with customized indexes, dedicated search forms, navigation widgets. In particular she appreciates that in such an architecture the simple fact that the XHTML documents put online following official templates allow GRDDL-aware agents to extract corresponding RDF annotations that can then be used to generate portals, feed workflow engines and run queries directly against the site.
See also: Automating the publication of Technical Reports
The Technical University of Marcilly (TMU) decided to use wikis to foster knowledge exchanges between lecturers and students. They tested several wikis over the years and they want to experiment with novel ways of structuring the wiki to improve navigation and retrieval and they also want to make it easier to reuse learning objects in different contexts. Ideally TMU wants the information structuring the wiki to be:
In this context TMU uses metadata embedded in the wikipages to:
Let us consider the case of Michel, a lecturer in engines and thermodynamics. He used the wiki to publish the handouts of his course. He initially tagged each handout with the main concepts it introduces (e.g. "RenewableEnergies", "Ethanol", "Diesel"). In addition, Michel automatically typed each section of the document using predefined styles (e.g. definitions, formula, example.). The next practical session will involve knowledge on classical Diesel engines and Ethanol-based engines. In order to generate a mnemonic card for this session Michel runs a query to extract definitions and formulas of the courses tagged with "Diesel" or "Ethanol". He also uses these tags to generate dynamic "see also" sections at the end of his sections suggesting other sections to read.
Students edit the online handouts, to add pointers, to insert comments on parts they found difficult to understand,and to recall pieces of previous courses useful for understanding a new course. Students also tagged the pages with their own tags to organize their reading and bookmark important parts for them; they use tags to create transversal thematic tracks (e.g. "LiquidFlow"), to give feedback on the content (e.g. "Difficult"), to prioritise reading (e.g. "NiceToKnow", "Vital"). These tags allow them to have transversal navigation and reorganize the content depending on the task they are doing (e.g. preparing an exam, writing a report, running an experiment). These tags are also used by Michel to evaluate the understanding and the shortcomings of his course.
Finally the mass of the course material and tags is such that it needs to be reorganised. Using the tag editor Michel groups "Ethanol" and "Methanol" as sub tags of a new tag he calls "Alcohol". Doing so the pages tagged with "Ethanol" or "Methanol" are grouped and accessible through "Alcohol". He repeats this with other tags (e.g. "Alcohol" and "Hydrogen" becomes sub- tags of "NewEngineEnergy"). This reorganizes the wiki seamlessly e.g. suggestion of navigation in the pages automatically propose narrower, broader and brother tags thus when viewing a page tagged with "Ethanol", the system suggest other pages tagged with "Methanol". Later when a student posts his report on an engine using "CopraOil", his new tag can be placed under the existing one "NewEngineEnergy"; he or anyone else can do it and the result will immediately benefit the whole community of the users. Using these tags and their organization, thematic indexes are dynamically generated for the materials of the course and automatically updated.
From the technical stand point, TMU designed a wiki that stores its pages directly in XHTML and RDF annotations are used to represent the wiki structure and annotate the wikipages and the objects it contains (images, uploaded files.). The RDF structure allows refactoring the wiki structure by editing the RDF annotations and the RDFS schemas they are based on. RDF annotations are embedded in the wiki pages themselves using the RDFa and microformats. Some of the learning objects can be saved in XML formats and an XSLT stylesheet exploits the styles used for the session to tag the different parts (e.g. definition, exercise, example) and these annotation can then be used to generate new views on this resource (e.g. list of definition, hypertext support for practical sessions.).
The embedded RDF is extracted by a GRDDL-aware agent using GRDDL transformations available online as XSLT stylesheets to provide semantic annotations directly to the application that needs to extract the embedded metadata:
See also: Sweet Wiki, Semantic Wikis
Voltaire's blog is pretty popular and encompasses many major areas of interest, one of which is bird watching. Voltaire has so many areas of interests and spends so much time watching birds that he doesn't want to surf the net and find each and every site he might want to syndicate. Rather than 'manually' subscribing to third-party blogs that are appropriate to the themes he covers, he wants to reverse the subscription model to be push-based i.e. people who want their blogs to be included can push the appropriate entries to his blog; his blog becomes somewhat of a magnet for similar entries of interest.
Voltaire has setup a weblog engine that utilizes XForms for editing entries remotely using the Atom Publishing Protocol. Voltaire has found the use of XForms for authoring fragments of Atom quite useful for a variety of reasons. In particular, the Atom Publishing Protocol uses HTTP and a single-purpose XML vocabulary as its primary remote messaging mechanism, which allows Voltaire to easily author various XForm documents that use XForm submission elements to dispatch operations on web resources.
As a result, the XForms for dispatching these operations each contain a rather rich set of information about transport-level services in the form of service URIs, media-types and HTTP methods. These are completely encapsulated in an XForms submission element. It so happens that there is an RDF vocabulary for expressing transport metadata called RDF Forms.
Somewhere else on the planet, the professional ornithologist Johan Bos, who recently spotted a red kite (Milvus milvus) far from their breeding ground in central Wales, is planning to post blog entries about his observations. To make his results visible he wants his entries to be included in Voltaire's blog.
Voltaire's site provides a general GRDDL transformation that extracts an RDF Form graph from the XForms submission elements employed in the various web forms for editing, deleting, and updating Atom entries on his weblog. Such a transformation can uniformly extract an RDF description of the transport mechanisms for a software agent to interpret. Johan's client can automatically retrieve an Introspection Document (via the Atom Publishing Protocol), update existing entries using the identified service URIs, and perform other such services.
Thus Johan's client relies on a GRDDL-aware agent to periodically extract the service URIs, transform the content at these URIs to Atom/OWL and query the resulting RDF to determine if the topics match. Doing so, he will replicate his entries at the matching URIs by POSTing them there.
Voltaire does not need to manage the subscriptions, all he might want to do is perhaps grant accounts for Johan for HTTP-level authentication (as a deterrent for spam - as you can imagine, reversing the subscription model in this way opens up Voltaire's system for lots of spam).
See also: XForms 1.1 specification, Atom Publishing Format and Procotol (atompub).
The Open Archives Initiative (OAI) publishes an XML schema that universities can use to publish their archived documents. They include guidelines for expressing the rights of these documents, including the possibility of referencing a license, like a creative commons license.
More than 800 universities implement this schema. Creative Commons would like to deploy tools, like the MozCC browser extension which provides a convenient way to examine licenses embedded in web pages and interpret them.
It is unreasonable to expect to interpret everyone's favorite XML schema, yet communities like the OAI would like to be able to include licensing information in their XML shema.
On the other hand, Creative Commons would like to be able to make a generic recommendation to anyone with XML instance documents, allowing them to do what they want with their XML schemata, as long as they include a transformation of the instance documents to RDF.
Since the XML instance documents are often distributed, as in the OAI case, the XML schema itself could embed RDF descriptions identifying a transform to apply to all its instance documents. So doing, for each source document, the transformation is indirectly referenced by the XML Schema it follows.
The XML schema is served from the namespace location and is a source document which includes descriptions associating a GRDDL transform with its instances. Thus it serves a dual purpose for its instances: (1) validation and (2) identifying transforms to glean meaning.
See also: Open Archives Initiative, Creative Commons, MozCC.
Steffen is interested in maintaining a directory of people he works with. Whenever he gets in touch with someone, he starts a simple script that aims at gathering as much metadata about this person as possible. The script first calls a search engine with keywords he has chosen e.g. "Jean-Paul Haton LORIA". The script receives a list of URL of web pages considered relevant by the search engine.
Because most of these web pages are non-XHTML HTML and because most of the time they are not even valid HTML, the script first checks if each page is a well-formed XML document. If the page is indeed a well-formed XML document the script just calls a GRDDL-aware agent on this page to extract metadata it may contain.
If the page is not a well-formed XML document the script proceeds with calling an HTML-tidying tool that retrieves the page, cleans the page the best it can, and so outputs an XHTML version. The script saves these XHTML versions locally making sure that the base URI of each local copy is specified and if not the script sets it to the URI of the initial HTML page. Finally the script calls a GRDDL agent on each local copy to extract the metadata they may contain.
Using his script Steffen found that several cases occur:
While one can use GRDDL to extract RDF from non-XHTML HTML source documents, unless there is good reason otherwise, the authors of content should deploy GRDDL with valid XML such as XHTML. Simply put, it is easier for authors to explicitly license a transformation from XML documents where there is no dependency on any other algorithms (such as a tidying algorithm). Although tidying of source documents can be part of a pragmatic approach to gathering data, the consumer of the RDF can only trust GRDDL transformations when they have been explicitly licensed by the author of the documents.
This use-case uses a feature that is not, and will not be, included in the GRDDL Working Draft. It should be addressable in the future using the mechanims described in the HTTP Header Linking Draft once that is accepted by the IETF as an RFC.
Oceanic is part of a consortium of airlines that have a group arrangement for the shared supply and use of aircraft spares. The availability and nature of parts at any location are described by AirPartML, an internationally-agreed XML dialect constrained by a series of detailed XML Schema. Each member of the consortium publishes the availability of their spares on the web using AirPartML. These descriptions can subsequently be searched and retrieved by other consortium members when seeking parts for maintenance. The protocol for use of the descriptions requires invalid documents to be rejected. Oceanic wishes to also publish RDF descriptions of their parts and would prefer to reuse the AirPartML documents which are produced by systems that have undergone exhaustive testing for correctness. There is no provision in the existing schemas for extension elements and changing the schemas to accommodate RDF would require an extended international standardisation effort, likely to take many years. This means they cannot alter their XML documents to use GRDDL.
Using the ability of HTTP Header Linking Draft to specify Link and Profiles for GRDDL transformation in HTTP Headers, Oceanic Consortium can serve RDF via GRDDL without altering their XML documents.
See also: HTTP Header Linking
The editor greatfully acknowledges the contributions of the following Working Group members:
Changes since the 2 October 2006 Working Draft include:
This document is a product of the GRDDL Working Group.


|
Address
Books
|
|
|
|
You
can move between MY address book and Global address book by using the links on
the right side of the Address book tab. |
|
|
|
The Global address
book |
|
|
|
Global list – contains all ProQuest office contacts.
|
|
|
|
To view click “View Global Address Book” and then “Show all Global
Addresses”.
|
|
|
|
When using this global book the system will only enter an address, you must
specify a contact at the selected destination.
|
|
|
|
Only Super Users can add addresses to the Global book, all requests should
be sent to Jo Uttley.
|
|
|
|
My address book |
|
|
|
All individual contacts i.e. distributor addresses. |
|
|
|
To view all addresses click “Show my full address list”. |
|
|
|
To add a new address to your personal address book click “new”. |
|
|
|
Fill all of the address details into the form, along with a contact telephone
number for the recipient and “add” to my address book. |


{{ block title }} Round {{ current_round }} out of {{ total_number_rounds }} {{ endblock }} {{ block content }}
You are the leader in this round.
You have a budget of {{ budget }}.
The multiplier is {{ multiplier }}.
{{ formfield "contribution" }} {{ next_button }} {{ endblock }}


LTA awards S$210 million contract for Jurong West, Bahar Junction MRT stations
SINGAPORE: Two Jurong Region Line stations will be designed and constructed by the Singapore branch of China Railway 11 Bureau Group, the Land Transport Authority said on Monday (Dec 9).
The S$210.1 million contract for the Jurong West and Bahar Junction stations also includes 1.15km of viaducts.
Jurong West station will be located along Jurong West Avenue 2, adjacent to Jurong West Street 23. The station will have a single island platform serving trains for both the Choa Chu Kang-bound and Jurong Pier-bound directions.
READ: Jurong Region Line to serve NTU, Tengah estate, Jurong Industrial Estate
Bahar Junction station will be located along Jurong West Avenue 4, near the junction of Jurong West Street 64 and Street 75. It will have two platforms connected by a 100-metre covered link bridge with travellators.
One platform will serve trains heading to Choa Chu Kang and Jurong Pier while the other platform will serve trains heading to Peng Kang Hill.
LTA said the Singapore branch of the China Railway 11 Bureau Group is an "established and experienced” construction company that has completed various rail-related projects worldwide.
The company has completed several major infrastructure projects in Singapore including three MRT stations - Tuas Link, Tuas West Road and Tuas Crescent stations - and their associated viaducts on the East-West Line’s Tuas West Extension.
“The company also constructed Singapore’s first integrated rail and road viaduct as part of the Tuas West Extension project,” LTA added.
READ: Work to construct 5 MRT stations on Jurong Region Line to start in 2020
READ: Residents, workers disappointed by Jurong Region Line land acquisition plans
The Jurong Region Line is Singapore’s seventh MRT line, which will open in three stages starting from 2026.
The 24km-long line will have 24 stations above ground, and will connect with the North-South Line and East-West Line with interchange stations at Boon Lay, Choa Chu Kang and Jurong East MRT stations.
The Jurong Region Line is expected to serve 200,000 commuters daily in its initial phase of operation. This is expected to grow to more than 500,000 commuters daily in the longer term, according to LTA.
Construction is expected to start in 2020 and be completed in 2026.


You are not authorized to view this encounter.
| Resident | Type | Encountered | Submitted |
|---|---|---|---|
| <%= @encounter.user.present? ? @encounter.user.name : "Unknown" %> | <%= @encounter.encounter_type %> | <%= @encounter.encountered_on %> | <%= @encounter.created_at.to_date %> |


Displaying File Status and History
You can display the following types of information about files:
- File status: the current state of the file as managed by Perforce,
indicated by label decorations
- File properties: location, number of revisions, and so on. Displayed
on the Perforce Properties dialog.
- Revision history: the changes that have been checked into the depot,
including a description of the change, date, user, and so on.
- Submitted changelists: previously-submitted changelists, including
a list of files submitted.
You can also search the contents of files under Perforce control using a grep-style search.
File Status
To view the status of open files, examine the file icons in the P4 Pending
Changelist view. The label decorations displayed on the icons indicate
the status of the file. For example, the following figure shows files open for
delete (red x), edit (red check mark), and add (red +).
File Properties
To display file properties:
- Right-click the file in the Navigator view and choose Properties.
- Click Perforce. File properties are displayed as shown in the following
figure.
Note that the head revision is the revision most recently checked in,
and the have revision is the one last synced to your workspace.
Revision History
To display the revision history of a file, right-click the file and choose
Revision History.
The History view lists the following details about the revisions
of a file that have been submitted to the Perforce depot:
- Revision: the revision number of the file. Every time you (successfully)
submit the file, its revision number is incremented.
- Changelist: the changelist number associated with the file revision
when it was submitted to the depot. This number is assigned by Perforce, and
is used to group related files when submitting them. For example, if you change
several files in the process of fixing a bug or adding a feature, the changelist
number identifies the point at which the change was submitted. You can use
the changelist number to sync the files to your workspace as a group.
- Date: the date the changelist was submitted.
- User: the Perforce user name of the user who submitted the changelist
- Action: the action perforce on the file, for example, add, edit,
or delete.
- Description: details about the changelist, entered by the user who
submitted the changelist.
To compare two revisions to see what changes have been made, select the desired
revisions, then right-click and choose Diff Two Revisions. The Diff
Two Revisions dialog is displayed, highlighting the differences between
the files, as shown in the following figure.
Submitted Changelists
To display a list of previously-submitted changelists, click the P4 Submit tab. To display details for a submitted changelist, click the desired changelist. Details are displayed in the pane below the list.
Searching File Content
To search the contents of files in a Perforce depot:
- Click the toolbar Search button. The Search dialog is displayed.
- Click the P4 Grep tab.
- Specify the text you are seeking, the files to be searched, and any search options.
- Click Search. Results are displayed in a Search results tab.
- To display the contents of file that contains the search text, double-click it in the Search pane. To locate an instance of the search text in the file, expand the results for the file and double-click the line that displays details about the instance.
You can also search file text from the P4 Submit view.


plm tries to follow as close as possible the way models are fitted using lm
. This relies on the following steps, using the formula
-data
:
model.frame
by getting the relevant arguments (formula
, data
, subset
, weights
, na.action
and offset
) and the supplementary argument,model.frame
the response (with model.response
) and the model matrix (with model.matrix
),plm.fit
with X
and y
as arguments.with some modifications.
Firstly, panel data has a special structure which is describe by an index
argument. This can be used in the pdata.frame
function which returns a pdata.frame
object which can be used as the data
argument of plm
. If the data
argument of plm
is an ordinary data.frame
, the index
argument can also be used as an argument of plm
. In this case, the pdata.frame
function is used internally to transform the data.
Next, the formula
, which is the first and mandatory argument of plm
is coerced to a Formula
object.
model.frame
is then called, but with the data
argument in the first position (a pdata.frame
object) and the formula
in the second position. This unusual order of the arguments enables to use a specific model.frame.pdata.frame
method defined in plm
.
As for the model.frame.formula
method, a data.frame
is returned, with a terms
attribute.
Next, the X
matrix is extracted using model.matrix
. The usual way to do so is to feed the function with to arguments, a formula
or a terms
object and a data.frame
created with model.frame
. lm
use something like model.matrix(terms(mf), mf)
where mf
is a data.frame
created with a model.frame
. Therefore, model.matrix
needs actually one argument and not two and we therefore wrote a model.matrix.pdata.frame
which does the job ; the method first check that the argument has a term
attribute, extract the terms
(actually the formula
) and then compute the model.matrix
.
The response y
is usually extracted using model.response
, with a data.frame
created with model.frame
as first argument, but it is not generic. We therefore create a generic called pmodel.response
and provide a pmodel.response.pdata.frame
method. We illustrate these features using a simplified (in terms of covariates) example with the SeatBelt
data set:
library("plm")
data("SeatBelt", package = "pder")
$occfat <- with(SeatBelt, log(farsocc / (vmtrural + vmturban)))
SeatBelt pdata.frame(SeatBelt) pSB <-
We start with an OLS (pooling
) specification:
occfat ~ log(usage) + log(percapin)
formols <- model.frame(pSB, formols)
mfols <- model.matrix(mfols)
Xols <- pmodel.response(mfols)
y <-coef(lm.fit(Xols, y))
## (Intercept) log(usage) log(percapin)
## 7.4193570 0.1657293 -1.1583712
which is equivalent to:
coef(plm(formols, SeatBelt, model = "pooling"))
## (Intercept) log(usage) log(percapin)
## 7.4193570 0.1657293 -1.1583712
Next we use an instrumental variables specification. usage
is endogenous and instrumented by three variables indicating the law context: ds
, dp
and dsp
.
The model is described using a two-parts formula, the first part of the RHS describing the covariates and the second part the instruments. The following two formulations can be used:
occfat ~ log(usage) + log(percapin) | log(percapin) + ds + dp + dsp
formiv1 <- occfat ~ log(usage) + log(percapin) | . - log(usage) + ds + dp + dsp formiv2 <-
The second formulation has two advantages:
-
sign in the second RHS part of the formula.The formula is coerced to a Formula
, using the Formula
package. model.matrix.pdata.frame
then internally calls model.matrix.Formula
in order to extract the covariates and instruments model matrices:
model.frame(pSB, formiv1)
mfSB1 <- model.matrix(mfSB1, rhs = 1)
X1 <- model.matrix(mfSB1, rhs = 2)
W1 <-head(X1, 3) ; head(W1, 3)
## (Intercept) log(usage) log(percapin)
## 8 1 -0.7985077 9.955748
## 9 1 -0.4155154 9.975622
## 10 1 -0.4155154 10.002110
## (Intercept) log(percapin) ds dp dsp
## 8 1 9.955748 0 0 0
## 9 1 9.975622 1 0 0
## 10 1 10.002110 1 0 0
For the second (and preferred formulation), the dot
argument should be set and is passed to the Formula
methods. .
has actually two meanings:
which correspond respectively to dot = "seperate"
(the default) and dot = "previous"
. See the difference between the following two examples:
library("Formula")
head(model.frame(Formula(formiv2), SeatBelt), 3)
## occfat log(usage) log(percapin) state year farsocc farsnocc usage
## 8 -3.788976 -0.7985077 9.955748 AK 1990 90 8 0.45
## 9 -3.904837 -0.4155154 9.975622 AK 1991 81 20 0.66
## 10 -3.699611 -0.4155154 10.002110 AK 1992 95 13 0.66
## percapin unemp meanage precentb precenth densurb densrur
## 8 21073 7.05 29.58628 0.04157167 0.03252657 1.099419 0.1906836
## 9 21496 8.75 29.82771 0.04077293 0.03280357 1.114670 0.1906712
## 10 22073 9.24 30.21070 0.04192957 0.03331731 1.114078 0.1672785
## viopcap proppcap vmtrural vmturban fueltax lim65 lim70p mlda21 bac08
## 8 0.0009482704 0.008367458 2276 1703 8 0 0 1 0
## 9 0.0010787370 0.008940661 2281 1740 8 0 0 1 0
## 10 0.0011257068 0.008366873 2005 1836 8 1 0 1 0
## ds dp dsp
## 8 0 0 0
## 9 1 0 0
## 10 1 0 0
head(model.frame(Formula(formiv2), SeatBelt, dot = "previous"), 3)
## occfat log(usage) log(percapin) ds dp dsp
## 8 -3.788976 -0.7985077 9.955748 0 0 0
## 9 -3.904837 -0.4155154 9.975622 1 0 0
## 10 -3.699611 -0.4155154 10.002110 1 0 0
In the first case, all the covariates are returned by model.frame
as the .
is understood by default as “everything”.
In plm
, the dot
argument is internally set to previous
so that the end-user doesn’t have to worry about these subtleties.
model.frame(pSB, formiv2)
mfSB2 <- model.matrix(mfSB2, rhs = 1)
X2 <- model.matrix(mfSB2, rhs = 2)
W2 <-head(X2, 3) ; head(W2, 3)
## (Intercept) log(usage) log(percapin)
## 8 1 -0.7985077 9.955748
## 9 1 -0.4155154 9.975622
## 10 1 -0.4155154 10.002110
## (Intercept) log(percapin) ds dp dsp
## 8 1 9.955748 0 0 0
## 9 1 9.975622 1 0 0
## 10 1 10.002110 1 0 0
The IV estimator can then be obtained as a 2SLS estimator: first regress the covariates on the instruments and get the fitted values:
lm.fit(W1, X1)$fitted.values
HX1 <-head(HX1, 3)
## (Intercept) log(usage) log(percapin)
## 8 1 -1.0224257 9.955748
## 9 1 -0.5435055 9.975622
## 10 1 -0.5213364 10.002110
Next regress the response on these fitted values:
coef(lm.fit(HX1, y))
## (Intercept) log(usage) log(percapin)
## 7.5641209 0.1768576 -1.1722590
Or using the formula
-data
interface with the ivreg
function:
coef(AER::ivreg(formiv1, data = SeatBelt))
## (Intercept) log(usage) log(percapin)
## 7.5641209 0.1768576 -1.1722590
or plm
:
coef(plm(formiv1, SeatBelt, model = "pooling"))
## (Intercept) log(usage) log(percapin)
## 7.5641209 0.1768576 -1.1722590


I'm A Celebrity: Kate Garraway's husband Derek struggling without her as he's 'never cooked a proper meal'
Trouble in the kitchen
by Richard BellPresenter Kate Garraway left her husband Derek Draper to look after their two kids when she jetted off to take part in this year's I'm A Celebrity... Get Me Out Of Here!
The Good Morning Britain host, 52, has already had to contend with swarms of cockroaches and other nasties crawling all over her - including up her "noo noo" - but it appears her husband has faced struggles of his own.
Derek Draper, who shares daughter Darcey, 13, and son William, 10, with Kate, took to social media to pose a cookery question to his followers as he had "never cooked a proper meal" in his life.

He wrote alongside the pic: "Mum @kategarraway is in the jungle. Dad has never cooked a proper meal in his life.
"Daughter demands her usual Sunday roast, 'Mum would do it if she were here'.
"So Dad's doing his best, though you might spot a few cheats. Any suggestions for shortcuts for stuffing? #ImACeleb."
His followers offered their advice, with some telling him to try Aunt Bessie's ready-made stuffing and others telling him he'd better just take the kids to a carvery.
One suggested, "Aunt Bessie's ready-made and frozen. Bung it in the oven... take it out" and another wrote, "Carvery in a pub, Derek. Quick, easy and no dishes lol".
A third tweeted: "Well done you, I'm sure Darcey will love it. Enjoy. Go Kate, look forward to watching x."
Read more: I'm A Celebrity star Caitlyn Jenner hiding devastating secret from her past
Derek might be doing his best but it could be hard for fans of I'm A Celeb to feel sorry for him, given what the campmates are having to eat.
Last night's (20.11.19) episode featured the first eating trial of the series, with DJs Roman Kemp and Adele Roberts forced to chow down on some truly gruesome fare - including a bull's penis, pig's uterus and camel's anus.
Not all viewers impressed by the challenge, with some on Twitter branding the segment "dull" and others complaining it was "the same every year".
Leave us a comment on our Facebook page @EntertainmentDailyFix and let us know what you think of this story.


| 003:023 Khan | : |
Have you not seen those who have been given a portion of the Scripture? They are being invited to the Book of Allah to settle their dispute, then a party of them turn away, and they are averse. |
| 003:023 Maulana | : |
Hast thou not seen those who are given a portion of the Book? They are invited to the Book of Allah that it may decide between them, then a party of them turn back and they withdraw. |
| 003:023 Pickthal | : |
Hast thou not seen how those who have received a portion of the Scripture invoke the Scripture of Allah (in their disputes) that it may judge between them; then a faction of them turn away, being opposed (to it)? |
| 003:023 Rashad | : |
Have you noted those who were given part of the scripture, and how they are invited to uphold this scripture of GOD, and apply it to their own lives, then some of them turn away in aversion? |
| 003:023 Sarwar | : |
(Muhammad), consider those who have received a share of the Book. When they refer to the Book in order to judge amongst themselves, a group of them turn away with disregard |
| 003:023 Shakir | : |
Have you not considered those (Jews) who are given a portion of the Book? They are invited to the Book of Allah that it might decide between them, then a part of them turn back and they withdraw. |
| 003:023 Sherali | : |
Hast thou not seen those who have been given their portion of the Book? They are called to the Book of ALLAH that it may judge between them, but a party of them turn away in aversion. |
| 003:023 Yusufali | : |
Hast thou not turned Thy vision to those who have been given a portion of the Book? They are invited to the Book of Allah, to settle their dispute, but a party of them Turn back and decline (The arbitration). |
Concepts/Themes Covered: الإيمان > الغيب > النار > أصحاب النار Faith> The Unseen World> Hell-Fire>Hell Fellows الإيمان > الكتب السماوية الأخرى > الكتب المقدسة Faith> The Other Divine Books> The Holy Books القرآن الكريم > حقيقته وتصديقه للكتب الأوائل The Holy Quran> The Quran's Reality and its confirmation of the Previous Books العلاقات السياسية والعامة > الحكم General and Political Relationships>The Judgement الديانات > بنو إسرائيل > حالاتهم Religions>Children of Israel>Their Status الديانات > بنو إسرائيل > معاندتهم و تكذيبهم و قتلهم الأنبياء Religions>Children of Israel> Their Opposition, their Denial and their Killing the Prophets
This tool uses eight English parallel translations for the Holy Quran imported from Mr. Clay Smith. You can also visit Qurany Concepts for browsing the Quran themes or topics. If you want to search the Holy Quran for keywords, please visit Qurany Keywords.


Fractal
- Drag on an area to zoom in.
- Right click to hide the options.
- Control click for a different equation.
- Middle click to randomize the exponent on the equation
- Shift click for a complex equation
- Shift right click to add a Mandelbrot factor
Fractal Home


Class Root
The root level element of all Silicone menu structures.
The Root element is the foundation for any Silicone menu hierarchy as it handles all of Silicone's callbacks and fires them for its children.
Not all available methods are listed here. For more information, see Base.
Internal
| Root:initialize (spec) | Initializes a Root element |
| Root:_add_name (element) | Adds a named element to the Root's name index |
| Root:_restack_focus () | Reorders the focus stack so that it can be indexed. |
Getters/Setters
| Root:getAbsoluteWidth () | Returns a Root element's width (the screen width) |
| Root:getAbsoluteHeight () | Returns a Root element's height (the screen height) |
| Root:getAbsoluteX () | Returns a Root element's X coordinate (usually 0) |
| Root:getAbsoluteY () | Returns a Root element's Y coordinate (usually 0) |
Querying
| Root:find (key) | Finds an element with the given name. |
Focus Stack
| Root:pushFocus (element, norestack) | Pushes an element onto the focus stack and puts it in focus |
| Root:popFocus (norestack) | Pops the first element from the focus stack |
| Root:peekFocus (norestack) | Returns the first element on the focus stack |
| Root:focus () | Sets focus to the first available element in the focus stack |
Events
| Root:update (dt) | Updates all of a Root's children and resizes it to fit the screen. |
| Root:doLeft () | Calls onLeft for the currently focused element |
| Root:doRight () | Calls onRight for the currently focused element |
| Root:doUp () | Calls onUp for the currently focused element |
| Root:doDown () | Calls onDown for the currently focused element |
| Root:doConfirm () | Calls onConfirm for the currently focused element |
| Root:doCancel () | Calls onCancel for the currently focused element |
Callbacks
| Root:onFocus () | Does nothing |
| Root:onLoseFocus () | Does nothing |
| Root:onMouseMove () | Does nothing |
| Root:onMouseDown () | Does nothing |
| Root:onMouseUp () | Does nothing |
| Root:onLeft () | Does nothing |
| Root:onRight () | Does nothing |
| Root:onUp () | Does nothing |
| Root:onDown () | Does nothing |
| Root:onConfirm () | Does nothing |
| Root:onCancel () | Does nothing |
Internal
Internal methods
- Root:initialize (spec)
-
Initializes a Root element
Parameters:
- spec table Menu specification
- Root:_add_name (element)
-
Adds a named element to the Root's name index
Parameters:
- element Base Menu element
- Root:_restack_focus ()
-
Reorders the focus stack so that it can be indexed.
This must be done regularly as elements in the focus stack may be removed by the garbage collector.
Getters/Setters
Getters and setters for element properties
- Root:getAbsoluteWidth ()
-
Returns a Root element's width (the screen width)
Returns:
-
number
The Root element's width
- Root:getAbsoluteHeight ()
-
Returns a Root element's height (the screen height)
Returns:
-
number
The Root element's height
- Root:getAbsoluteX ()
-
Returns a Root element's X coordinate (usually 0)
Returns:
-
number
The Root element's X coordinate
- Root:getAbsoluteY ()
-
Returns a Root element's Y coordinate (usually 0)
Returns:
-
number
The Root element's Y coordinate
Querying
Methods for finding other elements
- Root:find (key)
-
Finds an element with the given name.
Parameters:
- key string The name of the element
Returns:
-
Base or nil
The element
Focus Stack
Methods for manipulating the focus stack
- Root:pushFocus (element, norestack)
-
Pushes an element onto the focus stack and puts it in focus
Parameters:
- element Base The element to push
- norestack bool Suppress restacking the focus stack
- Root:popFocus (norestack)
-
Pops the first element from the focus stack
Parameters:
- norestack bool Suppress restacking the focus stack
Returns:
-
Base
The popped element
- Root:peekFocus (norestack)
-
Returns the first element on the focus stack
Parameters:
- norestack bool Suppress restacking the focus stack
Returns:
-
Base
The element
- Root:focus ()
- Sets focus to the first available element in the focus stack
Events
Methods for firing events when it's time for the menu to do something
- Root:update (dt)
-
Updates all of a Root's children and resizes it to fit the screen.
Parameters:
- dt number Time since the last update in seconds
See also:
- Root:doLeft ()
-
Calls
onLeft
for the currently focused element - Root:doRight ()
-
Calls
onRight
for the currently focused element - Root:doUp ()
-
Calls
onUp
for the currently focused element - Root:doDown ()
-
Calls
onDown
for the currently focused element - Root:doConfirm ()
-
Calls
onConfirm
for the currently focused element - Root:doCancel ()
-
Calls
onCancel
for the currently focused element
Callbacks
Callbacks do absolutely nothing on Root elements.
- Root:onFocus ()
- Does nothing
- Root:onLoseFocus ()
- Does nothing
- Root:onMouseMove ()
- Does nothing
- Root:onMouseDown ()
- Does nothing
- Root:onMouseUp ()
- Does nothing
- Root:onLeft ()
- Does nothing
- Root:onRight ()
- Does nothing
- Root:onUp ()
- Does nothing
- Root:onDown ()
- Does nothing
- Root:onConfirm ()
- Does nothing
- Root:onCancel ()
- Does nothing


opening access to the digital economy through sharing our model of peer-led learning
Support for cooperative learning, cooperatively-owned businesses, and collaboration with the local community
Getting a more diverse group of people into tech training and into tech employment
Helping charities and social enterprises develop digital services
For two main reasons:
It aims to set prospective applicants to our full-time course on the path to completing our pre-requisites, through teaching the starter skills and technologies needed to pursue a career in web development.
The short course is also a great introduction to how we learn here at FAC, as we place emphasis on collaborative, peer-led learning, and techniques like pair programming.
The course curriculum:
Toolkit and HTML
CSS
JavaScript
More JavaScript and Codewars
There'll also be a small amount of work to take away after each session and complete at home.
What are HTML, CSS and JavaScript, and why do we need them?
Hypertext is text displayed on an electronic device that can contain references, or hyperlinks, to other information.
Kind of like this.
In fact, you're looking at a bunch of hypertext right now!
HTML is an example of a hypertext language. It stands for: Hypertext Markup Language
Markup language allows us to define different elements on a page in a human-readable way.
Let's see an example...
In order to write HTML, we need to use something called tags. The text you're reading now has been interpreted and rendered by the browser, but it was written in HTML like this:
What if I want some of this text to be bold? We can use a different set of tags like so:
You'll be pleased to know that pretty much all webpages use HTML.
But that's not the end of the story!
Together, HTML, CSS and JavaScript make up the three core technologies of the web.
Some people find it helpful to think of their relationship to one another as nouns, adjectives and verbs.
Our HTML dictates what content will be on the page. It provides our basic structure.
Our CSS describes how that content should look, how it should be laid out, and what styles it should have.
And our JavaScript brings that content to life - it allows the user to interact with the content, providing a dynamic experience and determining the behaviour of the page.
Head to www.freeCodeCamp.org
Open up your browser (preferably Google chrome) and head to the Google homepage
Head to www.codepen.io
Using the HTML you've learnt, build a tribute page to someone (or something) that inspires you.
You'll need to try and satisfy the following user stories:
1. I can see the title, or header, of the page
2. I can see an image on the page
3. I can see a paragraph of bold text underneath the image
4. I can click on a link that takes me to another website
If you finish all these user stories, feel free to keep adding more elements to your page. You may want to continue with the challenges on freeCodeCamp for inspiration.


"ARIEL "the lion of God. (1.) One of the chief men sent by Ezra to procure Levites for the sanctuary (Ezra 8:16). (2.) A symbolic name for Jerusalem (Isaiah 29:1, 2, 7) as “victorious under God,” and in Ezekiel 43:15, 16, for the altar (marg., Hebrews ‘ariel) of burnt offerings, the secret of Israel’s lion-like strength.
"ARIEL "the lion of God. (1.) One of the chief men sent by Ezra to procure Levites for the sanctuary (Ezra 8:16).
(2.) A symbolic name for Jerusalem (Isaiah 29:1, 2, 7) as “victorious under God,” and in Ezekiel 43:15, 16, for the altar (marg., Hebrews ‘ariel) of burnt offerings, the secret of Israel’s lion-like strength.


Selected no. of seats: {{seatsToBook}}
Selected seat type: Classic
Selected seat type: Premium
Selected seat type: Recliner
Bill amount to be paid at counter: Rs. {{totalcost}}


Sign in or register
Username
Password
Remember me
Sign in
Register
Toggle navigation
PostQ
Add new friend
Friend's username
Add friend
Call
End


Please choose the Application Name
Please add a Workflow Sequence with valid details!!
Are you sure you want to trigger the pipeline?