The linguist’s spouse walked in, caught the marriage partner sleeping with a co-ed and said, “I’m surprised.” The linguist bolted upright, pointed the finger and corrected , “No. I am surprised. You are astonished.”

Thanks for a lovely gettogether and cocktails!. I recall the days when in the Officers Mess, I was expected to ask only for Whisky. I always went for Scotch. Occasional beer to wash that whisky down was normal. I liked the Fench Contreau after dinner. With men I had to have their drink – Rum. Without limits.
With all regards to French champaignes, I liked to have ‘Sovetskoe Shampanskoe’. Of course a tot of Vodka any day any time.
Now, I have had enough of all that, just a few glasses of hot water without any additives are fine with me.

"In ..., we have the prohibition."

A NOTE ON PIFFLES

by A. B. Smith

Introduction.

A.C.Jones in his paper “A Note on the Theory of Boffles”, Proceedings of the National Society, 13, first defined a Biffle to be a non-definite Boffle and asked if every Biffle was reducible.

C.D. Brown in “On a paper by A.C.Jones”, Biffle, 24, answered in part this question by defining a Wuffle to be a reducible Biffle and he was then able to show that all Wuffles were reducible.

H. Green, P. Smith, and D. Jones in their review of Brown’s paper, Wuffle Review, 48, suggested the name Woffle for any Wuffle other than the nontrivial Wuffle and conjectured that the total number of Woffles would be at least as great as the number so far known to exist. They asked if this conjecture was the strongest possible.

T. Brown in “A collection of 250 papers on Woffle Theory dedicated to the honor of R.S.Green on his 23rd birthday” defined a Piffle to be an infinite multi-variable sub-polynormal Woffle which does not satisfy the lower regular Q-property. He states, but was unable to prove, that there was at least a finite number of Piffles.

T.Smith, L.Jones, R.Brown, and A.Green in their collected works “A short introduction to the classical theory of the Piffle”, Piffle Press, $20, showed that all bi-universal Piffles were strictly descending and conjectured that to prove a stronger result would be harder.

It is this conjecture which motivated the present paper.

Dept. of Pure Mathematics, The University. Sheffield, England, 1966

Cause versus correlation

Impossible to differ. Therefore, a high correlation of the appearance of storks and the birthrate obviously proves creationism. Details of the proof are left, as a simple exercise.

Normal distribution

Q: Do you know the newest joke about statistics? A: Probably.

Is assumed to be given. Should a random variable, against rationality, be abnormally distributed, the “Central limit theorem” holds. Thus, 1234567 monkeys with a typewriter each must incorporate an author of “Romeo and Juliet“, up to a probability of 0.99.

Graph theory

Contrary to needs (e. g. in bookmarking), instead of using more realistic applications based on multiigraphs, methodologies using trees, endowed with cost functions, are investigated.

Mathematical logic

As Shakespeare put it: “Faith is FOL and FOL is faith”  Despite the significance of predicate calculus,  FOL alone is not even capable to define the natural numbers.Nevertheless, everyone (AKA every{{ø}}) seems to be a FOL-goer, especially since no Last Order Logic exists.

Conclusively

1. Thank you very much for the contributions to recreational mathematics (supplied with no express guarantee as to its suitability). Obviously the language of mathematics is not adequate for all. No problem, but trivially the language of science is.
2.  Considering that such ridiculous flaws i. e. non sequiturs) are propagated (standing on the shoulders of giants) and gain relevancy by perfectly citing them using the Chicago Manual of Style (sacred) or publishing them in Wikipedia (very subtle vandalism), as then they can become dangerous to your keyboard.
3. Just give me the change!

When I think of all the good time ….

The target audience includes researchers from academia, tool vendors, system suppliers, and users in industry who are interested in the all aspects of the topic.

Nothing is going to change my world.

However, the “you are looking at the wrong problem” response
came from a longstanding prominent member of the Petri net
community who has done his share of Petri net training/education,
so I wonder whether it represents a view shared by many here?

Personally, I find that the barrier between modeling and
programming has been lowered almost to insignificance in
modern declarative languages (where, roughly, one tries to
model the application domain, then adds a little programming
about what to do with the models). Which is one of the reasons
I enjoy working in and with these languages, and why I think
that combining Petri nets and declarative languages more deeply
would be profitable.

