gipoisson a écrit 97 commentaires

[…] il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages.

Vu tout le fil, le point que je relève est un détail, allons-y tout de même si ça ne te pose pas de souci. Alors, si Reader / Writer dans ton propos évoque la page liée — ici, mon illettrisme en Go devrait être totalement visible — je dirais qu'en Haskell ce genre d'abstractions est fourni dans les paquets venant avec GHC, le compilateur de facto du langage. J'ai nommé MonadIO, dans le paquet transformers donc. Cela vient avec l'avantage que les effets abstraits ne se limitent pas à des entrées/sorties, mais sont potentiellement composables avec toute autre monade. Bref, de base GHC n'est pas si dépourvu que ça.

Tout à fait, mea culpa maxima.
Quelqu'un qui est plus familier avec les sources d'OpenBSD est plus à même de caractériser ce que « noyau » veut dire pour cet OS.

Comme je viens de l'écrire plus haut, la page web de Coverity ne reflète pas nécessairement l'étendu des scans. Autrement, on ne lirait pas des phrases comme “Fixed dozens of Coverity issues” dans les notes de sorties s'il n'y avait que 16 KLOC scannées.

Y a pas des chiffres plus récents, pour NetBSD ?

Ce qui est publié sur le site de Coverity ne reflète pas l'état de collaboration entre un projet scanné et le scanneur. J'ai lu je ne me souviens où qu'après scan, Coverity envoie confidentiellement les résultats aux personnes concernées (responsible disclosure au cas où il y aurait des failles critiques). Celles-ci peuvent alors en faire ce qu'elles veulent : corriger silencieusement les vrais positifs, s'asseoir là-dessus, les rendre publics, les faire passer par un script qui en affichera le résumé sur le site web de Coverity … Certains projets ont des instances privées de Coverity (pour rappel, ce n'est plus un projet de l'université de Stanford mais un logiciel propriétaire) où on fait passer n'importe quel code, sans attendre l'avis des responsables upstream : c'est ainsi que j'ai découvert l'existence même de Coverity en lisant sur une liste de diffusion un message d'un employé de Redhat qui rapportait des failles pointées par un scan de Coverity, sans que les responsables du projet scanné aient eu une connaissance préalable que leur code se faisait analyser. Cas d'espèce : NetBSD est toujours scanné comme en témoigne le WiKi du projet et d'autres pages web.

Il n'y a donc plus rien de commun entre eux, à part le nom ?

Même pour des profanes des arcanes des BSD (dont je suis car utilisant du GNU), il est de notoriété publique que les trois OS se sont longtemps éloignés les uns des autres du point de vue partage de code. Au-delà de cette généralité, il y a de la littérature qui documente les choses plus finement, par exemple dans l'article "A Case Study of Cross-System Porting in Forked Projects" de Baishakhi Rᴀʏ et Miryung Kɪᴍ ; version publique ici. Deux des questions auxquelles l'article répond :

• « À quel point les modifications sont-elles portées de projet en projet ? » La figure 2  est une matrice des pourcentages de ports ayant comme sources la première ligne (en-tête) et comme destination la première colonne (en-tête). On y observe qu'en cumulé, la moyenne la plus élevée est de 15 % et on ne peut donc pas dire que les sources sont synchronisées entre les trois BSD.
• « Quelles sont les sous-arborescences des sources qui reçoivent le plus de ports d'une BSD à une autre ? » La figure 7  montre qu'encore une fois, il n'y a pas de partage avancé du code.

Bref, les trois sont des systèmes d'exploitation différents. Il n'est pas étonnant que quand on les analyse statiquement, on tombe sur des résultats différents.

L'intuition du commentaire parent n'est pas infondée si l'on en croit Coverty. Le projet définit une « densité en défauts », soit le taux de défauts par 1 KLOC. Taux actuels :

1. le noyau d'OpenBSD, code du 26/01/2017 : 0,06 ;
2. le noyau de NetBSD, code du 02/03/2009 : 0,32 ;
3. Linux, code du 24/07/2017 : 0,47 ;
4. le noyau de FreeBSD, code du 26/07/2017 : 0,78.

Disclaimer : je suis une tanche dans la discipline de Sécurité Informatique mais il ne me semble pas aberrant de prendre au sérieux le caractère scientifique d'un projet qui s'est construit ce genre de notoriété.

Je laisse le soin aux exégètes du plafond de verre l'interprétation de pourquoi elles ont disparu et pas ils.

