Luddigt märkningsspråk

(FML) Fuzzy Markup Language
Utvecklad av Giovanni Acampora
Typ av format Markup language
Förlängt från XML
Standard IEEE 1855-2016

Fuzzy Markup Language ( FML ) är ett märkningsspråk för specifikt ändamål baserat på XML , som används för att beskriva strukturen och beteendet hos ett fuzzy system oberoende av hårdvaruarkitekturen som är ägnad att vara värd för och köra det.

Översikt

FML designades och utvecklades av Giovanni Acampora under sin doktorsexamen. kurs i datavetenskap, vid universitetet i Salerno, Italien, 2004. Den ursprungliga idén inspirerade Giovanni Acampora att skapa FML var nödvändigheten av att skapa ett kooperativt fuzzy-baserat ramverk som syftade till att automatiskt kontrollera en livsmiljö som kännetecknas av en uppsjö av heterogena enheter vars interaktioner ägnades åt att maximera den mänskliga komforten under energibesparingsbegränsningar. Detta ramverk representerade ett av de första konkreta exemplen på Ambient Intelligence . Utöver denna banbrytande applikation är den största fördelen med att använda XML för att beskriva ett suddigt system maskinvaru-/mjukvarukompatibilitet. Faktum är att allt som behövs för att läsa en FML-fil är det lämpliga schemat för den filen och en FML-parser. Denna uppmärkningsmetod gör det mycket lättare att utbyta fuzzy system mellan mjukvara: till exempel kan en maskininlärningsapplikation extrahera fuzzy regler som sedan kan läsas direkt in i en fuzzy inferensmotor eller laddas upp till en fuzzy controller. Med teknologier som XSLT är det också möjligt att kompilera FML till det programmeringsspråk du väljer, redo att bäddas in i vilken applikation du vill. Som sagt av Mike Watts på hans populära Computational Intelligence-blogg:

"Även om Acamporas motivation för att utveckla FML verkar vara att utveckla inbyggda fuzzy kontroller för applikationer för omgivande intelligens, kan FML vara en riktig välsignelse för utvecklare av fuzzy regelextraktionsalgoritmer: av min egen erfarenhet under min doktorsexamen vet jag att jag måste designa en fil formatera och implementera lämpliga parsers för regelextrahering och fuzzy inferensmotorer kan vara en verklig smärta, det tar lika mycket tid som att implementera själva regelextraktionsalgoritmen. Jag skulle mycket hellre ha använt något som FML för mitt arbete."

En fullständig översikt över FML och relaterade applikationer finns i boken med titeln On the power of Fuzzy Markup Language redigerad av Giovanni Acampora, Chang-Shing Lee, Vincenzo Loia och Mei-Hui Wang, och publicerad av Springer i serien Studies on Fuzziness och Soft Computing .

Syntax, grammatik och hårdvarusyntes

FML tillåter att fuzzy system kodas genom en samling korrelerade semantiska taggar som kan modellera de olika komponenterna i en klassisk fuzzy controller såsom kunskapsbas, regelbas, fuzzy variabler och fuzzy regler. Därför representerar FML-taggarna som används för att bygga en fuzzy controller uppsättningen lexem som används för att skapa fuzzy uttryck. För att designa ett välformat XML-baserat språk, definieras en FML kontextfri grammatik med hjälp av ett XML-schema som definierar namn, typ och attribut som kännetecknas av varje XML-element. Men eftersom ett FML-program endast representerar en statisk vy av en fuzzy logic controller, tillhandahålls den så kallade eXtensible Stylesheet Language Translator (XSLT) för att ändra denna statiska vy till en beräkningsbar version. Faktum är att XSLT-moduler kan konvertera den FML-baserade fuzzy-kontrollern till ett allmänt datorspråk med hjälp av en XSL-fil som innehåller översättningsbeskrivningen. På denna nivå är kontrollen körbar för hårdvaran. Kort sagt, FML består i huvudsak av tre lager:

  • XML för att skapa ett nytt uppmärkningsspråk för fuzzy logic control;
  • ett XML-schema för att definiera de juridiska byggstenarna;
  • eXtensible Stylesheet Language Transformations (XSLT) för att konvertera en suddig kontrollbeskrivning till ett specifikt programmeringsspråk.

