FW: the nature of a bob (was Re: Models and their use)

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