Cette phrase semble exprimer du sarcasme mais ces problèmes d'opportunités différentes sont loin d'êtres anodins. Par exemple, un livre (ISBN : 9782702126561) écrit avant que le féminisme ne soit un sujet aussi fréquemment traité que de nos jours donne la parole aux personnes directement concernées et une des femmes de la photo ici-dessus y donne son témoignage :

“[…] Agnès Touraine [:] « Il y a de ces situations où l'on a l'impression qu'il est dévalorisant pour certains de parler à une femme.» Comme il peut l'être de l'écouter. Même si elle est élue, occupe des fonctions importantes dans son parti et a des choses à dire. «Au bureau exécutif du PS, on n'écoute pas une femme comme on écoute un homme», dit Geneviève Domenach-Chich, militante politique et conseiller spécial à l'Unesco. Ou plutôt, on l'écoute une minute, on la regarde un peu plus longtemps, « si elle est bien sapée », après quoi on ne l'écoute ni ne la regarde: on parle avec son voisin, on rédige son courrier, on parcourt un dossier ou son journal. Quand une femme intervient au Conseil national, où siègent deux cents membres, l'indifférence est encore plus marquée. Une fille monte à la tribune. Elle est belle. Elle parle. Les gens la regardent. Les mecs surtout. ''Ah, qui c'est, cette nénette? " Elle peut faire des remarques pertinentes, des suggestions astucieuses - en vain: très vite, la salle bavarde, après tout ce n'est qu'une femme, on ne l'écoute pas comme on écouterait Poperen.»”

D'autres extraits se trouvent ici.

le principal intérêt […] c'est d'avoir une liste épurée, simple à lire, et qui donne une bonne vue d'ensemble, sans rien de superflus.

Les deux sites proposent un accès programmatique à leurs données, ici et là. On peut construire sur ces infrastructures proposées et faire tout ce qu'on veut, par exemple changer la présentation des données. Mais bon, ton approche semble répondre à ta problématique, so cheers !

P.S. “Executive order” se traduit habituellement en « décret ».

Question sources primaires, les journaux officiels sont en haut de l'affiche. En ce moment, la plupart des liens que tu donnes sur l'UE renvoient sur le site de son journal officiel. Peut-être qu'il faudrait faire de même pour les USA.

Sur le fond, est-ce une initiative de créer des miroirs des sources primaires qui sont, pour l'écrasante majorité d'entre elles, dans le domaine public et en ligne ?

J'ignore s'il y a des solutions dans les environnements de bureau (GNOME, KDE, Xfce, …).
Sur la ligne de commande, cp est un des outils utilisés pour copier. Il copie une ou plusieurs sources vers une seule destination.

cp src dest
cp src1 src2 … srcN dest
man cp # le manuel

Accomplir une copie vers plusieurs destinations revient à itérer la copie en changeant de destination à chaque nouvelle itération ; on parle aussi de boucler pour signifier « itérer ». Il existe plusieurs façons d'itérer dans l'interpréteur de la ligne de commandes car il y a de multiples langages de programmation qu'il interprète.

Je te propose un outil qui s'appelle xargs qui construit des arguments à passer aux commandes ultérieures à partir des résultats des précédentes.

## Par défaut, afficher
Bash> printf "%s " "dir1" "dir2" "dir3" | xargs
#dir1 dir2 dir3

## Réorganiser les sorties
Bash> printf "%s " "dir1" "dir2" "dir3" | xargs --max-args=1
#dir1
#dir2
#dir3

## Solution à la question demandée
## Ici, la commande ultérieure est 'cp mon_fichier'
Bash> printf "%s " "../dossier_1" "../dossier_2" "../dossier_3" | xargs --max-args=1 cp mon_fichier

C'est sans doute une question d'habitude.

Tout à fait ! Ce bon vieux Lisp a le trépas difficile, sinon ça m'est également plus facile de lire un code écrit comme on l'a pensé. Mais peut-être que, du point de néophytes dans le langage, sur-usiter d'opérateurs infixés laisse l'impression qu'on jargonne et mes réserves concernaient ce cas de figure : si un certain style est un frein à la propagation de ce paradigme, autant lisser la courbe d'apprentissage en en adoptant un autre. Ça va dans le même sens que ta remarque d'il y a quelques mois :

« […] je ne suis pas partisan du jargon employé fréquemment dans le monde de la programmation fonctionnel […]»

Quant aux règles de précédence, le compilateur interactif GHCi est d'une grande aide. Dès qu'il laisse passer quelque chose, il suffira de lui demander ce qu'il en connaît via les commandes :type <machin>, :info <machin> ou :kind <machin>.