FML-syntax

FML-syntax är sammansatt av XML-taggar och attribut som beskriver de olika komponenterna i en fuzzy logic controller som listas nedan:

  • otydlig kunskapsbas;
  • luddig regelbas;
  • slutledningsmotor
  • subsystem för fuzzifiering;
  • avlusningsdelsystem.

I detalj är öppningstaggen för varje FML-program <FuzzyController> som representerar den luddiga styrenheten under modellering. Den här taggen har två attribut: namn och ip . Det första attributet tillåter att specificera namnet på fuzzy controller och ip används för att definiera platsen för kontrollenheten i ett datornätverk. Den fuzzy kunskapsbasen definieras med hjälp av taggen <KnowledgeBase> som upprätthåller uppsättningen av fuzzy koncept som används för att modellera den fuzzy regelbasen. För att definiera det luddiga konceptrelaterade kontrollerade systemet <KnowledgeBase> -taggen en uppsättning kapslade taggar:

  • <FuzzyVariable> definierar fuzzy-konceptet;
  • <FuzzyTerm> definierar en språklig term som beskriver det luddiga konceptet;
  • en uppsättning taggar som definierar en form av fuzzy set är relaterade till fuzzy termer.

Attributen för taggen <FuzzyVariable> är: name , scale , domainLeft , domainRight , typ och, för endast en utdata, ackumulation , defuzzifier och defaultValue . Namnattributet definierar namnet på fuzzy koncept, till exempel temperatur ; skala används för att definiera skalan som används för att mäta det luddiga konceptet, till exempel Celsiusgrad ; domainLeft och domainRight används för att modellera diskursens universum av fuzzy koncept, det vill säga uppsättningen av verkliga värden relaterade till fuzzy koncept, till exempel [0°,40°] i fallet med Celsius grad; positionen för suddigt begrepp i regel (efterföljande del eller föregående del) definieras av typattribut (input/output); ackumulationsattribut definierar metoden för ackumulering som är en metod som tillåter kombinationen av resultat av en variabel för varje regel i ett slutresultat; defuzzifier attribut definierar metoden som används för att utföra omvandlingen från en fuzzy uppsättning, erhållen efter aggregeringsprocess, till ett numeriskt värde för att ge det i utdata till systemet; defaultValue- attribut definierar ett verkligt värde som endast används när ingen regel har aktiverats för den aktuella variabeln. När det gäller taggen <FuzzyTerm> använder den två attribut: namn som används för att identifiera det språkliga värdet som associeras med fuzzy koncept och komplement , ett booleskt attribut som definierar, om det är sant, är det nödvändigt att överväga komplementet till medlemskapsfunktionen definierad av given parametrar. Fuzzy shape-taggar, som används för att komplettera definitionen av fuzzy-konceptet, är:

  • <TRIANGULARSHAPE>
  • <RIGHTLINEARSHAPE>
  • <LEFTLINEARSHAPE>
  • <PISHAPE>
  • <GAUSSIANSHAPE>
  • <RIGHTGAUSSIANSHAPE>
  • <LEFTGAUSSIANSHAPE>
  • <TRAPEZOIDSHAPE>
  • <SSHAPE>
  • <ZSHAPE>
  • <RECTANGULARSHAPE>
  • <SINGLETONSHAPE>

Varje shaping-tagg använder en uppsättning attribut som definierar den verkliga konturen av motsvarande fuzzy set. Antalet av dessa attribut beror på den valda fuzzy set-formen.