Quite apart from this, modeling and programming languages
face similar issues in design, implementation, tools, and use, so
sharing solutions and approaches would help even if the barrier
between the activities of modeling and programming would still
be present these days.

And yet, this surprising response has reminded me that specialists
who have immersed themselves in Petri net research might harbor
just as many unhelpful notions about modern programming
languages as specialists in programming languages do about
modern Petri nets. So perhaps readers are not joining this
discussion because they think there is nothing to discuss?

Obviously, I think otherwise;-) but if that would help (please
let me know), I could give a few concrete examples of why I
think that the two worlds of Petri nets and declarative
programming languages should move closer together (as in:
specialists in both areas should be more aware of developments
in both areas, and developments in both areas should profit
from expertise from both areas). I’ll start with the most extreme
example I can think of: Constraint Handling Rules (CHR).

From the CHR website at KU Leuven

<http://dtai.cs.kuleuven.be/CHR/>:

Created by Thom Frühwirth in 1991, the CHR language
has become a major specification and implementation
language for constraint-based algorithms and applications.
Algorithms are often specified using inference rules, rewrite
rules, sequents, proof rules, or logical axioms that can be
directly written in CHR.
..
CHR – a concurrent language for constraint systems,
logic, agents, and more

I first encountered CHR a few years ago when they were
used to specify and discuss semantics of popular extensions
to Haskell’s type classes, hardly a topic where you would
expect to find Petri nets in use.

And yet, so much about CHR seemed so familiar that I
finally realized that CHR defines a family of languages
that are isomorphic to the family of Coloured Petri Nets
(CPN): every type of CHR corresponds to a type of CPN,
and vice versa!

The host languages of CHR correspond to the inscription
languages of CPN, the constraints and predicates of CHR
correspond to the tokens and places of CPN, the constraint
store of CHR corresponds to the current marking of CPN
and the rules of CHR correspond to the transitions of CPN.

The main differences are in pragmatics – how the models
are used, and which features are preferred or have good
support. For instance, CPN have all but replaced Predicate/
Transition Nets and logic inscription languages do not seem
popular for CPN while CHR use unification prominently; or
CPN modellers tend to avoid transitions which are always
enabled, while CHR have special support for some of these
(propagation rules) in terms of scheduling (no repeated
firing); CPN models are often used for their processes,
while CHR rulesets are often used for their final constraint
store; and so on.

I posted those observations to the CHR mailing list in
June 2006 (to access the list archives, the KU Leuven
listserver requires you to login, just to confirm you exist)

https://listserv.kuleuven.be/cgi-bin/wa?A1=ind0606&L=chr
(first thread, subject “! (CPN o-o CHR)”)

Hariolf Betz, a student of Thom Frühwirth, wrote up
some of those ideas in a CHR’2007 workshop paper:

Relating Coloured Petri Nets to Constraint Handling Rules
http://dtai.cs.kuleuven.be/CHR/biblio/Year/2007.complete.html#betz_petri_nets_chr07

but while this paper is now often cited, the potential of the
connection between CHR and CPN has remained largely
unexplored so far (at least in part because of the reasons
explained in the first email in this thread). It might help if
Petri net researchers started exploring the possibilities
from their end, or would at least offer to help CHR
researchers with finding and translating the relevant
parts of the Petri net literature (from applications over
implementation/optimizations to semantics and complexity).

This survey might serve readers here as an introduction
to CHR and its research topics:

As Time Goes By: Constraint Handling Rules -
A Survey of CHR Research between 1998 and 2007
http://dtai.cs.kuleuven.be/CHR/biblio/Year/2010.complete.html#chr_survey_tplp10

And that is only one example of why more collaboration
between Petri net and programming language folks
would be useful, IMHO.

are there any groups working on or interested in funding work on
bridging the gap between the Petri net and programming language
communities? And do you agree that there is a gap to be bridged?

My own impression, coming from the language side but with a net
background, is that awareness and use of Petri nets among
programming language researchers and practitioners is not nearly as
good as it should be. Also, attempts to interest language colleagues
in nets are hampered by needless obstacles on the net community
side. These obstacles are unintended, merely a result of differences
in cultures and approaches to communication and community building.

