Re: simon:entity (or Identifiable)

I'm catching up on this thread in one hit.  There are specific responses below, 
with email archive URIs for the messages to which they refer.

The overall thrust of my view is that:

(a) we want fewer classes, not more  (no separate classes for "bob", "state")
(b) a minimal model based on the relationships between entities rather than 
trying to fully ontologize the domain
(c) that "bob"s should be indentifiable, but not necessarily identified.


Details follow...

<http://www.w3.org/mid/B7376F3FB29F7E42A510EB5026D99EF2053FFF84@troy-be-ex2.win.rpi.edu>
MYERSJ4@...

Agree, not "levels".  I think all "bob"s are also "entities".  Need relation 
(property) rather than class to capture "bob"-ness.

All "entities", including "bob"s may have description.  Bob has some particular 
characteristics concerning invariance that make them suitable for provenance 
descriptions.

<http://www.w3.org/mid/CAAtgn=QYwC+1tC=OHxA3BJt-8izFSC-Z83dGAdiqpFw6pJ3Z+Q@mail.gmail.com>
mccusj@...

Disagree that "bob" is something like a named graph.  Just an entity in IVP 
relation to another entity.

Re: "Do you distinguish 'description of an entity' from 'description of an 
entity's state'?"  No.  At this level, "entity state" doesn't appear (or, if you 
prefer, is just another entity).  The notion of "state" is helpful for 
explaining REST/Web architecture in general, where (IMO) it is a hidden 
abstraction that underpins the "representation" that is transferred when 
dereferencing a resource URI, but serves to add confusion in discussion of 
provenance.

My mental model looks something like this:

    Entity(bob) --hasDescription--> Description;   (may be provenance related to 
Entity)
      |
      v isIVPof     (may be reflexive to the extent that Entity is static)
      |
    Entity(orig) ---hasDescription--> Description

When accessing provenance, what we transfer (in terms of web architecture) is a 
representation of the state of the description


<http://www.w3.org/mid/B7376F3FB29F7E42A510EB5026D99EF2040413F4@troy-be-ex2.win.rpi.edu>
MYERSJ4@...

I think the problem is that by defining separate terms/concepts, rather than the 
relationships that matter for provenance, we end up trying to mpin down too much 
detail that really doesn't matter, and concerning which there is scope for 
disagreement.  I try to push for saying as little as possible, but it seems to 
me that such minimal definition is only possible in terms of a simple E-R style 
(or DL-style) description of a suite of relevant concepts.  I think this may be 
what you allude to in mentioning "Graham making a comment [...] more about the 
purpose of the model"

So, I don't think hierarchy has a place in out discussions.  To the extent it 
exists, it is incidental, and should not be a constraint.

RDF describes generic E-R models, so I think discussing models or RDF 
implementation should be fairly isomorphic.


<http://www.w3.org/mid/4E21319B.50002@oracle.com>
reza.bfar@...

I think we reached our present confused position precisely by trying to make 
"state" an explicit part of the model, which it is not obviously the case in all 
situations, so we tried to capture the essence of invariant aspects of something 
described by provenence by ither means (enter "IVP", "bob", etc.).

I agree about the lack of hierarchy.

In scenarios like you describe, I see the various modifications you mention each 
as entities in their own right, each of which might be an "IVP" of an Entity 
that represents the contract through its lifetime.  So in scenarios like this 
where there is a clear "state", these can still be described.  My question for 
you would be: is there anything about this entity-only model that fails to 
capture something that you need to be explicitly represented?


<http://www.w3.org/mid/4E2153D5.3010302@oracle.com>
ryan.golden@...

'"What can be identified"--whether it is stuff, stuff states, or something 
else--is not something our model may prescribe. '

+1

:)


<http://www.w3.org/mid/4E217083.2050006@cs.man.ac.uk>
Khalid.Belhajjame@...

"This raises the following question: Do we need to (uniquely) identify Bobs?"

IMO, not necessarily.  But it must be *possible* to uniquely identify them when 
needed.

By which I mean that it is not necessary to have an assigned identifier to serve 
the purpose of being a "bob", but we might need to be able to assign such an 
identifier in order to create some forms of provenance description.  I'm rather 
punting the details of identification mechanism to the implementation:  we could 
just say "use URIs", but it may be that in some circumstances it's easier to use 
RDF constructs involving blank nodes and (say) inverse functional properties, or 
other forms of "definite description".  So I think it's enough to say "can be 
identified" for now.

I think you agree with something similar in 
<http://www.w3.org/mid/4E21919E.40207@cs.man.ac.uk>


<http://www.w3.org/mid/B7376F3FB29F7E42A510EB5026D99EF2040413F6@troy-be-ex2.win.rpi.edu>
MYERSJ4@...

Allowing the use-case:  "I think it argues for uniquely identifying Bobs."

Following from (or repeating) the previous point, I disagree.  I think it's 
enough that it is *possible* to uniquely identify "bob"s, not that we have to do it.



#g
--

Received on Thursday, 21 July 2011 12:03:48 UTC