- From: Myers, Jim <MYERSJ4@rpi.edu>
- Date: Thu, 14 Jul 2011 16:20:04 -0400
- To: <public-prov-wg@w3.org>
Sorry about this dropping off the list - didn't realize that somewhere we hit 'reply' instead of 'reply all'... > -----Original Message----- > From: Myers, Jim > Sent: Thursday, July 14, 2011 3:17 PM > To: 'Simon Miles' > Subject: the nature of a bob (was Re: Models and their use) > > Not sure I understand Luc's categories but I'll try to break up my > comments on different points: > > > Jim, > > > > >> Not sure about this... what is the relevant difference between an > > >> instance and an entity? > > > > > > I think this is the 'thing as representation of entity' debate. I > > > think we > > require that a provenance thing/entity/bob has to have an ID and a > > set of properties with values that can be retrieved. > > > > I don't know if this is a real point of contention or a matter of > > language, but I disagree with the last part of the above. "that can > > be retrieved" does not, to me, seem to be part of the model, it is a > > matter of access. We surely can't involve access control issues etc. > Yes - I was not intending to talk about access. My point was more that > a bob defined as something with an ID and one or more property/value > pairs is sufficient to address our use cases even though our concept > of what that bob is may be richer. Let me try an example, though it > may open further cans of worms: Consider a java object that has a > local ID and a sameAs() method that will return true if it is > indistinguishable from another one. Can this be a bob? I'd like to say > 'no' and require that you be able to capture everything we need to do > provenance in a globalID and properties for that java object. This > means the search language can be restricted to talking about IDs and > properties, etc. versus allowing a query to find the provenance of a > bob where bob.sameAs(new JavaObject(a,b,c)) is allowed because that is > the only way to find this bob by descriptive info. I realize this > example goes beyond the model itself but hopefully it gives some sense > of why I'm trying to distinguish the bob from the richer model. > Perhaps saying that we only want to talk about the provenance of > entities that can be serialized to {ID/set of properties} and that our > model and query language etc. will all rely only on that serialization makes sense? Does this mean I'm jumping the gun and going beyond conceptual model to implementation? > > > > in a conceptual definition. I assume you are referring more to what > > is asserted, but it does not seem obviously feasible to require that > > any property be asserted, or that it should be part of the concept definition. > > What we can say is that, in using the model, what is relevant for > > provenance are assertions of what is invariant. We might also place > > a restriction, if really necessary, that something generated, > > derived or used must have a property value asserted of it (though I'd prefer not to). > > > > I'm not convinced we need to say that an entity has properties. > > There are things which are true of an entity, which we can call > > properties, but this seems superfluous - what does *not* have > > properties? But I don't have a strong objection if people think we need to. > > > I think my comments above address this some, but I'll just say again > that I don't want to make it mandatory for 1 or more properties to exist. > > > > Instances of classes in other ontologies, or of programming > > > language > > classes etc. could be richer - have behaviors, restrictions on > > property values, etc. > > > > Does this actually mean there is a difference between PIL entities > > and instances of classes? If the behaviour of an entity is always > > the behaviour of that entity, i.e. is a property of that entity, > > then why could we not want to say how the entity came to have that > > behaviour as part of its provenance? If the entity has a property > > whose values can only range between X and Y, this is also an > > enduring truth whose provenance may be of interest. For example, if > > I say that the Royal Society can only have up to 1000 members at any > > one time, the history of > this truth is also expressible. > > Sounds like we're using property differently along the lines above. I > don't think there's any problem in talking about bobs for class > definitions and describing the process executions through which that > definition changed the acceptable range for properties of instances of > that class. What I don't want is a bob (say an IVP of the Royal > Society) with membership =100 and part of the conceptualization of > that bob in our model is some notion that I can define > era=pre-industrial if membership <100 and therefore query to "find the > provenance of any bobs that are IVPs of the Royal Society with > era=pre- industrial". I would say this requires a bob that is defined > in terms of an ID, properties, and some other rules/methods/etc. > Rather than expand the notion of bob, I'd like to say that you have to boil down what you're talking about to an ID+properties concept before it will fit in the provenance model. > If you want a recipe-style escape-hatch to have a property that points > to this extra richness that you could use out of band to turn the > query above into a query about a bob that is an IVPof the Royal > Society with membership <100, that's great. > > This is the point I was trying to make when talking about mapping from > other ontologies and is what I'm trying to distinguish when I talk > about the difference between a bob and the entity/instance of a class > in another ontology that it 'represents'. > > > > I take the general point that there could be something about > > instances which is irrelevant to provenance entities, but maybe this > > is a matter of what we include in our definition, not a difference in what they denote. > ~Yes, but I think there might be things that are relevant to > provenance that we also want to exclude, e.g. the computable > properties and the function to generate them in the example above. > Aside from that, I agree that when I say a bob represents something, I > am not trying to imply the same type of X is a description of Y idea > that gives one URI to an RDF document with metadata about a .doc file > at a second URI. I want the bob to be the something as far as the model is concerned. > > > > > > I think our use cases don't require anything but ID and > > > property/values (the > > 'content' as well if that's not a property), but, in analogy with > > the idea of process execution having a link to recipe, I could see > > reasons to have a link from the provenance thing/bob to the class > > type or full object > it represents. > > > > I do not have a problem with provenance thing being separate from > > "full object", though, as argued above, I'm not clear why we need that. > > > > I *do* have a problem with provenance thing "representing" something > > it can link to. Links are surely between representations, described > > using languages. Unless we are talking about a special kind of > > thing, which is representing something which is itself a > > representation, then asserting links between X and the > > representation of X does not make > sense to me. > > "Represent" is probably being overloaded and I'm willing to accept > whatever terminology makes sense. I agree that it would be silly if X > and representation of X were both in the model and you could link > them. What I'd like to see is the escape hatch to get out of the > model. Perhaps if bob IDs are always URLs, we already have the > mechanism to figure out whether that URL is a website, or the URL for > a physical object, etc. If this suffices though, I guess it might also > apply to the recipe link - if you want to know the recipe for a process execution, go ping the URL for it and get out of band info about it. > > > > > > Just like with recipe and the ability to compare what happened > > > with what > > was supposed to happen, being able to compare what is asserted about > > things with the knowledge about how those things are supposed to be > > constrained/behave would be very valuable as evidence and to assess > trust. > > > > Agreed, but as argued above, I can't see why constraint and > > behaviour are not properties. > > They are properties in your sense of the word, but not necessarily > things that can be reduced to key/value pairs associated with an ID > and put into the definition of a bob. Assuming that we agree there's > value in getting to aspects of an 'entity' that are not included in > our definition of bob, how do we talk about it (I just said entity in > this sentence - if that's not what we mean, what do I call it?), and > how would I go from having a bob to accessing those beyond-the-definition aspects (and what do I call that?). > > Cheers, > Jim
Received on Thursday, 14 July 2011 20:21:04 UTC