- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Tue, 06 Sep 2011 11:09:39 +0100
- To: Graham Klyne <GK@ninebynine.org>
- CC: public-prov-wg@w3.org
Hi Graham, If i recall correctly, you commented on "represents", and this was replaced by "is representation of". I am not trying to play with words here, I genuinely feel that for people working in knowledge representation/data modelling, constructing representations of the world is a well understood notion. So, I don't see this word as problematic in this context if - it is used only with this meaning - is introduced up front to mean this. Now assuming that this still does not satisfy you, the choice of 'assertion' is problematic. Because sometimes, entities (or process executions or agents) are not asserted but inferred. It would really feel strange to write that an assertion is inferred ... Cheers, Luc On 06/09/11 06:42, Graham Klyne wrote: > Luc, > > I mentioned previously that "representation" is an imprecise word with > different possible interpretations. I don't think this is a good > choice of focus for your model description. > > Better, I think, would be to focus on "assertions" about the world, > especially in light of your point 2 below. To say that a > "representation" can be "asserted" doesn't make sense to me. > > ... > > Apart from that, then talking about data model constructs seems a > reasonable way to go. In a different message, I said that I thought > the treatment of the abstract syntax wan not helping. Reflecting > further on this, I see two ways to go: > > (1) drop the abstract syntax entirely, and build a model around RDF > abstract syntax (i.e. binary predicates, with named graphs for accounts) > > or > > (2) put the provenance abstract syntax at the heart of the model > document, and effectively make it all about defining the abstract > syntax. Describe everything in terms of PASN constructs, and focus on > explaining the meaning of those constructs. Don't relegate it to an > appendix. > > I suspect the latter is closer to the direction you would prefer to > take :) > > #g > -- > > > If you are going to > > On 05/09/2011 22:22, Luc Moreau wrote: >> Hi Graham, >> >> Actually, this whole thread of discussion, and separate emails with >> Paolo, >> make me think that it's more appropriate: >> >> 1. To present the data model as a representation of the world. >> Hence, an entity is a *representation* of an identifiable >> characterized thing, >> or a process execution is a *representation* of an activity. >> >> >> 2. To explain that representations of the world can be asserted by >> asserters, >> and what this means in terms >> of existence of stuff in the world (from the asserter's viewpoint). >> Note that the model also allows for some of the representations to be >> inferred >> (as opposed to asserted). >> For instance, agents can be inferred or asserted. >> >> Hence, for uniformity, I think it's more appropriate to talk about >> constructs of >> a data model. >> Where it is clear that a construct can only be asserted, then, use >> the term >> assertion. >> >> Further comment interleaved. >> >> On 05/09/11 21:36, Graham Klyne wrote: >>> Luc, >>> >>> I think it's better, but: >>> (a) I still think the term "Entity" doesn't quite reflect what is being >>> defined, and >>> (b) I still think the first sentence doesn't really tackle what an >>> Entity >>> [Assertion] actually *is* - your more oblique approach via >>> "representation" >>> leaves me, as a reader, guessing at what it is you really mean to >>> convey. >>> >>> I still think that starting out with something like: >>> >>> "A (BOB) is an assertion about an identifiable characterized thing" >>> (if you'll >>> excuse the resurrection of "BOB" here) gets the key information in >>> front of >>> the reader in a way that is less easily overlooked. Subsequent text can >>> explain in more detail, as you do, the details of what this actually >>> means. >> >> I think this is very misleading. A Bob (hey, long time no see!) is >> not an >> arbitrary assertion *ABOUT* an identifiable characterized thing. >> In fact, when you assert a Bob, you assert the *existence* of an >> identifiable >> characterized thing (... with attributes ... over ... interval, etc). >> >> Cheers, >> Luc >> >> >>> >>> #g >>> -- >>> >>> >>> On 05/09/2011 15:53, Luc Moreau wrote: >>>> Hi Graham, Jim, and Simon, >>>> >>>> Following the discussion this WE, Paolo and I have revised the >>>> definition of >>>> entity. >>>> Before editing the document, we would like to get your feedback. >>>> >>>> General assumption (to appear in section 4): in the real world, we >>>> find: >>>> - identifiable characterized things, their situation in the world >>>> - activities >>>> - events >>>> >>>> Cheers, >>>> Luc >>>> >>>> >>>> >>>> ----- >>>> Revised section 5.1 >>>> ------- >>>> >>>> >>>> In PIDM, an entity construct is a representation of an identifiable >>>> characterized thing. >>>> >>>> An instance of an entity construct, expressed as entity(id, [ attr: >>>> val, ...]) in the Provenance Abstract Syntax Notation: >>>> - contains an identifier id, denoting a characterized thing >>>> - contains a set of attribute-value pairs [ attr: val, ...], >>>> representing >>>> this characterized thing's situation in the world. >>>> >>>> The assertion of an instance of an entity construct , entity(id, [ >>>> attr: val, >>>> ...]), states, from a given asserter's viewpoint, the existence of an >>>> identifiable characterized thing, whose situation in the world is >>>> represented by >>>> the attribute-value pairs, which remain unchanged during a >>>> characterization >>>> interval, i.e. a continuous interval between two events in the >>>> world (which may >>>> collapse into a single instant). >>>> >>>> Example: <same example> >>>> ... states the existence of a thing of type File and location >>>> /shared/crime.txt, >>>> and creator alice, denoted by identifier e0, during some >>>> characterization >>>> interval. >>>> >>>> Further properties: >>>> - If an asserter wishes to characterize a thing with same >>>> attribute-value pairs >>>> over several intervals, then they are required to assert multiple >>>> entity >>>> assertions, each with its own identifier. >>>> >>>> - There is no assumption that the set of attributes is complete and >>>> that the >>>> attributes are independent/orthogonal of each other. >>>> >>>> Cheers, >>>> Luc >>>> >>>> >>>> On 09/01/2011 05:32 PM, Provenance Working Group Issue Tracker wrote: >>>>> PROV-ISSUE-85 (What-is-Entity): Definition of Entity is confusing, >>>>> maybe >>>>> over-complex [Conceptual Model] >>>>> >>>>> http://www.w3.org/2011/prov/track/issues/85 >>>>> >>>>> Raised by: Graham Klyne >>>>> On product: Conceptual Model >>>>> >>>>> See also: >>>>> http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0383.html >>>>> >>>>> Section 5.1. >>>>> >>>>> The definition of "Entity" seems to introduce un-needed >>>>> complications. I don't >>>>> see anything here that fundamentally distinguishes an entity from >>>>> anything >>>>> that can be named, i.e. a web resource. >>>>> >>>>> I don't see what useful purpose is served by the insistence on >>>>> "characterized >>>>> thing". >>>>> >>>>> This section seems to spend more effort describing "entity >>>>> assertion" is is >>>>> apparently a different concept, but not formally part of the >>>>> model. There is >>>>> some sense that an entity must have associated entity >>>>> assertions... but I >>>>> can't see why this is needed, and indeed it may be not possible to >>>>> enforce >>>>> this idea in RDF's open world model. >>>>> >>>>> There's been talk of Entities being part of the occurrent vs >>>>> continuant >>>>> distinction, but I'm not seeing that explained. >>>>> >>>>> Suggest: why not just have an entity as an identifiable thing, and >>>>> build the >>>>> rest around that? What would break with this approach? >>>>> >>>>> >>>>> >>>> >>
Received on Tuesday, 6 September 2011 10:10:23 UTC