As a result, programming language researchers occasionally reinvent
wheels long known (or already forgotten..) in the Petri net
community.  The problem is not so much the reinvention itself, but
that it is not informed by the earlier efforts and that, if the
reinvented wheels do include any new ideas, those are not fed back
into the net community. Also, partially successful reinventions
attract their own followers, publication venues and workshops,
continuing the story of duplicated development and lack of
communication. We now have several active communities working on
variations of the same theme, without being entirely aware of each
other’s work. The other side of the coin is that Petri nets do not
profit as much from programming language research as they could.

One concrete topic that I think would help, and that I would like
to be able to spend more time working on is to present and develop
high-level Petri nets as a declarative programming language.
Apart from its intrinsic potential, this could also serve as a kind of
“rosetta stone”, providing an example translation between programming
language and Petri net terminologies and concepts. So those interested
in other aspects of Petri nets or programming language research could
use this project to help them get acquainted with the other side.

Sub-topics that I am interested in pursuing include:

(1) presenting high-level Petri nets in a way that programming
language people can relate to,

(2) applying language design principles and ideas to Petri nets,
and Petri net ideas to programming languages,

(3) presenting place/transition and condition/event nets as
simplifying abstractions of high-level nets for analysis,      not as intermediate models,

(4) moving beyond editing Petri nets as bipartite graphs
(emphasizing semantic over syntactic editing)

(5) promoting Petri nets as a means to communicate computational
thinking by introducing laypeople to programming concepts,
with little or no syntactic overhead or semantic complexity.

(1) is partly community building, partly developing the tools that
enable successful communication, partly reformulating the existing
formal foundations and practices in ways more accessible to the
target audience (the analysis parts of 2 are a prerequisite for this
to work, and the ‘nets as types’ slogan from 3 will help to provide
motivation); beneficiaries will be software developers who work in a
distributed context but are not yet aware of Petri nets, but also
the Petri net community as a whole, by extending their visibility
and reach into the programming language community and by gaining
access to additional expertise (enabling the exchange parts of 2).

(2) is about exchanging ideas between the two communities in order to
improve foundations and practices in both; there have been
successful, if isolated, instances of this in the past, but also
spectacular failures of communication; 1 will hopefully encourage
a wider exchange and help to reduce duplication of efforts in
future; my specific interests are in combining pure functional
languages and Petri nets, beyond the widely popular Coloured Petri
Nets in which functional languages are merely inscription languages
inside Petri net structures; but even just analyzing Petri nets wrt
language design principles and ideas will help to support 1 and 4.

(3) programming language folks value their language’s expressiveness,
which can have the surprising effect that previous exposure to
simple net types can lessen their interest in attempts to describe
higher-level nets (it can make the latter look like an insufficient
base model with “bolted on” inscriptions, or the net structures as
insignificant add-ons to the inscription language “doing the work” -
neither impression is helpful; and if someone does not succeed
immediately in “getting” the implications of high-level nets, the
interplay of net structure and inscriptions, and the modeling
options offered by this combination, they tend to fall back on their
understanding of simpler net types to base their evaluation on);   the suggested alternative is to make use of the fact that
programming language folks are very familiar with simplifying
abstractions of full programming languages for analysis, eg in the
form of type systems; if we consider the separation of nets into
dynamic parts (marking) and static parts (structure), the slogan
becomes: net structures are the static types of concurrent systems.

(4) is about a problem most Petri net modellers will be familiar with:
not only does one tend to spend all too much time fiddling with the
graphical representation, but editing graphs, while sufficient to
achieve the intended model modifications, does not reflect semantic
model operations; when editing programs, there are similar problems
if the editor uses only string or syntax operations; no matter whether
the syntax is textual or graphical or hybrid, one really wants to
move beyond syntax, towards semantics-based operations.

(5) is about going even further in terms of accessibility and
promoting the advantages of “Petri net thinking” (once we can
explain high-level Petri nets to programming language folks in a way
that maintains their interest, can we also explain them to
laypeople?); many successful programming language communities have
strong beginner-focused efforts, where language fans try to promote
and support (via tools and tutorials) their favourite language as
best first-language-to-learn-programming and, more generally, recent
efforts to promote “computational thinking” seem strongly coloured
by algorithms and programming languages backgrounds;
mixing in some Petri net views into the “computational thinking”
efforts would more easily encompass understanding of concurrency,
distribution and communication, providing benefits to both the
campaigners and their audiences, while raising general awareness of
Petri nets; thinking about presenting Petri net ideas to beginners,
without immediately jumping into a specific formalization in terms
of matrix algebra, graph theory, formal multiset rewriting, and the
like, will provide benefits to anyone thinking about Petri nets, not
just beginners new to the topic, but also to experts thinking about
possible extensions and variations.