-- N.B. Il y a élision volontaire de certaines sorties pour aller directement à la fixité.

Prelude> :info $
infixr 0 $

Prelude> :info .
infixr 9 .

Prelude> :info <$>
infixl 4 <$>

La précédence est accordée suivant l'ordre décroissant de fixité infix<TRUC> où <TRUC> indique si l'opérateur est liant vers la gauche (l) ou vers la droite (r).

Réserve partagée sur l'abus d'opérateurs ; cela dit, les parenthèses à la Lisp ne demandent pas de moindres efforts non plus. Dans le cas présent, on peut éliminer l'alias du functor et expliciter fmap, voire éviter le lifting et utiliser tout simplement map qui est devenu un idiome répandu dans moult langages. Bref :

putStrLn $ show $ map (launchMissile'' . F) [10, 0, 7, negate 11, 17]

À part ça, oui la complexité est refoulée dans le module et à mon sens, c'est le chemin à suivre. Consommer facilement les APIs de modules bien conçus devrait se faire sans modération et sans se prendre la tête avec leurs cuisines internes. Lorsqu'on voudra être à la baguette soi-même, là on pourra alors se farcir les détails. Après tout, de nos jours, même les compilateurs sont des modules et ce ne serait pas raisonnable de s'en passer en prétextant qu'ils nous cachent de la complexité.

P.S. De rien sur l'indication de Ranged-sets, c'est moi qui te remercie pour tes efforts constants de vulgarisation sur Haskell en particulier et, plus généralement, sur le fonctionnel : ces choses-là ne devraient pas avoir le statut confidentiel qu'elles apparaissent avoir actuellement et les efforts comme les tiens contribuent beaucoup à faire évoluer la situation.

Concernant les ranges, que dirais-tu du module Ranged-sets ?

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

-- Module 'Ranged-sets'
import Data.Ranged.Boundaries
import Data.Ranged.Ranges
import Data.Ranged.RangedSet

newtype Fusées = F Integer deriving (Num, Ord, Eq, DiscreteOrdered, Show)

class PrêtePourLaRampe a where
    délivrerFeuVert :: a -> RSet a

instance PrêtePourLaRampe Fusées where
    délivrerFeuVert x = rSetIntersection
        ( makeRangedSet [Range (BoundaryBelow 0) (BoundaryAbove 10)] )
        ( rSingleton x )

launchMissile'' :: Fusées -> Maybe String
launchMissile'' x
    | not $ rSetIsEmpty $ délivrerFeuVert x = Just $ show x
    | otherwise                             = Nothing

main :: IO()
main = do
    putStrLn $ show $ launchMissile'' . F <$> [10, 0, 7, negate 11, 17]
    -- Si on n'a pas de GHC sous la main, les sorties devraient ressembler à ça:
    -- [Just "F 10",Just "F 0",Just "F 7",Nothing,Nothing]

Ça semble ne pas être usine à gaz et ce petit exemple est plutôt lisible en n'ayant que quelques notions dans le langage.

Comme indiqué dans le titre original, il s'agit d'un feuilleton et dans le cas échéant, c'est l'épisode VII. Pour les précédents épisodes, voir ici dans un ordre antéchronologique. Ainsi par exemple, Aristote était-il abordé là-bas.

Le rapprochement que l'auteur cherche à faire est entre le libre et sa théorie de la réciprocité. A priori, il ne devrait pas s'attarder sur le libre, on est après tout en présence d'un essai (en réponse à un autre essai). Pour un examen anthropologique approfondi des cultures libres, voir par exemple Gabriella Cᴏʟᴇᴍᴀɴ, brought to you by DLFP!

Voilà, on est paré pour le week-end et au-delà !

Ma motivation est de développer un outil qui permet le calcul formel (polynômes à plusieurs variables, quotients, algèbre linéaire…) sur des objets proches de la formulation mathématique des problèmes – là où la plupart des systèmes de calcul formel demandent de tout transformer en objets basiques du système …

Ça me rappelle l'article “Towards an Implementation of a Computer Algebra System in a Functional Language” d'Oleg Lobachev et Rita Loogen qui ont fait le même constat que toi : la majorité des systèmes de calcul formel (SCF) sont au moins diglotte, un langage interne servant à implémenter le SCF tandis que des langages externes constituent le moyen par lequel on interagit avec le SCF.

