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

Re: simon:entity (or Identifiable)

From: Reza B'Far <reza.bfar@oracle.com>
Date: Fri, 15 Jul 2011 11:22:19 -0700
Message-ID: <4E20855B.5090407@oracle.com>
To: public-prov-wg@w3.org
Folks -

I realize that the "R" word has been banned and am fine with that.  Here is a 
suggestion for reconciliation of proposals/suggestions by Ryan, Jim(s), and Luc -

 1. That we specify that Identifier is some "base-line" temporally identified as
    zero point (there exist no entity to be identified before this point).
 2. That we have a new concept that encapsulates a single "state" (sorry, I know
    that's another dangerous word) of identifier from that point on.  I don't
    want to give it a name so I'll call it set S{}.
 3. An Identifier can have a DAG (Directed Acyclic Graph) of S{} nodes where the
    DAG has a single root node and that root node has equivalence with the
    identifier itself.

Just trying to reconcile at this point.

On 7/15/11 10:46 AM, Jim McCusker wrote:
> On Fri, Jul 15, 2011 at 12:06 PM, Myers, Jim<MYERSJ4@rpi.edu>  wrote:
>>> Being able to describe what the entity "looks like" at the time the
>>> provenance was recorded.
>>> My understanding was that a BOB was something like a named graph,
>> graph
>>> literal (http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-
>>> literals/),
>>> or information artifact similar to iao:Dataset. The Bob would then
>> have
>>> content that described, in some way, the entity in question.
>>> Hence the Bob being a description of an entity's state.
>> Do you distinguish 'description of an entity' from 'description of an
>> entity's state'? I get the sense that you are not using state in the
>> same sense of 'a more stateful view of' that is driving the discussion
>> of entity versus entity-state in the IVPof debates.
> Any description of an entity will occur with an entity in a particular
> state, and so two are the same.
>>> If it is possible to know, there should be assertions on the BOB
>> itself that say
>>> which entity the BOB is describing. Ideally, this is a URI of
>> something that's
>>> referenced within the BOB.
>> I'm hoping someone will chime in on this - I agree we need to connect
>> the idea of a bob with the entity, but I could see implementing that as
>> a link (as you say) or by saying that my entity's class is a subtype of
>> Bob (hence there's only one URL for the Bob and the entity).
> But that's clearly wrong, since Bobs only describe the state of an
> entity at one point/span of time and context. If the same entity is
> observed again, and a new Bob is created that describes the state
> differently, then there's nothing to tie it down. I'm guessing that by
> saying there is no referable entity outside of the Bob, then you can
> just make Bobs all the way down. But there would be no grounding to
> non-provenance resources in this case.
> The Bob is the description of something based on its state, the Entity
> is that something. A description of a thing is not the thing itself.
> Within the context of information systems, one can say that
> http://tw.rpi.edu/instances/JamesMcCusker is me. If you were to
> download the RDF from that URL that would contain a description of me
> within the context of RPI. The graph literal behind
> http://tw.rpi.edu/instances/JamesMcCusker is one description (that can
> change over time), and can be given an identifier using a graph digest
> [1], guaranteeing that we always talk about the same graph. But that
> graph is not me, even though the URI that returns it stands in for me
> in the semantic web.
> [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=
> Jim
> --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-6330
> http://krauthammerlab.med.yale.edu
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu
Received on Friday, 15 July 2011 22:08:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:06 UTC