För att göra ett exempel, överväg Tipper Inference System som beskrivs i Mathworks Matlab Fuzzy Logic Toolbox Tutorial. Detta Mamdani-system används för att reglera tippningen i till exempel en restaurang. Den har två variabler i input ( mat och service ) och en i output ( tips ). FML-kod för modellering av en del av kunskapsbasen för detta luddiga system som innehåller variablerna mat och tips visas nedan.

 

  
    
                     
              
                  
            
              
                   
            
                      
 	                 
              
                   
            
              
                   
            
              
                   
            
        
     <?xml version="1.0" encoding="UTF-8"?>  <FuzzyController  name=  "newSystem"  ip=  "127.0.0.1"  >  <KnowledgeBase>  <FuzzyVariable  name=  "food"  domainleft=  "0.0"  domainright=  " 10.0"  scale=  ""  type=  "input"  >  <FuzzyTerm  name=  "delicious"  complement=  "false"  >  <LeftLinearShape  Param1=  "5.5"  Param2=  "10.0"  />  </FuzzyTerm>  <FuzzyTerm  name=  "härsken"  complement=  "false"  >  <TriangularShape  Param1=  "0.0"  Param2=  "2.0"  Param3=  "5.5"  />  </FuzzyTerm>  </FuzzyVariable>  ...........  <FuzzyVariable  name=  "tips "  domainleft=  "0.0"  domainright=  "20.0"  scale=  "Euro"  defaultValue=  "0.0"  defuzzifier=  "COG"  accumulation=  "MAX"  type=  "output"  >  <FuzzyTerm  name=  "genomsnittligt"  komplement=  "falskt"  >  <TriangularShape  Param1=  "5.0"  Param2=  "10.0"  Param3=  "15.0"  />  </FuzzyTerm>  <FuzzyTerm  name=  "billig"  komplement=  "falskt"  >  <TriangularShape  Param1=  "0.0"  Param2=  "5.0"  Param  "10.0"  />  </FuzzyTerm>  <FuzzyTerm  name=  "generous"  complement=  "false"  >  <TriangularShape  Param1=  "10.0"  Param2=  "15.0"  Param3=  "20.0"  />  </FuzzyTerm>  </FuzzyVariable>  < /KnowledgeBase>  ............  </FuzzyController> 

En speciell tagg som dessutom kan användas för att definiera en luddig form är <UserShape> . Denna tagg används för att anpassa suddig form (anpassad form). Den anpassade formmodelleringen utförs via en uppsättning <Point> -taggar som listar de yttersta punkterna i det geometriska området som definierar den anpassade otydliga formen. Uppenbarligen är attributen som används i <Point> -taggen x- och y-koordinater. När det gäller regelbaskomponenten tillåter FML att definiera en uppsättning regelbaser, var och en av dem beskriver olika systembeteende. Roten till varje regelbas modelleras av <RuleBase> -taggen som definierar en otydlig regeluppsättning. Taggen <RuleBase> använder fem attribut: name , type , activationMethod , andMethod och orMethod . Uppenbarligen name regelbasen unikt. Typeattributet till regelbasen i fråga. Attributet activationMethod definierar metoden som används för att implikera processen; attributen andMethod och orMethod definierar respektive algoritmen och och eller som ska användas som standard. För att definiera den enskilda regeln används taggen <Rule> . Attributen som används av taggen <Rule> är: name , connector , operator och weight . Namnattributet tillåter att identifiera regeln ; connector används för att definiera den logiska operatorn som används för att koppla ihop de olika satserna i föregående del (och/eller); operatören definierar algoritmen som ska användas för den valda anslutningen; vikt definierar vikten av regel under inferensmotorsteg. Definitionen av antecedent och konsekvent regeldel erhålls genom att använda <Antecedent> och <Consequent> taggar. Taggen <Clause> används för att modellera de fuzzy satserna i föregående och konsekventa del. Den här taggen använder attributmodifieraren för att beskriva en modifiering av termen som används i satsen. De möjliga värdena för detta attribut är: ovan , under , extremt , intensifiera , mer eller mindre , norm , inte , plus , något , något , väldigt , ingen . För att slutföra definitionen av fuzzy-satsen måste de kapslade <Variable>- och <Term> -taggarna användas. En sekvens av <Rule> -taggar realiserar en otydlig regelbas.