I’d appreciate pointers to existing work on any of the above topics.

Moving from research agenda to funding, it is obvious that the above
topics cover a wide enough range of work that progress without funding
specific to Petri net research and development is frustratingly slow,
and success without community involvement is impossible. In fact, I
tend to have so many ideas that, even after filtering out the bad
ones, it would be helpful if some of them could be farmed out, to
colleagues who have the background or to students who have the time to
fully realize their potential.

In the past, I have been working in declarative programming research
contexts, but I was also given a good -if somewhat dated by now-
basis in Petri nets. Ideally, I would be looking for a full-time
research position in a group that complements this background, i.e.,
a group strong and active in high-level Petri nets (so I can catch
up on recent developments and better understand and interact with
the net community), but open to declarative programming languages
and ideas (supporting my efforts to build bridges and providing a
local forum for testing and exchanging ideas).
If there are no full-time positions in these directions, I would also
be interested in suggestions on alternative routes of funding, ways
that would allow me to spend at least one day a week on pursuing my
Petri net related research & development interests while paying the
majority of my bills from other employment.
As one example of a spin-off from personal work that could be of
wider community interest, I am currently working on a simple
Javascript/SVG based Petri net editor: I mostly want to get rid of
the troublesome GUI library dependency for my own CPN simulator,
using a webbrowser as a GUI instead. As I am interested in simple
CPN simulators that can be written by embedding CPN variants into
their inscription languages, it is also important to decouple the
GUI from the inscription language. That way, the same GUI could be
re-used for Haskell-/Erlang-/Clean-/F#-/..-Coloured Petri Nets if
those language communities could be interested in applying CPN
modeling as part of their software development processes.

With some more work, the Javascript/SVG GUI could also be useful for
other groups (an alternative, common GUI, allowing smaller groups to
focus on their simulators and analysis tools), and with more work
beyond that, it opens the possibility of bringing Petri nets to the
web, making it easier to write blogs and tutorials about Petri net
models and their simulations (earlier efforts based on Java- and
Flash-based implementations have not yet resulted in ubiquitous
Petri nets on the web, where the tendency seems to be away from
plugins; the alternative of using animated gifs or sequences of  pngs also does not seem to enjoy widespread use, nor does it offer
quite the same possibilities).

Working on my own resources, time available continues to be very
limited and, within that time, I have to give priority to my research
interests, keeping graphical editing features to a minimum and not
spending time on providing standard APIs or on supporting browsers
that I do not use.  That means progress continues to be very slow for
me and wider opportunities for the Petri net community are going to be
missed. The same obstacles apply once I get back into the more
interesting issues, beyond the good old-fashioned graphical interface
to a good old-fashioned CPN simulator, but based on earlier
experiences, a tweakable and portable graphical representation seemed
a necessary first step towards presenting and distributing the results.

If interested research groups, projects, and companies, or the
steering group as representative, could allocate funds for
infrastructure and community development in their budgets, and use
those to fund external part-time researchers and developers, those
could then develop open-source components for community use (I expect
that there would be others willing to allocate a day or two every week
to such work, remotely, if the funds can be made available). If this
works out, it would be a more distributed approach to research and
development – groups of part-time workers could make progress where
there isn’t sufficient funding for additional full-time researchers,
or where non-academic workers have the abilities, but cannot commit
themselves full-time because of other demands.

In short, the questions are: can I do research and development in
the overlap between Petri nets and declarative programming
languages, full-time or part-time, while still making a living? And
who else is interested in or already working at the border between
Petri nets and declarative programming languages?
I feel these ideas are important but, without topic-specific funding,
I can only work on them in the gaps between other projects and am not
able to invest the amount of time they deserve.

Looking forward to your suggestions,
Claus

PS. A few more notes on my view of the community communication problem:

