W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

RE: Some thoughts about the revised provenance Model document

From: Myers, Jim <MYERSJ4@rpi.edu>
Date: Fri, 30 Sep 2011 16:25:12 +0000
To: "'Graham Klyne'" <GK@ninebynine.org>
CC: "'W3C provenance WG'" <public-prov-wg@w3.org>
Message-ID: <3131E7DF4CD2D94287870F5A931EFC230296C6B9@EX14MB2.win.rpi.edu>
Graham,

I agree that one could have a network of identified things and their provenance connections without requiring attributes. But, I can't think of any real-world use case that can be addressed without having fixed attributes from somewhere. I don't think it would be good to say a pre-requisite for using the provenance model is that you must have another external unspecified means of defining those.

Luc's right that OPM didn't have to address attributes in the same way - OPM artifacts were assumed to only have fixed properties. But we did need a way to specify those to handle the provenance challenges. One of the big challenges in getting interoperability was in reconciling how/where one could get the descriptive attributes. Since OPM did not have a standard serialization one could not rely on being able to query some other RDF relationships - if the binding of the language to a specific serialization did not tell you how to pull information into a standardized construct, you could not access it (without human guesswork). I think that's needed here as well - if we don't specify how one can be assured of getting descriptive information, the prov spec doesn't handle our use cases without external knowledge.

For OPM, if one could have assumed an RDF serialization, it would have been a relatively low barrier to say use OPM with no annotation mechanism and expect that you'll have to use SPARQL and additional RDF-encoded metadata to use it. (If OPM didn't have some statement that 'all RDF statements with the same ID as an artifact could be understood as descriptive metadata about the artifact' then I suspect it would still be a leap beyond logic to do so, but in practice I think it would be ~OK.)

I suspect that is partly what you're suggesting here too, but:
	I'm not sure we have that agreement - without one, there is no interoperable way to get descriptive information (because it wouldn't be in the model and thus there's no way to transfer it between serializations), and
	Even if we do, since entities only fix some of the properties of things, we still need a mechanism to distinguish fixed versus variable attributes from external sources. - we need to know that the date is relevant for an entity representing the weather page on a fixed date, but that RDF statements that associate a date(s) with 'the current weather' page are not usable for provenance queries.

I think both of these points mean we need to have some mechanism in the standard to address descriptive metadata. I would agree with you though that it should (and would) still be possible to use the provenance model with no attributes on anything (open world style). If you don't use them, prov-model compliant services won't get very far in interoperating with you, but, if you've got some other ontologies that are well understood in your community, you could add prov to it and be interoperable in your domain that way.

 Jim


> -----Original Message-----
> From: Graham Klyne [mailto:GK@ninebynine.org]
> Sent: Thursday, September 29, 2011 4:13 PM
> To: Myers, Jim
> Cc: 'W3C provenance WG'
> Subject: Re: Some thoughts about the revised provenance Model document
> 
> Jim,
> 
> If I understand you correctly, the significance of attributes is for discovery of
> of related resources.
> 
> My understanding is that the primary purpose of provenance is to establish a
> basis for trust, a reason to believe (or not) some information that is
> presented about some subject.  It's not clear to me what need there is to
> use attributes for resource discovery to achieve this end.  (But I may well be
> missing something here.)
> 
> So, on this basis, there may be perfectly good reasons to have defined
> attributes and values for discovery purposes, I'm not seeing why they are
> needed to achieve the goals of *provenance* information.
> 
> (But it's getting late here, and maybe I'm missing some key point in your
> message.)
> 
> In summary: I think your concerns are reasonable, but what makes them in
> scope specifically for *provenance* information?
> 
> #g
> --
> 
> On 29/09/2011 18:44, Myers, Jim wrote:
> > Graham,
> >
> > How would we use provenance to find, for example, how Luc got to
> > Boston? It's clear if we have fixed attributes for name and location
> > such that we could query for an entity with name Luc that has an ivpOf
> > relationship with an entity in Boston and then look at the provenance
> > from there. How would it work without fixed attributes in the prov
> > model? I'm guessing that you're thinking that we can find those
> > attributes outside the language somewhere (e.g. non-prov RDF
> > statements) but what are the minimal requirements there and what
> > language/models exist that meet them? Can we only model provenance of
> > things for which ontologies have been developed? Presumably it has to
> > be possible to associate descriptive metadata with the entities
> > through some path (what relationship(s)?)? And it has to be clear
> > which metadata is fixed? You mention being able to infer across ivpOf
> > relationships - is there one set of inference rules for all possible
> > descriptive metadata? Or do we need to be able
> to distinguish further between types of metadata?
> >
> > -->  As you can probably guess from the questions above, I'm concerned
> that kicking fixed attributes out will end up being more complex and place a
> higher burden on users than keeping them in, but I may be misunderstanding
> how such an alternative would work. Part of that concern is that I think I
> hear that modeling experts in this group can handle defining classes for
> different types of entities that would allow discovery by attribute, but I'm
> concerned that being able to do this becomes a requirement for using
> provenance (versus asserting entities defined solely by attributes(entity,
> name=Luc)  or perhaps in a mixed mode (e.g. an entity representing Luc that
> 'hasBaseType' foaf:person and one representing him in Boston that also
> hasBaseType foaf:person and location=Boston as a fixed attribute.) Again -
> perhaps I'm misunderstanding how discovery based on descriptive
> information could be done if we don't have fixed characterizing attributes in
> the prov standard....
> >
> >   Jim
> >
> >>
> >> 3. Do we need to model "Characterizing attributes"?
> >>
> >> The notions of "characterizing attributes" have developed to derive
> >> the relationship between different entities that are views of some
> >> common thing in the world.  I am not convinced that we need to model
> >> these attributes, and I'm not sure the way they are modelled can
> >> necessarily apply in all situations that applications might wish to
> represent.
> >>
> >> At heart:  when it comes to exchanging provenance information, why do
> >> we
> >> *need* to know exactly what makes one entity a constrained view of
> >> another?  What breaks (at the level of exchanging provenance
> >> information) if we have no access to such information?  How are
> >> applications that exchange provenance information about entities for
> >> which they don't actually know about these attributes to know about
> >> their correspondences with real-world things?
> >>
> >> I think the role of attributes here is mainly to *explain* some
> >> aspects of the provenance model, but they do not need to be part of the
> model.
> >>
> >> To my mind, a simpler approach would be to allow for assertion of an
> >> IVPof type of relationship between entities, from which some useful
> >> inferences about any attributes present might flow, but I don't see
> >> the need for the attributes to be in any sense defining of the entities.
> >>
> >> <aside>
> >> My suggested definition of IVPof might be something like this:
> >>
> >>     A IVPof B  iff  forall p : (Entity ->  Bool) . p(B) =>  p(A)
> >>
> >> where A, B are Entities, and the values of p are predicates on Entities.
> >> </aside>
> >>
> >> ...
> >>
> >> #g
> >>
> >
> >
> >
Received on Friday, 30 September 2011 16:25:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:42 GMT