Som exempel, betrakta en Mamdani-regel som består av (maten är härsken) OR (servicen är mycket dålig) som föregångare och dricks är billigt som följd. Den föregående delen består av två satser: (maten är härsken) och (servicen är dålig) . Den första antecedentsatsen använder mat som variabel och härsken som fuzzy term, medan den andra antecedentsatsen använder service som en variabel, dålig som fuzzy term och mycket som modifierare; den konsekventa klausulen använder tip som en luddig variabel och billig som en fuzzy term. Den fullständiga regeln är:

OM (maten är härsken) ELLER (servicen är mycket dålig) (tipset är billigt) .

Låt oss se hur FML definierar en regelbas med denna regel.

 
     
          
           
                
                    
                    
                
                 
                    
                    
                
            
            
                
                    
                    
                
            
       <RuleBase  name=  "Rulebase1"  activationMethod=  "MIN"  andMethod=  "MIN"  orMethod=  "MAX"  type=  "mamdani"  >  <  Regelnamn=  "reg1"  connector=  "eller"  operator=  "MAX"  vikt=  "1.0"  >  <Antecedent>  <Clause>  <Variable>  mat  </Variable>  <Term>  härsken  </Term>  </Clause>  <Clause  modifier=  "mycket"  >  <Variable>  service  </Variable>  <Term>  dålig  </Term >  </Clause>  </Antecedent>  <Consequent>  <Clause>  <Variable>  tips  </Variable>  <Term>  billigt  </Term>  </Clause>  </Consequent>  </Rule>  ....... .....  </RuleBase> 

Låt oss nu se ett Takagi-Sugeno-Kang-system som reglerar samma fråga. Den viktigaste skillnaden med Mamdani-systemet är definitionen av en annan utdatavariabel spets . Taggen <TSKVariable> används för att definiera en utdatavariabel som kan användas i en regel i ett Tsk-system. Den här taggen har samma attribut som en Mamdani-utdatavariabel förutom domainleft och domainright- attributen eftersom en variabel av detta slag (kallad tsk-variabel) inte har ett diskursuniversum. Den kapslade <TSKTerm> -taggen representerar en linjär funktion och är därför helt annorlunda än <FuzzyTerm> . Taggen <TSKValue> används för att definiera koefficienterna för linjär funktion. Följande kritan av FML-kod visar definitionen av utdatavariabel spets i ett Tsk-system.

 

  
         
              
                
            
              
                
                
                
            
              
                
                
                
            
        
     <?xml version="1.0" encoding="UTF-8"?>  <FuzzyController  name=  "newSystem"  ip=  "127.0.0.1"  >  <KnowledgeBase>  .......  <TSKVvariabelt  namn=  "tips"  skala =  "null"  accumulation=  "MAX"  defuzzifier=  "WA"  type=  "output"  >  <TSKTerm  name=  "genomsnittlig"  order=  "0"  >  <TSKValue>  1.6  </TSKValue>  </TSKTerm>  <TSKTerm  name=  " cheap"  order=  "1"  >  <TSKValue>  1.9  </TSKValue>  <TSKValue>  5.6  </TSKValue>  <TSKValue>  6.0  </TSKValue>  </TSKTerm>  <TSKTerm  name=  "generous"  order=  "1"  >  < TSKValue>  0.6  </TSKValue>  <TSKValue>  1.3  </TSKValue>  <TSKValue>  1.0  </TSKValue>  </TSKTerm>  </TSKVariable>  <KnowledgeBase>  ..........  </FuzzyController> 

FML-definitionen av regelbaskomponent i ett Tsk-system förändras inte mycket. Det enda som skiljer sig är att <Clause> -taggen inte har modifier-attributet.

