Re: PROV-ISSUE-87 (Model-concepts-formalism): Formalism used is not explained, not applied to concepts [Conceptual Model]

Hi,

just my 2 cents/pennies:

\begin{provocative}
I really feel we don't need another language. The current syntax is close enough to that used in good old logic databases that we 
should make an effort to just use some dialect of Datalog, which also comes with well-defined semantics. We may discover PASN is 
special in some way, but I would not be surprised if we instead discovered that it isn't.
\end{provocative}

-Paolo



On 9/6/11 7:03 AM, Graham Klyne wrote:
> On 05/09/2011 22:38, Luc Moreau wrote:
>> Hi Graham,
>>
>> I think this is a key point, and I agree with it.
>>
>> On 05/09/11 22:04, Graham Klyne wrote:
>>> To make the PASN worthwhile, I think it needs to be *much* easier to
>>> understand, to the point that it becomes easier to write a provenance
>>> assertion in PASN rather than in RDF. (Rather like the way it's easier to
>>> write OWN class expressions using the "Manchester" or similar syntax rather
>>> than expressing them in RDF.) Currently, the exposition of PASN isn't
>>> satisfying this criterion, IMO.
>> Could you tell us what you would like to see, which would make it
>> understandable, and meet that criterion?
> I partly covered this in the other message I just sent:  focus the document
> about explaining the provenance model in terms of the abstract syntax, don't
> relegate it to an appendix.  Introduce it up front with an explanation that it
> is a serialization-neutral syntax for expressing provenance assertions, then
> define each of the key constructs in terms of its abstract syntax (somewhat as I
> did with the alternative definition for "Entity" posted recently).  Thus, the
> entire document becomes a description of the abstract syntax.
>
>> In particular, when you say that you don't how to interpret the syntax, do you
>> mean formal
>> interpretation? or do you mean something intuitive?
> Something of both.  What I believe is needed is to provide a strong intuition
> that can be developed and refined to a formal construction.  This is why I place
> so much emphasis on choice of terminology:  the wrong terms don't evoke the
> right intuitions, and without the right intuitions it is very hard to follow or
> understand the purpose of the formal constructions.
>
> <aside>
> I've long felt there's a problem here with the teaching of mathematics:  many
> important results have their roots in clear intuitions, but teaching often
> focuses on the formal proof which often obscures the important intuition.  The
> role of intuition is underplayed, but it is, if you like, the UI of a
> mathematical theory.
> </aside>
>
> So, back to the PASN:  following an overview of the purpose and role of PASN, I
> think a formal syntax is a useful start - defining the wffs of provenance
> assertions.  Then for each production, a description of the intuition of what
> that construct expresses, with simple examples. Finally, one might choose to
> provide a more formal definition, e.g. a mapping to FOL, or maybe a more model
> theoretic approach, from which valid inference patterns may be deduced.
> Alternatively, one might prefer the separate mapping to RDF and OWL to provide
> the linkage to formal inferences.
>
> I also think the formal syntax of PASN should be the framework around which the
> mapping to RDF and OWL is defined.
>
> #g
> --
>


-- 
-----------  ~oo~  --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier

Received on Tuesday, 6 September 2011 07:50:54 UTC