Occasionally, I have been able to interest programming language
colleagues to take a look at the Petri net home page and
bibliography, but not one of these has ever returned from there with
surviving interest (as far as I know, the “impact” of my efforts has
been limited to inspiring one dedicated paper and a few publications
mentioning Petri nets as related work, none of which fully explored
the implications).
A couple of colleagues, when asked about this, explained that they
would have liked to investigate further but found it difficult to
relate the specialist nomenclature and concept set used in the Petri
net literature to that used in their own areas of expertise (eg., if
you don’t know what terms to search for, you cannot even begin to
try understanding the relevant publications, and if the organisation
of concepts differs too much, important ideas can get lost in the
translation). So I have come to the impression that the general lack
of interest in Petri nets from programming language researchers
(with rare, but interesting exceptions) is not entirely due to
self-propagating biases towards process calculi or state machine
based modeling languages.

Since I remain convinced of the advantages and potential of Petri
nets in general, and of the combination of Petri nets and
declarative programming languages in particular, I am beginning to
think it is a problem of presentation, mindset, and accessibility.
There is evidence that mindset-related obstacles in the world of
programming languages can be overcome – for instance, pure
functional languages like Haskell force a different approach to
thinking about programming that many conventionally trained
programmers find difficult. With a lot of help from a friendly and
open community, however, even non-academics have seen this as a
worthwhile challenge, tackling of which will improve their general
programming skills, and so this community keeps growing.

Physical accessibility remains a problem. In addition to an
overwhelming amount of publications, there are many good books on
Petri nets, but all too many papers are not freely accessible – even
the PNML standard is hidden behind a paywall. Too many lists of
publications point to paywalls or only provide references to
hardcopies. The books and paper proceedings are expensive and not as
widely available as one might think if one only frequents the
library of a university that has a strong Petri nets group or a
consistent history of buying certain proceedings by default.
That means that privately interested (and privately funded)
newcomers can find it difficult to find enough second-stage
introductory material (beyond the mere definitions) to guide and
motivate them into choosing and buying one or more of those
expensive books, and once they want to delve into details beyond
those books, they run into the next wall (some book authors make
introductory parts available online, and some paper authors make a
copy of their papers available online as well – in programming
language circles, this is the rule, not the exception).

There is also a non-physical aspect of accessibility that links
directly into presentation: programming language folks are used to
active online communities, with mailing lists, wikis, irc channels,
blogs, blog aggregators (feeds presenting updates from multiple
blogs related to the same language), and lots of freely available
online resources, such as bibliographies that link directly to
online versions of papers, code repositories for community-provided
software packages, etc. There are also specialist discussion sites
on which links to new online resources or papers are passed on and
discussed.  The vast majority of interested parties, including
privately interested persons and open-minded commercial developers,
are not able to visit the central conferences and workshops in
person and may not have easy access to a university library, either,
so online communities are key to good communication and progress.

Note that I am mainly interested in building _direct_ bridges
between _practitioners_ of programming languages and Petri nets:
programmers and modelers, language and net type designers, language
and net type implementers and tool builders. Theoreticians are often
already aware that programming languages and Petri nets are just
different instances of their theories. But trying to move between
the two fields via their theories requires multiple nontrivial
jumps – busy practitioners (who could spend all their lives just
staying abreast of their own fields) need a more direct route.

Also, precise language definitions and formal semantics are
important, but good online documentation, online examples, and lots
of short online tutorials on all topics, written not only by
experts, but often simply by fellow searchers who run into the same
issues, drive community interest.  It is important to present the
benefits and pragmatics before delving into any formalisms, and it
is important that people can communicate with others in the same
learning situation and feel involved in community building.

Where are the Petri net blogs? The net repositories (PetriWeb
content seems somewhat limited)? The tools for hosting Petri net
contents?  The Petri net wikis? The links to online papers in the PN
bibliography? Why do not all Petri net research groups and authors
have copies of their papers online (usually permitted for the
author’s home page), to help distributing their results and ideas?
Where are the Petri net discussions (for both beginners and experts,
not to mention specialist interests beyond specific tools)?  The
Petri net HowTos (how to model a distributed software system? how to
model a web application stack? how to model xyz? how to apply Petri
net tools and techniques to situations faced by todays programmers?)?   Where are the communicators that build on these tools in order to
explain the details and relevance of tricky or formalized
publications to interested practitioners? Is all Petri net
development activity restricted to universities and a few spin-offs?
Is all communication limited to workshops, conferences, and
in-person tutorials?  How can non-academics keep up to date with
recent developments, or contribute to spreading the word? ..