Les auteurs ont alors émis l'idée de mettre en place des SCF unifiant les dialectes internes et externes dans un langage fonctionnel. Leurs travaux étaient plutôt orientés du côté des algorithmes et sont reflétés dans Eden. Du côté des SCF, leur article m'a fait découvrir GiNaC qui réalise l'unification des dialectes en C++. Par exemple, dans le ginsh, ton premier exemple serait rendu comme ici-bas, cette syntaxe C++ reste la même en interne.

ginsh> ppp = expand((x - 1) * (x + 1) * (x^2 + x + 1) * (x^2 + 1) * (x^2 - x + 1) * (x^4 - x^2 + 1));
-1+x^12
ginsh> collect(ppp, x);
-1+x^12

Dans l'article, un autre SCF est mentionné : DoCon qui faisait l'unification en Haskell. Depuis, il a évolué en DoCon-A qui est écrit en Agda. Dans le guide d'utilisation du système, le XVIIe chapitre paraît indiqué pour tes deux derniers exemples. Si tu parles du Haskell, DoCon-A est fait pour s'entendre avec Abach !

Alors, à partir du seul jeu de données accessible publiquement, voir ce PR.

Du moment où les données sont là, les graphiques souhaités sont relativement faciles à faire. Il suffirait par exemple d'accéder à toutes les données brutes sous format CSV/TSV ou équivalent et après, on pourra voir ce qui est faisable en pratique. Pour le moment, la page des stats du site ne présente qu'une seule entrée de données en CSV.

J'avais fais un POC il y a quelque jours à partir de ce CSV, le graphique permettait de résumer certaines tendances passées et j'avais coupé la partie où il tentait une extrapolation des prochaines tendances. C'est pas ce genre de choses dont il s'agit ? Le voici sous plusieurs déclinaisons :

1- à la Calc
2- version dépouillée
3- contraste appuyé
4- minimalisme
5- nuances de gris
6- tout est carré

Cela peut être adapté pour générer d'autres formes. Donc, si le reste des données peut être soutirées des serveurs/SGBD et formatées en « tableaux plats », ce serait un excellent moyen de partir sur du concret.

Un exemple de stats sympa pour OSM avec http://neis-one.org/2014/08/osm-activity-2014/

Sur la page indiquée, rien ne laisse penser que les graphiques ont été faits en JavaScript.
Je dis ça car vu les specs de l'entrée de suivi, je me sens capable de bricoler un truc mais pas en JavaScript. Serait-ce la volonté de ne pas installer quoi que ce soit sur les serveurs qui conduit à imposer ce langage ?

O.K., je vois pourquoi vous ne voulez pas modéliser intensivement. Notons tout de même qu'il y a déjà une ontologie en place, elle est seulement embryonnaire.
J'ai parcouru quelques pages de documentation à la recherche d'un document expliquant les choix des constructions OWL retenues pour WikiData, en vain. Aurais-tu des pointeurs ? Il y a les pages répertoriées ici mais elles ne parlent pas des choix déjàs faits et implémentés.

Compléments sur les implémentations de la skolémisation en regardant ce qui se fait chez

• Apache Jena : le commentaire reflète la nature polémique qu'a toujours véhiculé cette notion. On notera d'ailleurs que la discussion du groupe W3C chargé de normaliser le concept s'est terminée en queue de poisson. À souligner que chez le W3C la controverse ne portait pas sur ce qu'est la skolémisation, tout le monde était d'accord que ça porte sur des bnodes. Andy Seaborne écrit “Skolemization of blank nodes to IRIs : Don't ask, just don't ask.” sans doute pour éviter de réveiller la controverse.

• Blazegraph : ça c'est l'outil actuel qu'on trouve sur le nœud SPARQL de WikiData. Dans la javadoc, Brad Bebee écrit que l'outil génère des UUIDs pour les bnodes. Ailleurs dans le code, il est précisé comment on retrouve le même UUID pour un bnode donné après (dé-)sérialisation. Je lie le code source pour mémoire.

• RDFLib : pour essayer de casser la monoculture Java évoquée par ailleurs, je mentionne cette lib écrite en Python (voir aussi le point ici-bas) ; dans le code lié, le nom de la méthode est des plus explicites et se passe de commentaire !

• rdf4h : un paquet écrit en Haskell. Le commentaire de Rob Stewart sur la comparaison de bnodes est très intéressant, je le cite en le traduisant : « J'hésite à tester l'égalité entre des bnodes normaux et des bnodes générés automatiquement parce qu'un bnode qui a été sérialisé est parsé tel quel¹. L'autre facteur de doute est que chaque parseur RDF est libre de choisir son format pour les bnodes.»

