<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Automatic plugin workflow construction</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Luka</forename><surname>Bradesko</surname></persName>
						</author>
						<author>
							<persName><forename type="first">Cyc</forename><surname>Europe</surname></persName>
						</author>
						<title level="a" type="main">Automatic plugin workflow construction</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">EEAC183935C0C7D47DD86140167302AA</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T04:50+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>The thesis will be based on the LarKC platform, particularly on the part which is responsible for smartly connecting and using the plug-ins, to form useful workflows. The result of the thesis will be a Decider plug-in, which is able to construct the most effective and useful workflow, out of the available plug-ins and based on the input SPARQL query. This is done by using the semantic annotations of the plug-ins, propagating the knowledge in the Platform's plug-in registry and using some sort of reasoning software to</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>decide the ways in which plug-ins can be connected. This can be at the end extended to the point that decider plug-in is able to monitor and switch between the plug-ins on the fly, improving the overall performance.</p><p>Data about the plug-ins will be available to the software via the ontology with which the plug-in is annotated. Currently the vocabulary of the ontology is very poor and also the connections between the constants are rare, which makes it obvious that it needs to be improved, especially with the important parameters which are most relevant for making decisions which plug-in to use for what job and provide support for them inside the ontology. These parameters are mostly QoS parameters, together with predicates describing the job the plug-in can do.</p><p>The communication between the plug-ins is handled by the platform, but currently data passing consists of just plain triples. There is no way for the computer to tell, what is that it is passing around. In order for the Decider to be able to decide more efficiently which plugin to use, there should be some way of annotating also the data, not only plug-ins. This implies creating additional ontology which will be used as base when annotating the data. Also the data passing possibilities which are currently limited to only linear workflows have to be updated to support splitting and joining the data flows, which will make it possible to parallelize the workflow.</p><p>The Plug-ins are communicating with the platform via the API, which will have to be improved in order to support all the other features we will introduce while developing.</p><p>Among other technical improvements, also the API connecting decider and internal platform reasoner (Cyc based) should be defined.</p><p>While the LarKC platform already has quite a large number of plug-in available from the community it is still in its early stage of the development and the plug-ins are not always properly annotated. Because of this, we need to generate the test data, based on real plug-ins and also on possible future plug-ins, to show the usability and provide the evaluation for the efficiency and usability of the Decider.</p></div>		</body>
		<back>
			<div type="references">

				<listBibl/>
			</div>
		</back>
	</text>
</TEI>
