- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 14 Jul 2011 22:53:00 +0100
- To: reza.bfar@oracle.com
- CC: public-prov-wg@w3.org
Reza, I don't know about minority, but I think something you said is very important to keep in mind: "However, if the group is saying that defining touch points to the tangent layers, per your own references, is also out of scope, then I warn that there is a fundamental problem for product implementers." IMO, it's crucial that we articulate those "tough points", even if we don't define any notion of agent subclassing _within_ the provenance model. #g -- Reza B'Far wrote: > Ok. At this point, I'm resigning to the fact that I'm in the > minority. However, just look at HTML as a data point: > > They could have made <p></p> and <div></div> tags into the same generic > tag with an attribute (or attributes). I would argue that they made the > right decision(s) in the strong types they created, though not all were > perfect decisions (e.g. <blink>). That "strongly encouraged" all the > implementers of browsers to define rendering of a paragraph in a > specific way (and different from <div) which is more loose). The core > issue is compatibility. If you make something generic and provide only > soft guidelines for extensions, you end up with compatibility issues > when product implementers build their products because they will do > whatever they can within the specification to differentiate their > products. Ignoring that fact risks success of a standard once implemented. > > But, I end with my original statement that I'll drop the topic. > > On 7/14/11 1:57 PM, Daniel Garijo wrote: >> Hi Reza, all, >> I agree with you in that subtyping is very important from an >> implementer persepctive. >> However I think that the model discussed in the model TF is supposed >> to be generic, >> and once we have it, the test cases TF can develop some profiles >> subtyping all the >> generic concepts, showing examples of how it would be extended in >> different domains. >> Thus, developers could use these profiles as reference for other >> extensions. >> Best, >> Daniel >> >> 2011/7/14 Reza B'Far <reza.bfar@oracle.com <mailto:reza.bfar@oracle.com>> >> >> I agree that it's the right thing to do to keep trust definition >> out of the scope of WG. However, if the group is saying that >> defining touch points to the tangent layers, per your own >> references, is also out of scope, then I warn that there is a >> fundamental problem for product implementers. If you want to >> exclude all aspects of trust including any think like the ability >> to embed something else via a URI or something like that to a >> trust mechanism, then you'll have compatibility issues from >> different product vendors. If you want to do that knowingly, it's >> fine and I'll drop the thread, but if you disagree and think that >> exclusion of trust doesn't cause fundamental incompatibility, we >> can continue thread and I can provide more details on why this is >> the case. >> >> So, my point from the beginning is that without subtyping, things >> are too generic to be able to import and export things about >> entities between different systems. And I believe a primary >> use-case for usage of the model is import/export between different >> implementations. >> >> >> >> On 7/14/11 12:35 PM, Satya Sahoo wrote: >>> Hi, >>> I agree with Yolanda that core of provenance should not include >>> trust, since in view trust is a function of provenance (computed >>> over provenance assertions). In a paper by Sizov et al. [1], >>> provenance is modeled as a layer between trust and proof layers >>> of the Semantic Web layer cake. >>> >>> Some comments on Reza's point: >>> > for the first version, we need something that the implementers >>> can provide that says "the person >creating this mod is not >>> trusted" or "the person creating this mod is trusted" at that >>> binary simplicity >level. >>> A follow up query would be (in context of provenance) - "why is >>> the person trusted or not trusted". Is it due to the algorithm >>> used to compute trust (there are several, e.g. [2] [3]) or is it >>> the provenance of the person or the provenance of the mod (which >>> provides the context for trust)? >>> In addition, how is the trust value in the above statement >>> represented - binary value, a plain text label, a term from a >>> trust vocabulary/ontology? >>> >>> Hence, I believe trust is not in scope of the WG. >>> >>> Best, >>> Satya >>> >>> [1] >>> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4397215&tag=1 >>> <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4397215&tag=1> >>> [2] H.Luo andJ.Tao and Y.Sun Entropy-BasedTrustManagementforData >>> Collection in Wireless Sensor Networks, Proceedings of WiCom ’09. >>> 5th International Conference on Wireless Communications, >>> Networking and Mobile Computing, page(s): 1-4, 2009. >>> [3] Y. Wang and M.P. Singh. Formal Trust Model for Multiagent >>> Systems. In Proceedings of the 20th International Joint >>> Conference on Artificial Intelligence (IJCAI-07). pp. 1551 - >>> 1556, 2007. >>> >>> On Thu, Jul 14, 2011 at 2:00 PM, Reza B'Far <reza.bfar@oracle.com >>> <mailto:reza.bfar@oracle.com>> wrote: >>> >>> Yolanda - >>> >>> Thank you for the response. Please see responses below - >>> >>> 1. You're completely correct that trust has shades of gray >>> (accuracy, preciseness, etc.). This is partly why I >>> also included the PACE reference. However, it should >>> be up to the implementer to determine trust. All we're >>> doing is providing some very coarse grain way to even >>> express existence or lack of trust. Perhaps we should >>> add to the two that I put in an "Unknown". At this >>> point, IMO, for the first version, we need something >>> that the implementers can provide that says "the person >>> creating this mod is not trusted" or "the person >>> creating this mod is trusted" at that binary simplicity >>> level. Later on, during future versions of the draft, >>> additional attributes can always be added. I'm even >>> find with doing that now... or creating a pointer to >>> other standards that deal with trust. But, not dealing >>> with it makes it so that the fact that an agent is >>> mentioned is not all that useful if I have to have >>> trust. And most, if not all, commercial applications >>> have to have trust. It's not an option. I can't go >>> republish some news from some random source that I >>> don't have any trust for or no one vouches for as a >>> reputable org (journalism use-case). Nor can I provide >>> records management lineage in time for some legal >>> evidence piece. >>> 2. I am fine with the proposal of completely removing >>> agent. I guess it's better than ONLY having a >>> "generic" agent. But I prefer specific agent(s) >>> 3. References from Fugetta, et. al, as well as >>> Russell\Norvig, Taylor/Dashofy, Medvidovich etc. where >>> Software Agents are definitively defined look at the >>> following categories - >>> * Mobile Agents - mobility context >>> * Intelligent Agents - automated processes that >>> make their own decisions without direct human >>> interaction >>> * User-Agent as defined in Http/HTML/etc. within >>> the context of client-server computing >>> 4. On (3) above, my "beef" here is that we need to use >>> words that have definitive meaning in software >>> engineering within their own context. System Agent is >>> typically used (and I previously sent a reference on >>> this) to refer to automated intelligent agent... some >>> cron job that's running in the background doing >>> automated stuff. User-Agent is defined by Fielding in >>> REST. >>> 5. Orthogonal to discussion - I generally don't like >>> something called "recipe" for example. I mean what is >>> a recipe? It's in my kitchen, but I don't find it in a >>> gang-of-four software engineering book or in anything >>> that I've seen in a graduate or undergraduate software >>> engineering book. Getting creative with words is >>> dangerous. And I don't think we're inventing anything >>> here in this (or any other) working group in the way of >>> a new theory, principle, etc. so I strongly recommend >>> we use exact words that are in either accepted and >>> semi-mature (few publications, not just 1 paper) or >>> fully mature computer science and/or software >>> engineering disciplines. >>> >>> Best. >>> >>> >>> On 7/14/11 10:40 AM, Yolanda Gil wrote: >>>> Hi Reza: >>>> >>>> You raise an interesting topic, albeit a tough one. >>>> >>>> Trust tends not to be binary, it comes in all shades of grey >>>> (e.g., a degree of confidence). >>>> >>>> It is also subjective, the level of trust may depend on the >>>> application, the domain, or the use of the provenance. >>>> >>>> So in my opinion, the core of a provenance representation >>>> should not include a representation of trust. Maybe later >>>> we include an extension to represent trust, but note that >>>> many trust metrics can be derived from a given provenance >>>> record. >>>> >>>> I am also not sure about your second category. I am not >>>> sure if the NYT as publisher of an article would be >>>> considered "user-agent" or "system". I am not sure if my >>>> personal email agent should be considered "system" or >>>> "user-agent". >>>> >>>> In general, I think ontologizing agency is tricky. >>>> >>>> In my opinion, the notion of agent should be eliminated from >>>> the model unless we want to attach a special meaning to a >>>> participant which is a meaning of responsibility for a >>>> step/process. >>>> >>>> Yolanda >>>> >>>> >>>> >>>> On Jul 14, 2011, at 10:18 AM, Reza B'Far wrote: >>>> >>>>> Creating new thread to put agent sub-typing up for discussion. >>>>> >>>>> Proposal is to have the following sub-types of agent >>>>> >>>>> 1. Trust-based sub-types >>>>> * Trusted Agent >>>>> * Untrusted Agent >>>>> 2. Limiting the scope of System vs. Human interaction >>>>> * User-Agent >>>>> >>>>> Alternative to 2, we could also do Automated System Agent >>>>> and Human Agent. >>>>> >>>>> Reza >>>> >>> >>
Received on Thursday, 14 July 2011 21:55:16 UTC