Eh bien ! revenons aux fondamentaux en rebondissant sur ce qu'écrit R.S. Dans le Mallea et al. déjà mentionné deux fois ailleurs dans les commentaires², dans la sous-section 4.1, on peut lire ceci sous l'intertitre “Issues with blank nodes” : « Les stratégies de parsing de bnodes à partir d'un graphe sérialisé, i.e. un document, varient suivant le parseur considéré et dans le temps. La conséquence en est que pour vérifier si deux graphes proviennent d'une même source, on sera obligé de prouver un isomorphisme or on ne connait pas d'algorithmes généraux à complexité polynomiale répondant à cette tâche. » Cela est écrit bien sûr après une section explicitant sur quoi porte la skolémisation.

En somme, je crois que j'ai apporté suffisamment d'eléments sur la skolémisation en RDF. Jusqu'à maintenant, je n'ai vu aucune source melant cette notion avec les graph patterns et les opérateurs qui leur sont applicables.

Voir ce wiki et la discussion qui est référencée.

Ou alors file des exemples.

Facile ! Soient les triplets suivant :

PREFIX foo: <bar://woe.truc.machin/>
_:a foo:x _:b .
_:c foo:y [ foo:x foo:d ] .

Contrat d'implémentation. Mon moteur SPARQL garantira qu'après sérialisation-désérialisation de ce graphe, on aura toujours le graphe suivant :

PREFIX foo: <bar://woe.truc.machin/>
PREFIX bar: <bar://woe.truc.skolem/>
bar:a foo:x bar:b .
bar:c foo:y bar:e .
bar:e foo:x foo:d .

Maintenant, saurais-tu retourner la faveur et filer des exemples de skolémisation de graph patterns passés au à l'opérateur booléen FILTER EXISTS ?

Basic graph patterns are sets of triple patterns. SPARQL graph pattern matching is defined in terms of combining the results from matching basic graph patterns. […] Any other graph pattern terminates a basic graph pattern.

The filter expression EXISTS is also provided. It tests whether the pattern can be found in the data; it does not generate any additional bindings.

In situations where stronger identification is needed, systems MAY systematically replace some or all of the blank nodes in an RDF graph with IRIs. Systems wishing to do this SHOULD mint a new, globally unique IRI (a Skolem IRI) for each blank node so replaced.

Dans l'article Mallea et al. donné dans un autre commentaire, on lit :

In first-order logic (FO), Skolemization is a way of removing existential quantifiers from a formula in prenex normal form (a chain of quantifiers followed by a quantifier-free formula). […] The central idea of Skolemization is to replace existentially quantified variables for “fresh” constants that are not used in the original formula.

Si tu quantifies existentiellement un graph pattern qui ne saurait générer de nouvelles ressources, ça va être compliqué de le skolémiser, surtout lorsqu'il s'agira de le typer fortement (stronger identification) pour lui conférer une sémantique non-ambigüe.
Et, encore une fois, qu'est-ce qui va se passer si tu as introduit un GP avec OPTIONAL et qu'on admet que la quantification est permise ? Ça s'appellera une « inception-quantification » vu que OPTIONAL peut mener à un GP vide ?

Mais encore une fois, je vois bien pourquoi tu assimiles la quantification ∃ à un parcours d'un graphe à la recherche d'une certaine propriété. Au début, de ce thread, je disais même que j'allais pinailler.

ça me rappelle Nepomuk, ça permettait de faire des requêtes SPARQL […]

Certes, ce n'est pas KDE¹ et ce n'est plus dans la barre de recherche², mais les ontologies de Nepomuk sont toujours utilisées, j'avais évoqué cela dans un autre commentaire et oublié de revenir dans ce fil pour montrer comment les s'en servir.

sh$ tracker sparql --help
sh$ cat > la_requête.rq << EOF

SELECT ?dateModif ?nomFichier
WHERE {
    ?uriFichier nfo:fileLastModified ?dateModif .
    ?uriFichier nfo:fileName ?nomFichier .
    FILTER ( ?dateModif > "2017-01-01T00:00:00Z"^^xsd:dateTime )
    FILTER regex( ?mime, ".odt"^^xsd:string )
} ORDER BY ?dateModif

EOF

sh$ tracker sparql --file=la_requête.rq

Ça pourrait même être le meilleur moyen d'apprendre SPARQL car ça demande zéro configuration pour tout ce qui est outillage SPARQL.

