Fwd: comments on the prov example

Some comments from Paolo, who is not on the mailing list yet.
Luc

-------- Original Message --------
Subject: 	comments on the prov example
Date: 	Thu, 12 May 2011 18:12:13 +0100
From: 	Paolo <pmissier@acm.org>
Reply-To: 	<pmissier@acm.org>
To: 	Luc Moreau <L.Moreau@ecs.soton.ac.uk>, Paul Groth <pgroth@few.vu.nl>



Hi,
   (emailing privately since I am not on the list)

I am a bit nervous about the proliferation of edge types before a semantics is defined for them, because they may appear arbirtrary
if we are not careful. I see the immediate need for principles that allow contributors to introduce new elements into the model --
otherwise, one ends up with a "semantic Web" view of PIL (no disrespect :-)) where anyone is entitled to add new properties to some
namespace, with no restrictions. I think we should do better.
   The approach that I assume you are using, albeit implicitly so far, is to add specialisations to Processor and Artifact (in OPM
terms) and then define constraints on the type of relations that can exist amongst these. Is that the case?
For example: you seem to have an implicit rule that says

    R wgby P:pub,    P:pub  used C   =>   R copyOf C

where R, P, and C are variables, "pub" is a Processor type (it specialises Processor), and you apply the rule by matching the
pattern to graph fragments, for example:
   R<- r5, C<- c2, P<- pub4  =>  r2 copyOf c2

Similarly, you seem to have

    P:dwnld  used R ,   LCP wgby P:dwnld   =>   LCP isRepresentationOf R

with an instance in the graph: LCP<-lcp2, R<-r3, P<-dwnld2  (and another nearby)

I hope this is what you have in mind, and if so it makes sense to me. However the question is, which of these types are core, which
are extensions, and who makes the rules?
I guess there will be a significant few common processor types that we can deal with in this way (those that operate on data
collections are an example, as they are grounded in a well-defined functional model of collections). But how do you go about
introducing new processor types?
it seems to me that the framework for adding element to the model should be discussed even before the model itself!

A further but related note on  17. collections:
   Issue: what collection algebra do we support? what are the corresponding process exececutions (types) and derivations?
   Issue: should we define Collection as a type of RSR? (cf type issue for RSR)?
   Issue: where do we define this notion? in the core model or in the best practice?

this is where I am currently trying to help. I am using the approach I just described, with the advantage as I wrote above that
collections are well understood data structures in the functional programming framework, so the processor types are well defined. I
hope to be able to contribute to the group on this point at least.

bw -Paolo


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