- From: Reza B'Far <reza.bfar@oracle.com>
- Date: Thu, 14 Jul 2011 14:06:44 -0700
- To: public-prov-wg@w3.org
- Message-ID: <4E1F5A64.6010308@oracle.com>
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:07:33 UTC