Informellement, oui ça pourrait être ainsi, surtout dans une discussion visant à donner une « douce » introduction. Au-delà de ça, on se rappellera que la sémantique de SPARQL a été montrée équivalente à la logique de premier ordre. De là, il ressort déjà qu'on ne peut pas quantifier sur « des ensembles » (objets d'ordre supérieur, le premier ordre étant celui des triplets, pour continuer dans l'informel), or les graph patterns en sont ; on est limité à quantifier sur les éléments « simples » des ensembles.
Mais il y a aussi la clause OPTIONAL : si on permet de quantifier sur les graph patterns, un EXISTS+OPTIONAL mènera à l'incohérence du graphe dès lors qu'il n'y aura pas de binding utilisable à l'intérieur de OPTIONAL.
Sans oublier que EXISTS appelle NOT EXISTS. Dans une base de connaissances BC où cette dernière clause met le graphe dans une valeur de vérité T, il suffit de trouver un triplet P tel que BC+P conduira à ¬T pour ruiner la tentative de quantification sur EXISTS. La norme garantit que BC+P est cohérent : c'est un graphe donné par la clause UNION.

De rien ! Peut-être que tu pourrais proposer une reformulation du § concerné aux modos.

Désolé de pinailler mais EXISTS et la quantification existentielle ne sont pas AMHA deux notions équivalentes. La première renvoie à un opérateur sur un (mini-)graphe tandis que la deuxième est basiquement un opérateur sur une variable. C'est d'ailleurs pour cela qu'on peut remplacer une variable par un bnode et avoir le même résultat dans les deux cas.

EXISTS est tellement conçu pour les graph patterns que la norme en dote une fonction dans l'algèbre des requêtes. Cela dit, l'équivalence bnodes ≣ variables devrait être utilisé au sein de basic graph patterns car en dehors de ça, les implémentations ont (auraient ?) la latitude d'adopter des stratégies qui leur chantent, sans oublier que si l'on passe à OWL, c'est quasi-garanti de se tirer une balle dans le pied avec cette équivalence. Lecture supplémentaire sur les bnodes avec une enquête sur leur utilisation dans des applications concrètes : DOI : 10.1007/978-3-642-25073-6_27. Le W3C en parle succinctement dans les sections 3.4 et 3.5 de ce document.

Qu'est-ce que ça donne en pratique sur le nœud que tu as présenté ? Tout d'abord, les moteurs de recherche me renvoient sur la spéc. des dumps de WikiData où on peut lire ceci :

Special values
Wikibase data model has two special values - somevalue (unknown) and novalue, specifying value that is known to exist but its exact value is unknown and the value that is known to not exist.

Somevalue
Unknown value is represented as RDF blank node in both simplified and full statements (le dernier graissage est de moi).

Ensuite, un peu de code pour accompagner toute cette exégèse : en reprenant la ressource que tu as introduite dans la dépêche, demandons au graphe des connaissances de WikiData s'il y aurait des pères qui sont encore vivants alors que leur progéniture a été touchée par la mort.

PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>

SELECT DISTINCT ?pèreLabel ?enfantLabel ?enfant
WHERE {  
    ?enfant wdt:P22 ?père .
        FILTER NOT EXISTS { ?père wdt:P570 ?dateDécèsPère . }    # L.a-1
        FILTER EXISTS { ?enfant wdt:P570 ?dateDécèsEnfant . }    # L.b-1

    SERVICE wikibase:label {
        bd:serviceParam wikibase:language "fr" .
    }
}

La requête illustre bien que EXISTS opère sur des graph patterns. Dans L.a-1 et L.b-1, les variables dateDécèsPère et dateDécèsEnfant peuvent être substituées par des bnodes, façon

# […]
FILTER NOT EXISTS { ?père wdt:P570 _:x . }    # L.a-2
FILTER EXISTS { ?enfant wdt:P570 _:y . }      # L.b-2
# […]

et le résultat sera identique au premier.

Enfin, nul doute que tu étais déjà au courant de tout ça ― ton passif sur ces sujets est éloquent de soi-même ― certainement que la phrase a été rapidement écrite entre deux itérations de zoom sur des fractales :p Bref, j'écris tout ce qui précède pour faire de la retape auprès des néophytes dans le domaine.

P.S. Le résultat de la requête contient des choses rigolotes à cause de notices incomplètes sur certains personnages. Ainsi apprend-on par exemple que Sun Tzu est mort et que son père, Sun Ping, est toujours vivant. Le patriarche aurait-il trouvé et appliqué victorieusement l'art de la guerre … contre la mort ?