W3C home > Mailing lists > Public > public-wai-ert@w3.org > March 2007

RE: Editor's draft comments

From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Date: Wed, 14 Mar 2007 13:28:17 +0100
Message-ID: <09700B613C4DD84FA9F2FEA52188281901E7E2F0@ayalga.fundacionctic.org>
To: "Shadi Abou-Zahra" <shadi@w3.org>
Cc: <public-wai-ert@w3.org>

Hi again,

> >> So let's say a Single Assertor class refers to a 
> foaf:Organisation. 
> >> No Compound Assertor anywhere. What testing mode would you use?
> > 
> > If we think that an Organisation is a compound Assertor and that it 
> > may also include Software (I'm not in favour of the last 
> one) could be 
> > also manual, heuristic or mixed, otherwise it could be just 
> manual or 
> > heuristic (see next for explanations)
> I think you are mixing up how single/compound assertors were 
> defined. A Single Assertor is a single entity. This could be 
> a group of /things/ (as defined by foaf:Group) or a whole 
> organisation (as defined by foaf). 
> In other words, a Single Assertor does not have to be one 
> single tool or one single person but rather one single *entity*.

Ok, now I catch the "single entity" thing. I think this is a key question to really understand what a Single Assertor is and I'm not sure if it's clear, maybe some emphasis on the "single entity" could help.

> > My point of view so far is:
> > 
> > * Manual: Can be single or compound,
> > 
> > Single --> just Persons and/or Organizations.
> > Compound --> main: Persons and/or Organizations; secondary: whatever
> > 
> > Problems --> Compound assertor without mainAssertor: a 
> group of volunteers that carried out a test throught an NGO 
> website, who's the mainAssertor?
> Since all volunteers contributed equally, they are all mainAssertors.
> [...]
> Again, they could be all mainAssertors if there is no "leader tool".

OK, was quite simple. Got it.
> > * Semiauto: Can be only compound by definition,
> > 
> > main Assertor --> Software
> > secondary Assertor --> at least one Person and/or Organization, 
> > whatever else
> Wrong assumption, it *should* be compound. However, the user 
> behind a semi-automated tool may not be disclosed in the 
> report. The tool could be a Single Assertor but the mode of 
> testing was semi-automatic.

So the idea is that I know that a tool has the main responsability and I know that there's some human/s behind with a secundary role, but I may have no detail about the human/s behind, isn't it.
> > * Mixed: Can be only compound (and must include Persons, or 
> > Organizations, AND Software),
> > 
> > main Assertor --> whatever;
> > secondary Assertor --> whatever
> > 
> > Problems --> If there is no detailed information by 
> definition, how could I know who or what is the mainAssertor?
> As discussed above, mixed does not imply a Compound Assertor. 
> A Single Assertor could (by definition) be a whole 
> organisation as one single entity. How this single entity 
> carried out the testing is actually a separate question.

A mixed result implies a combination of persons AND tools, so just an Organization assertor can't give way to a mixed result unless the general thinking is that an Organization Assertor could also implicitly include Software tools, is this the general thinking?

> > * Heuristic: ¿¿¿???
> > 
> > single or compound but just Software?
> > single or compound with whatever main and secondary Assertors?
> Let your imagination fly! For example a tool takes input from 
> humans and "guesses" new result. This *could* be described by 
> using the compound class with the tool as the main assertor, 
> and the humanoids as the help assertors. This is one of many 
> possibilities and scenarios.

OK, this is a completely open scenario.

> > Note that the problems mainly come from the requirement of a 
> > mainAssertor for compound Assertors, but we need the mainAssertor 
> > distinction for manual and semiauto modes
> I think the problem comes from tying the test mode too 
> closely with the assertor. Of course they are related but not 
> married. The test mode is actually there to help clarify what 
> the assertor did, this is not always apparent from the mere 
> structure of the assertor class.

Make sense, nevertheless I think that, with the exception of the heuristic mode, there are certain rules that restrict the correct usage of Assertors/results combinations. (e.g the main Assertor in a semiauto result can't be a Person, etc.)

> > * Additional question:
> > 
> > - Should we define Organization as a type of Compound 
> Assertor not as a single one? After all, an Organization is a 
> group of people and other resources (software included?), isn't it?
> It is a *single entity*. Do you have suggestions on how I can 
> improve the wording to clarify this meaning?

It's allways hard to explain what an entity is, what about "that which is perceived or known or inferred to have its own distinct existence (living or nonliving)" ;o)
Now seriously, I don't have any great idea apart from the emphasis and/or maybe same examples next, something like "(e.g. Person, Organization, etc.)"
> >> Then we should also move Assertor to 2.1.2, Test Subject to 
> >> 2.1.3 and so on. There is no difference between earl:Assertor 
> >> and earl:TestMode when it comes to the schema.
> > 
> > Maybe we should, and then we'll transmit a clear idea of 
> the hierarchy in EARL with just the Table of contents.
> > There's also no difference between earl:TestResult and 
> earl:Outcome when it comes to the schema nor between 
> earl:Single/CompoundAssertor and earl:Assertor, but they are 
> sub-sections. Additionally I'm not talking about the schema 
> now, I'm talking about the document hierarchy.
> > 
> > IMO the most important think is to be consistent (and so, 
> easy to predict) following always a previously established 
> criterion. Some random criteria that could make sense are:
> > 
> > - Use always a section per Class
> > - Use subsections just for sub-classes
> > - Use subsections to reflect EARL hyerarchy
> > ...
> > 
> > I think we're not currently following any of the previous, 
> are we following any other?
> > Maybe it's not the most important thing right know, so I 
> can live with it as is, but I think it may be a good 
> improvement if we think as EARL "outsiders"
> This is editorial preference and shouldn't stop us from 
> moving to Last Call

I think in this case is not just a question of editorial preference. The selection of what criteria is going to be followed is just a question of editorial preference, but the selection of al least one common criterion to follow is a question of consistency, not just editorial preference.



Carlos Iglesias

Fundación CTIC
Parque Científico-Tecnológico de Gijón
33203 - Gijón, Asturias, España

teléfono: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org
Received on Wednesday, 14 March 2007 12:28:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:55 UTC