xml

Retrieval of Agricultural Production Standards

Description: 
Within the FutureFarm project there has been proposed an machine-readable encoding for the representation of agricultural productions standards. These represenations can be retrieved from rules servers using only HTTP methods. A prototype standards viewer can be tested on http://test.futurefarm.eu.
Deviations: 
This is an implementation only for the selection and retrieval of the machine-readable encodings of relevant production standards in to the client (e.g. FMIS). The process of compliance checking of these rule sets against field operations data is subject of another implementation.

e LABs

Publisher: 
UNCEFACT
Description: 

exhange message for laboratory observations from labs to customer.

The laboratory observation information exchange process is used between the laboratory party who is reporting about the observation and the user of these observation report. This user is usually the party who uses the content of the report, but this user can also be the party who ordered and pays for the observation or has any other connection with the observation report.
The observation report can be used in private and in a public context.

The e-Lab observation report is a message send by the laboratory to the concerned parties who are eligible to receive the results of the observations on the sample, performed by the laboratory . The observations are done on samples water, soil, agricultural commodities, plant products, animal product and or samples taken from live animals. It includes a broad usage ranging from soil, fertilizer, crop products, animal feed, and health status and diagnostic on live animals. These results are used to obtain information of the quality of soil, water, crop products, animal products , or health information about plants or animals.
Only two types of parties are involved, the laboratory and the receiving parties.

Version: 
0.3
Licence: 
free of rights (uncefact licence)

Request for Weather Nowcast (GeoTIFF to XML conversion)

Purpose: 

Disease Pressure Service provides farmer the information on elevated risk of a crop (etc) disease. DPS alarms may be used e.g. to trigger a spraying event. The purpose of the data transfer is to get a weather nowcast for the Disease Pressure Service internal processes. The applicable actors are Advisory Service (Disease Pressure Service), Intermediator (Weather Service) and Field (Parcel).

Concept: 

Weather Service Provider provides weather information (e.g. nowcast) in GeoTIFF format through a Web Coverage Service interface. The actual weather data variable values are stored into metadata of a returned GeoTIFF image. Lightweight ESB like service was implemented between Disease Pressure Service and Weather Service to a) convert the WCS interface into more convenient SOA interface with XML message exchange and to b) eliminate the need to implement image metadata manipulation routines into the Disease Pressure Service server side code.

Used standards/de facto standards: GeoTIFF, WCS, ESB, SOA, XML, REST

More on SOA: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp...

More on REST: https://www.ibm.com/developerworks/webservices/library/ws-restful/

Design: 

Interface provides XML message exchange capability for Disease Pressure Service (DPS) when requesting weather information (nowcast) from Weather Service Provider’s (WSP) Web Coverage Service interface. The sequence begins with getNowcast action request (within a XML message) from the DPS to the lightweight ESB Service (ESBS) implement. The parameters (coverage) include the coordinates of the area the weather info is requested, weather variables needed and the timestamp of the sample. ESBS parses the request into a valid WCS request format (URL) and passes it to the WSP. The WSP response input stream (GeoTIFF image) is read by ESBS and the image metadata is applied utilizing Apache Sanselan class libraries. The valid parameters are extracted from the image metadata, parsed into a XML and passed to the DPS as a response.

The DPS and the ESBS services are implemented using Java EE (http://www.oracle.com/technetwork/java/javaee/overview/index.html). In order to implement GeoTIFF metadata reader you need to download and install e.g. Apache Sanselan (used in this implement) class libraries ( http://commons.apache.org/sanselan/download_sanselan.cgi).

Implementation: 

Disease Pressure Service uses a SOAP client for message exchange with ESB Service (REST implement). The DPS’s weather request (XML message exchange) triggers an event where the Weather Service Provider’s Web Coverage Service interface is called. The method is using basic Java .io and .net class libraries (InputStream is = url.openStream() where the url is an object from a class URL created passing WSC service url to the constructor). The beauty of the Apache Sanselan is that it can read the image metadata directly from the input stream (metaData = Sanselan.getMetadata(is, null)). The Sanselan metadata container type is an array list (ArrayList <Object> al = new ArrayList() , al = metadata.getItems()). The XML messaging between DPS and ESBS is currently using proprietary format but a possibility to use e.g. AgroXML is investigated.

Source: 

agriXchange project team

Model: 

Animal passport reply

Use cases: 
Purpose: 

A cattle registration office or a livestock inspector requests for the animal passport. It can be at national or international level.

Concept: 

The cattle registration office receives the request for animal passport data. It sends a message with the animal passport data to teh cattle registration office which did the request.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

request for animal passport

Use cases: 
Purpose: 

A cattle registration office or a livestock inspector requests for the animal passport. It can be at national or international level.

Concept: 

The cattle registration office or the livestock inspector send a request for animal passport data to the cattle regsitration office where the animal comes when the animal comes from another country.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

Message of validation of the export

Purpose: 

The exporter of the animal informs his cattle registration office about his intent to export the animal. And the holder of the animal informs his cattle registration office about the arrival of the imported animal. The two cattle registration offices exchange messages to validate the animal movment.

Concept: 

The exporting cattle registration office verifies the export and replies with an export notice status message including data.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

Imported animal data

Use cases: 
Purpose: 

The exporter of the animal informs his cattle registration office about his intent to export the animal. And the holder of the animal informs his cattle registration office about the arrival of the imported animal. The two cattle registration offices exchange messages to validate the animal movment.

Concept: 

The cattle registration office checks the arrival information of the animal with the received export notification message. Then it sends an export notication statuts message including animal data to the exporting cattle registration office.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

Intended to export animal data

Use cases: 
Purpose: 

The exporter of the animal informs his cattle registration office about his intent to export the animal. And the holder of the animal informs his cattle registration office about the arrival of the imported animal. The two cattle registration offices exchange messages to validate the animal movment.

Concept: 

The export cattle registration office sends an export notification message, including animal data, to the cattle registration office in the country of import.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use UN/CEFACT standard.

Response for the request of imported animal data

Use cases: 
Purpose: 

The holder of the animal notifies the cattle registration office about the arrival of the imported animal. The cattle registration office send a request for the animal data to the cattle registration office of the country of export.

Concept: 

The exporting cattle registration office receives the message of animal data request. It checks the animal data about the export and replies to the importing cattle registration office by sending import notification status message and animal information.

Design: 

Harmonization of hte relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

Request for imported animal data

Use cases: 
Purpose: 

The holder of the animal notifies the cattle registration office about the arrival of the imported animal. The cattle registration office send a request for the animal data to the cattle registration office of the country of export.

Concept: 

The cattle registration office sends an import notification message with a request for the animal data to the cattle registration office of the country of export.

Design: 

Harmonization of the relevant code lists is necessary. It's also important to take care of the animal identification number.

Implementation: 

It's possible to use the UN/CEFACT standard.

Syndicate content