- Nemyslim si ze dava smysl opakovat
FROM
clause, t.j. mit viceFROM
klauzuli. My ji pouzivame k tomu, abychom vybrali schema ze ktereho dotazovat.
WHERE
neni v MMQL optional, vzdy tam musi byt. Prijde mi ze obrazek naznacuje, ze by to tam byt nemuselo (pokud mu spravne rozumim).
BIND
momentalne nepodporujeme, teoreticky by to slo, ale otevreli bychom se tomu, ze se uvnitr toho objevi nejaka velka agregace napric vice databazemi, a bylo by podle me slozite definovat, jak se to ma prekladat. Kazdopadne na urovni jazyka tomu nic nebrani, je to spis implementacni slozitost.- V obrazku chybi
VALUES
- Nepodporujeme
GRAPH
, protoze to nedava v kontextu MMQL smysl
- Nepodporujeme
NOT EXISTS
ve verzi MMQL kterou jsem navrhoval v diplomce - dle me uvahy jdeNOT EXISTS
ekvivalentne vyjadrit pomoci podporovanehoMINUS
v kombinaci s filtrovanim - Zdroj pro vztah mezi
NOT EXISTS
aMINUS
v puvodnim SPARQL: https://www.w3.org/TR/sparql11-query/#neg-notexists-minus
DISTINCT
podporujeme,REDUCED
nepodporujeme protoze to je vlastne takovy "best effort reduced", t.j. negarantuje redukci duplikatu, ale pouze odstrani ty jednoduche na odstraneni. Nikdy jsem nikde nevidel ze by to nekdo k necemu pouzival, takze mi nedavalo smysl to do MMQL davat kdyz nemame use case.
ORDER BY
podporujeme v SQL-like syntaxi, t.j.ORDER BY ?var ASC|DESC
. Prijde mi to jako nejprirozenejsi poradi.