Som exempel, betrakta en tsk-regel som består av (maten är härsken) OR (servicen är mycket dålig) som föregångare och, som en följd av detta, tips=1,9+5,6*mat+6,0*service som kan skrivas som tips är billig i en implicit sätt. Så regeln kan skrivas på detta sätt:

OM (maten är härsken) ELLER (servicen är mycket dålig) (tipset är billigt) .

Låt oss se hur FML definierar en regelbas med denna regel.

 
     
    
            
                
                    
                    
                
                
                    
                    
                
            
            
                
                    
                    
                
            
         <RuleBase  name=  "Rulebase1"  activationMethod=  "MIN"  andMethod=  "MIN"  orMethod=  "MAX"  type=  "tsk"  >  <  Regelnamn=  "reg1"  connector=  "eller"  operator=  "MAX"  vikt=  "1.0"  >  <Antecedent>  <Clause>  <Variable>  mat  </Variable>  <Term>  härsken  </Term>  </Clause>  <Clause>  <Variable>  service  </Variable>  <Term>  dålig  </Term>  </Clause>  </Antecedent>  <Consequent>  <Clause>  <Variable>  tips  </Variable>  <Term>  billigt  </Term>  </Clause>  </Consequent>  </Rule>  ............  </RuleBase> 

FML grammatik

