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

That may be fine, but if you're going to do that please include a (freely 
available) reference *and* explain your particular usage.  Also, consider that 
it is not the *technical* aspects of the language that of key importance here, 
but the human ones:  if datalog syntax can be used to expose provenance concepts 
without baggage then it may be fine, but if it requires understanding a separate 
50-page manual then it's a loser.

#g
--

On 06/09/2011 08:50, Paolo Missier wrote:
> 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
>> --
>>
>
>

Received on Tuesday, 6 September 2011 11:43:30 UTC