- From: Simon Miles <simon.miles@kcl.ac.uk>
- Date: Sat, 3 Sep 2011 15:40:20 +0100
- To: Provenance Working Group WG <public-prov-wg@w3.org>
Graham, Jim, Luc, In considering how the primer might be written, I greatly appreciate Graham's attempt to make explicit the intended meaning behind the model definitions. Graham - I think that the reason for the term 'entity' is that people, including me, continued to think we were defining concepts in a conceptual model (as with "resource" in RDF, "agent" in Dublin Core, "object" in UML...), not names of data model constructs, even though I know Luc has said we're defining the latter for a while. - As with you, I am concerned that the current model will be hard to grasp. For example, if I have a file at a given location, and think "what kind of thing would this be in PIL?", then I'd be stuck. It is not an entity, because it is not an assertion and I don't know if its a (characterised) thing, because that is not defined and not actually a concept in the model. At best, it is "a kind of stuff that entity is an assertion about". One way we could fix this is to have two definitions, i.e. Defn 1. An entity *is* an identifiable characterized thing. Defn 2. entity(id, [ attr: val, ...]) *is* an assertion that an entity, identified by id, existed and was characterized by the attributes [ attr: val, ...]. (and then include all the caveats that the attributes are chosen to form one perspective appropriate to the other assertions made about the entity, as I think Jim is arguing). The above can be seen like the difference between defining a "for loop" (concept) and a "for statement" (language construct). Jim - I'm see no difference between what you and Graham expressed, but I guess you want to ensure he didn't mean: a. "e0 is a file THAT HAPPENS AT THE MOMENT TO be at file system location is /shared/crime.txt and which have been created by Alice" b. "e0 is COMPLETELY DEFINED BY BEING (not just a perspective on) a file at /shared/crime.txt created by Alice" Right? - Your example of overwriting a file in a single location nicely illustrates nuances of the entity definition, and I guess we need something of this sort in the primer. Though we might have to explain things simply but not completely correctly before getting to accurate but challenging :-) - I find your definition of entity more opaque than the current one (sorry). What is an "asserted interpretation"? Thanks, Simon On 3 September 2011 14:36, Myers, Jim <MYERSJ4@rpi.edu> wrote: > Luc may have a different perspective, but I think your description of e0 may not capture what's needed: > >> entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ]) > >>might be interpreted as asserting that the thing denoted by "e0" is a file whose >>file system location is "/shared/crime.txt", and which was created by "Alice". > > e0 is a characterization of a file as a file-in-a-fixed-location - e0 is the file at location /shared/crime.txt. The thing - the file currently at /shared/crime.txt is ambiguously defined in terms of time and processing - if I swap new content to /shared/crime.txt - has the thing moved or has it changed in place. For e0, its clear - e0 can't move. I could also have an entity with fixed content (whatever is at /shared/crime.txt now) which would have moved (or an entity representing the file with fixed location and content that would have ended/been used by the swap PE). > > Is this consistent with your interpretation? (With Luc's?) To me an entity is an asserted interpretation of how a thing is scoped with respect to time/processing... > > The fact that a file was moved from location A to B can be asserted by asserting entities that characterize the movable file as file-in-location-A and file-in-location-B and asserting that file-in-location-B wasGeneratedBy a move PE that used file-in-location-A. > > (If useful, one can also characterize the mobile file as well (perhaps as file-with-fixed-content) and talk about its provenance as well (the series of edits that created it from other fixed-content-files ignoring how those files might have been moved around) and even link the descriptions (via IVPof/complementOf).) > > Jim > -- Dr Simon Miles Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166
Received on Saturday, 3 September 2011 14:41:00 UTC