FML-taggarna som används för att bygga en fuzzy controller representerar uppsättningen lexem som används för att skapa fuzzy uttryck. För att förverkliga ett välformaterat XML-baserat språk krävs dock en FML-kontextfri grammatik och beskrivs i det följande. Den FML kontextfria grammatiken är modellerad av XML-fil i form av ett XML Schema Document (XSD) som uttrycker den uppsättning regler som ett dokument måste uppfylla för att anses vara ett giltigt FML- dokument . Baserat på den tidigare definitionen ges en del av FML XSD avseende kunskapsbasdefinitionen nedan.

 

  
		
		     
			     
			     
			 	
		
	
	 
		
			   
		
		   
		  
			
				 
					 
				
			
		
		  
			
				 
					 
				
			
		
		   
		    
		   
		   
		   
			
				 
					 
				
			
		
	
	 
		
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
		
         
		   
		   
	
	 
		   
		   
		   
	
	 
		   
		   
		   
		   
	
	 
		
			    
		
	
	 
		   
		   
	
	 
		   
		  
			
				 
					 
				
			
		
		  
			
				 
					 
				
			
		
		  
			
				 
					 
				
			
		
		  
			
					 
						 
					
			
		
	
	 
		
     		 
				
					    
				
			
		
	
	 
		
			   
		
	
	 
		
			   
		
	
	 
		
			 
				
					 
						 
						 
					
				
			
			  
			
		
		  
			
				 
					     
                                            
				
			
		
	 <?xml version="1.0" encoding="UTF-8"?>  <xs:schema  xmlns:xs=  "http://www.w3.org/2001/XMLSchema"  >  ........  < xs:complexType  name=  "KnowledgeBaseType"  >  <xs:sequence>  <xs:choice  minOccurs=  "0"  maxOccurs=  "unbounded"  >  <xs:element  name=  "FuzzyVariable"  type=  "FuzzyVariableType"  />  <xs:  elementnamn =  "TSKVariable"  type=  "TSKVariableType"  />  </xs:choice>  </xs:sequence>  </xs:complexType>  <xs:complexType  name=  "FuzzyVariableType"  >  <xs:sequence>  <xs:elementnamn  =  "FuzzyTerm"  type=  "FuzzyTermType"  maxOccurs=  "unbounded"  />  </xs:sequence>  <xs:attribute  name=  "name"  type=  "xs:string"  use=  "required"  />  <xs:attribute  name=  "defuzzifier"  default=  "COG"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value=  "MM|COG|COA|WA|Custom"  />  </xs:restriction >  </xs:simpleType>  </xs:attribute>  <xs:attribute  name=  "ackumulation"  default=  "MAX"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value =  "MAX|SUMMA"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  <xs:attribute  name=  "scale"  type=  "xs:string"  />  <xs:attribute  name=  "domainleft"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "domainright"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "defaultValue"  typ =  "xs:float"  default=  "0"  />  <xs:attributnamn  =  "type"  default=  "input"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value =  "input|output"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  </xs:complexType>  <xs:complexType  name=  "FuzzyTermType"  >  <xs:choice>  <xs: element  name=  "RightLinearShape"  type=  "TwoParamType"  />  <xs:element  name=  "LeftLinearShape"  type=  "TwoParamType"  />  <xs:element  name=  "PIShape"  type=  "TwoParamType"  />  <xs:  elementnamn =  "TriangularShape"  type=  "ThreeParamType"  />  <xs:elementnamn  =  "GaussianShape"  type=  "TwoParamType"  />  <xs:  elementnamn=  "RightGaussianShape"  type=  "TwoParamType"  />  <xs:elementnamn  =  " LeftGaussianShape"  type=  "TwoParamType"  />  <xs:element  name=  "TrapezoidShape"  type=  "FourParamType"  />  <xs:element  name=  "SingletonShape"  type=  "OneParamType"  />  <xs:elementnamn  =  "RectangularShape"  type=  "TwoParamType"  />  <xs:element  name=  "ZShape"  type=  "TwoParamType"  />  <xs:element  name=  "SShape"  type=  "TwoParamType"  />  <xs:element  name=  "UserShape"  type=  "UserShapeType"  />  </xs:choice>  <xs:complexType  name=  "TwoParamType"  >  <xs:attribute  name=  "Param1"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "Param2"  type=  "xs:float"  use=  "required"  />  </xs:complexType>  <xs:complexType  name=  "ThreeParamType"  >  <xs:attribute  name=  "Param1"  type=  "xs:float"  använd =  "required"  />  <xs:attribute  name=  "Param2"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "Param3"  type=  "xs:float"  use=  "required"  />  </xs:complexType>  <xs:complexType  name=  "FourParamType"  >  <xs:attribute  name=  "Param1"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "Param2"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "Param3"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "Param4"  type=  "xs :float"  use=  "required"  />  </xs:complexType>  <xs:complexType  name=  "UserShapeType"  >  <xs:sequence>  <xs:element  name=  "Point"  type=  "PointType"  minOccurs=  "2"  maxOccurs=  "unbounded"  />  </xs:sequence>  </xs:complexType>  <xs:complexType  name=  "PointType"  >  <xs:attribute  name=  "x"  type=  "xs:float"  use=  "required"  />  <xs:attribute  name=  "y"  type=  "xs:float"  use=  "required"  />  </xs:complexType>  <xs:complexType  name=  "RuleBaseType"  >  <xs:attribute  name=  "name"  type=  "xs:string"  use=  "required"  />  <xs:attribute  name=  "activationMethod"  default=  "MIN"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value=  "PROD|MIN"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  <xs:attribute  name=  "andMethod"  default=  "MIN"  >  <xs:simpleType>  <xs: restriction  base=  "xs:string"  >  <xs:pattern  value=  "PROD|MIN"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  <xs:attribute  name=  "orMethod"  standard =  "MAX"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value=  "PROBOR|MAX"  />  </xs:restriction>  </xs:simpleType>  </xs :attribut>  <xs:attributnamn  =  "typ"  use=  "required"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value=  "TSK|Tsk|tsk|Mamdani| mamdani"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  </xs:complexType>  <xs:complexType  name=  "MamdaniRuleBaseType"  >  <xs:complexContent>  <xs:extension  base=  " RuleBaseType"  >  <xs:sequence>  <xs:element  name=  "Rule"  type=  "MamdaniFuzzyRuleType"  minOccurs=  "0"  maxOccurs=  "unbounded"  />  </xs:sequence>  </xs:extension>  </xs: complexContent>  </xs:complexType>  <xs:complexType  name=  "AntecedentType"  >  <xs:sequence>  <xs:element  name=  "Clause"  type=  "ClauseType"  maxOccurs=  "unbounded"  />  </xs:sequence>  </xs:complexType>  <xs:complexType  name=  "MamdaniConsequentType"  >  <xs:sequence>  <xs:element  name=  "Clause"  type=  "ClauseType"  maxOccurs=  "unbounded"  />  </xs:sequence> </xs:sequence  > xs:complexType>  <xs:complexType  name=  "ClauseType"  >  <xs:sequence>  <xs:element  name=  "Variable"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:whiteSpace  value=  "kollaps"  />  <xs:pattern  value=  "(([AZ])|([az]))+([AZ]|[az]|[0-9])*" /> <  /  xs :restriction>  </xs:simpleType>  </xs:element>  <xs:element  name=  "Term"  type=  "xs:string"  >  </xs:element>  </xs:sequence>  <xs:attributnamn  =  "modifier"  use=  "valfritt"  >  <xs:simpleType>  <xs:restriction  base=  "xs:string"  >  <xs:pattern  value=  "above|below|extremt|intensify|mer_eller_mindre|norm|inte|plus|något |somewhat|very"  />  </xs:restriction>  </xs:simpleType>  </xs:attribute>  </xs:complexType>  ..........  </xs:schema> 