One useful starting point might be a collection of survey articles,
providing entry points and guidance about the various areas of
research documented in the publications listed in the Petri net
bibliography. That way, newcomers would at least have an idea what
to look for.

> One of the dangers of contrasting (for example) statistics with logic is that this is really about comparing empiricist and  rationalist methods.

I agree that one should not confuse mathematical methods with any kind of dogma — empiricist, rationalist, or theological.

Mathematical methods, including logic and statistics, are neutral with respect to any kind of application. For example, one could apply statistics to bridge either by a priori calculation of the probabilities or by gathering data about how people play the game.

@DW

> … every new science must find a fertile balance between these scientific methods, and the recent swing from “linguistics should  be rationalist” to “linguistics should be empiricist” takes us to  another glass ceiling.

As a science, linguistics is as old as Aristotle, and the pendulum is always swinging. In the 1950s, information theory and grammar discovery procedures were dominant, and Charles Fries did some very interesting work with the tiny corpora available.

In the late ’50s, Chomsky began his campaign against statistics, information theory, grammar discovery procedures, and finite-state machines. Instead, he promoted “the native speaker’s intuition” (i.e., his own intuition) as the ultimate standard.

Computational linguists have always been more empirical. Even when they used their own intuition to write grammar rules, they tested them by running their systems on actual data. That’s just as empirical as a physicist’s using intuition to write a theory and then testing its predictions against the data.

The ultimate criterion for science is the ability to make predictions about future observations. It’s irrelevant whether the methodology began with intuition, statistical analysis, or some combination of both.

John Sowa

Michal

Dear Corpora colleagues, Do you think LINGUISTICS is SCIENCE or ARTS? I think the discussion about linguistics using either the scientific or artistic methods, is quite interesting. Really, is it ARTS (the Humanities) or Science. If we divide this man activity into Sciences and Arts, then linguistics for the exception of phonetics is Arts. Can linguistics reconstruct some parent language? We know that all the Romance languages have the parent language, i.e. Latin. But can linguists reconstruct Latin on the basis of Italian, Spanish, French and other Romance languages? The answer is NO. If linguistics had been SCience, then it would have been possible. But it is ARTS, thus it is impossible. Or am I mistaken? Looking forward to hearing from you either directly yutamb@mail.ru or via the net.

Be well, Yuri Tambovtsev
> _______________________________________________
> Corpora mailing list
> Corpora@uib.no
> http://mailman.uib.no/listinfo/corpora
>
>

This is a good question, but not one that can have a fully satisfying answer. Personally, I want to extend the title “linguist” to everyone who studies language in a serious way. Given that, I find myself confronted with a bewildering range of approaches, and little commonality between the activities of different kinds of linguist. The range clearly includes things that could be seen as physics or physiology, others that look more like philosophy, sociology, history, geography, psychology, various flavors of biology, lots of computer science, different kinds of pure and applied mathematics,
anthropology, cultural studies, and so on, even up to astrobiology and cryptography. Some of these satisfy my internal gut feeling for what sciences are like, others not so much. Even the ones that don’t seem especially scientific have a tendency to fit squarely into the German term “Geisteswissenschaften”. Literally, this means “sciences of the spirit”, in practice it corresponds to what the Anglo-Saxons tend to call “Arts” or “Humanities”. By this stage in my thinking I am inclined to reject the dichotomy implied in the question.

I think Linguistics is a good example of why we should not worry too much about whether things are sciences, and why we should worry more about whether the work we are doing will make an important difference to anything that we care about. The second question is quite challenging enough.

Chris

I can’t agree with “move the data to the computation”, unless you mean in general “get the computation and the data together in the same place”. The main thing is that once you are parallelizing /distributing work that involves tons and tons of data, network bandwidth becomes a key resource, so reducing transportation needs is every bit as important as making individual computations fast and effective.

The astronomical and biomedical communities have been more or less on top of this for years, there are plenty of stories of researchers sharing data by mailing CDROMs around the place or even just sending hard drives around in the mail. But if the algorithm you’re coding up is orders of magnitude smaller than the data it will be run on, you move the code to the data not the data to the code. This is
increasingly normal, that’s why we talk about datacenters not codecenters.

Best wishes,
Dominic