FML-syntes

Eftersom ett FML-program endast realiserar en statisk vy av ett fuzzy system, tillhandahålls den så kallade eXtensible Stylesheet Language Translator (XSLT) för att ändra denna statiska vy till en beräkningsbar version. I synnerhet används XSLT-tekniken för att omvandla en suddig kontrollbeskrivning till ett allmänt datorspråk som ska beräknas på flera hårdvaruplattformar. För närvarande har ett XSLT-konverterande FML-program i körbar Java-kod implementerats. På detta sätt, tack vare transparensmöjligheterna som tillhandahålls av virtuella Java-maskiner, är det möjligt att erhålla en suddig styrenhet modellerad på hög nivå med hjälp av FML och körbar på en uppsjö av hårdvaruarkitekturer genom Java-teknologier. Men XSLT kan också användas för att konvertera FML-program till äldre språk som är relaterade till en viss hårdvara eller i andra allmänna språk.

Vidare läsning

  •   Lee, Chang-Shing; et al. (december 2010). "Dietbedömning baserad på fuzzy ontologi av typ 2 och fuzzy markup language". International Journal of Intelligent Systems . 25 (12): 1187–1216. doi : 10.1002/int.20449 . S2CID 13570946 . (prenumeration krävs)
  •   Acampora, G.; Loia, V. (2005). "Fuzzy kontroll interoperabilitet och skalbarhet för adaptiv domotic ramverk". IEEE-transaktioner på industriell informatik . 1 (2): 97–111. doi : 10.1109/TII.2005.844431 . S2CID 8008285 .
  • Acampora, G.; Loia, V. (2008). "Ett förslag om ubiquitous fuzzy computing för Ambient Intelligence". Informationsvetenskap . 178 (3): 631–646. doi : 10.1016/j.ins.2007.08.023 .
  •   Acampora, G.; Wang, M.-H.; Lee, C.-S.; Hsieh, K.-L.; Hsu, C.-Y.; Chang, C.-C. (2010). "Ontologibaserade multiagenter för intelligenta vårdtillämpningar". Journal of Ambient Intelligence and Humanized Computing . 1 (2): 111–131. doi : 10.1007/s12652-010-0011-5 . S2CID 35304577 .
  •   Acampora, G.; Loia, V.; Gaeta, M.; Vasilakos, AV (2010). "Interoperabla och adaptiva fuzzy-tjänster för applikationer för omgivande intelligens". ACM-transaktioner på autonoma och adaptiva system . 5 (2): 1–26. doi : 10.1145/1740600.1740604 . S2CID 14234229 .