See also: IRC log
SAZ: where does the ruleset fit - in evidence,
or as part of the test case?
... Jibberjim proposed some stuff, using OWL
... posted some example reports using what jibberjim proposed
<shadi> http://www.w3.org/WAI/ER/EWT/resources/report-1.earl
<shadi> http://www.w3.org/WAI/ER/EWT/resources/report-2.earl
<shadi> http://www.w3.org/WAI/ER/EWT/resources/report-3.earl
<shadi> http://www.w3.org/WAI/ER/EWT/resources/report-1.earl#cp1.1
SAZ: I am moving to Vienna, working for W3C
JK: Work at FIT
Sander: Work in Linz
CarlosI: work at CTIC
JibberJim: Does no real work anyway.
Chaals: works at Opera. Also works with Sidar, on Hera.
CV: Works at FIT, hosts the meeting, have a nice tool.
SAZ: Proposal to have test case described in your own namespace, with evidence, and map that using e.g. owl:sameAs to a well-known checkpoint
<shadi> http://www.w3.org/WAI/ER/EWT/resources/report-3.earl#priority-1
SAZ: Chaals -- you propsed ruleset - whast do you think?
Chaals: I think there are two problems with it. The first is that it requires a description of a test case, and how to do that is going beyond our charter, and complicating things. On top of that, there is a risk that people will mess up the equivalence statements, and that will mess up the data - this proposal seems to me to make that more likely.
SAZ: Don't think that there is a description of
testcase required
... Can we re-use the ruleset somewhere else?
CV: We ahve a ruleset description in our test
case language. You can have different rulesets for the same requirement.
... don't know whether this should be part of EARL or a seperate entity.
Chaals: As I understand the proposals, mine is different since it points to the ruleset, Jim's leaves it out and assumes it is in the testcase
CV: Need to deal with rulesets to standardise them.
SAZ: My concern with ruleset property is that
either we don't define anything - not sure how useful that will be since no
interop
... might be a good thing - we can refine it later
... let's first check what the use case is.
<JibberJim> CMN: We don't need a standard ruleset desc. language, it would be good if we did, but we don't need one, but one will come, so we should be flexible.
<JibberJim> CMN: we don't want to prematurely standardise on OWL or something
<JibberJim> CMN: we do need a pointer to the rules.
<JibberJim> CMN: if people are just pointing to an rdf:resource
<JibberJim> SAZ: What's the difference between a ruleset for an atomic assertion and a compound assertion.
<JibberJim> SAZ: the difference is WCAG level A and a ruleset that describes your level A.
<JibberJim> oops, previosu was CMN
Jim: If the evidence is in the ruleset and
everyone is using a common identifier, it is easier to query without
trusting.
... if you have a common test-case URI then you are in the problem of needing
a real trust mechanism straight away.
... Agree that requiring the testcases to differ makes parsing harder.
... querying over collections is hard
SAZ: So either in the assertion we have two properties - one for common identifier, ne for how we did it, or within the testcase we have a pointer to the common testcase.
Jim: Inside the testcase is neater, but it is more complicated for non-RDF people.
SAZ: Chaals, what do you think about moving ruleset out of evidence
Chaals: Think it is a bad idea, but can live with it.
Jim: having two identifiers - common test case
and test case used is useful. Like the idea of a tool-level test case, rather
than burying that inside the result.
... a ruleset pointer is useful even without the evidence
SAZ: So that would be test case being common, and the ruleset pointing to the rules used, and maybe other assertions, but not required.
Jim: If you test two different pages you point
to two sets of evidence. You wouldn't be able to recognise that they were the
same method. A local testcase gives us the methodology.
... otherwise we have to base the methodology on the particular tool.
Chaals: So evidence could ahve a ruleset, a list of assertions, or both.
jim: is ruleset made up of assertions that are page by page, or general for any pages?
Chaals: ruleset is the methodology - applies to different pages. But you can also look at the assertions that were used according to that ruelset, and apply a different ruleset
Jim: So you need a rules language, not just OWL
Chaals: That would be better, but you can do a bunch of stuff with OWL
SAZ: So you have a testcase - common URI, the references to assertions, and the set of rules/methodology used to determine that something conformed to the commonly understood testcase.
Jim: Does evidence just point to assertions? Are you happy with rules not being in the evidence?
Chaals: Think that assertions can carry all the evidence that you can rely on.
CV: We might not be keen to publish the description of our test cases - we tell our customers but when someone is claiming based on our tool not all the information can be published.
SAZ: Also, some vendors might not be willing to publish all their information
CV: Right - think that not everyone is going to be prepared to publish all their information
Chaals: Right - I don't think any of this
should eb required, but it is useeful to be able to point to the rules
used.
... this makes the minimal query "find things that claim WCAG-AA" easy, and
"find WCAG-AA according to some set of rules that I trust"
SAZ: Propose to have that in the assertion, instead of in the evidence.
Jim: I think evidence is clearer if it only has one kind of thing inside it
SAZ: It is basically references
Chaals: Would like to be able to make things a collection, so that it is more stable and reliable.
SAZ: So, we have a testcase which points to a common ID, we have a ruleset pointer, and we have evidence/references.
CV: testcase points to common? I don't think that is a good idea. What is common to people is a ruleset, and testcases are particular to each tool.
SAZ: idea is that we have a pointer to the common ruleset.
CV: Problem is that there are many testcases
for the same checkpoint
... what is common is the ruleset.
<JibberJim> chaals: There's a naming issue, the testcase property has been used to describe the basic commonly known thing like WCAG AAA
<JibberJim> SAZ: a pointer to the commonly known testCase, a pointer to the methodology, the local testcase
<JibberJim> SAZ: and we have references to other assertion that the result is based upon, all directly below Assertion.
SAZ: Pointer to the methodology used in the particular case, and a set of references. These would also be properties of the Assertion
CV: Spec is ambiguous right now on what testcase means
SAZ: Does the model work?
Chaals: OK, works for me.
Jim: WFM, but all of them should be optional
CI: WFM
Sandor: ruleset pointer will point to different things - how the internal testcase is built up (first order logic?) and the second is how to gain assertions from other assertions - aren't these two different things?
SAZ: Depends on the assertion. If I make an assertion of WCAG level-A, I take a set of assertions for checkpoints, and say "based on these checkpoint assertions I make this claim". Another claim is to have a collection of tests done for a specific checkpoint - the ruleset could be more complex, which depends on what you can assert in the the rule language.
Sandor: there could be a really powerful rules langauge.
Jim: We don't define that
CV: You can't leave it oout or you ask for trouble
Jim: You have an identifier. So you can tell the machine to trsut them or not even if it can't automatically interpret them.
chaals: better to leave it open for now, and see what emerges
CV: Don't say you need a complete set of rulesets - at least define the parts that are useful for accessibiltiy
SAZ: Can the rulset be described in a test desccription language?
Chaals: Well, if we leave it open, then there
is no problem. It can be a test case language, simple OWL, an image of a
document written in chinese
... think we should leave it open, but describe an example using OWL
JK: Think it is OK, but need to be clear about what the terms mean
CV: Right. We had interpreted it contrary to the apparently common understanding
SAZ: So we agree on the model. Questions - constraints, naming.
SAZ: My understanding is that this refers to the common identifier for a requirement, not the test cases used by a specific vendor.
CV: Think this is a major issue
Chaals: The idea is that you use the same query whether you are looking for conformance to WCAG triple-A, WCAG 1.1, A common testcase that is part of checking for 1.1, or a locally-specific test.
CV: testcase can't be WCAG triple-A.
CI: Know what CV means. Thinking about WCAG 1.1
- it isn't a testcase, it is a guideline.
... the test case is what the tool actually did to test conformance.
... e.g. WCAG 1.1 is not a testcase
CV: Applying this to software testing you have the same problem.
<JibberJim> chaals: updating hera isn't a problem, updating all reports that have been published before is a problem
<JibberJim> chaals: what we have used testCase for so far isn't that well described, we should just update the description to reflect better what we're using it for.
<JibberJim> chaals: if we think the names of URI's are meaningful we should make no more named URI's during Working Draft as it causes too much hassle
<JibberJim> chaals: RDF gives us identifiers that can be labeled with descriptions
<JibberJim> SAZ: thinking about names isn't fun
SAZ: URIs were created to have a name, not a
number
... DNS makes things human-readable
... Wondering if the solution isn't OWL. Looking at the spec, I don't see
that it is totally wrong. The text says that it describes a test case, and
gives a WCAG checkpoint as an example.
Chaals: The spec uses a bunch of examples, and in a working draft it is important to read the spec
CV: Yes, but we should use commonly used terminology
Chaals: Agree.... but we should not use URIs as if they are real descriptions.
SAZ: So what are the options?
Chaals: re-label the thing, or mint a non-meaningful URI
SAZ: There is no way to make conversions
without meaningful URIs
... we are plannig on releasing the thing under a new namespace when we go to
Rec
... imagine the name is earl:requirement
CV: Are we going to keep the nmg-strawman as the URI?
SAZ: We have decided we will only change the namespace at Recommendation - for working drafts we will maintain the same namespace, and where necessary make new terms in the same namespace
<JibberJim> End of Break
<JibberJim> SAZ: from the schema - A testcase is a test, usually one that can be either passed or failed
<JibberJim> SAZ: It could be pointing to a requirement - what belongs in a testCase, what belongs in a ruleSet
<JibberJim> CV: difference between How and What, test case e.g. wcag and how we tested.
<JibberJim> S: Markup validation is not atomic.
<JibberJim> chaals: use case is "find me things that pass", so we need identifiers for commonly known requirements
<JibberJim> SAZ: Does it make sense to have a subPropertyOf testcase that is a requirement
<JibberJim> SAZ: Is it possible to have an rdf:ID and rdf:about on the same ID.
<JibberJim> chaals: an assertion has an ID, but you would not want to say that a particular assertion is about a particular testCase.
<JibberJim> chaals: you'd need to use a seperate property
<JibberJim> SAZ: There isn't always a clear mapping of the requirement to the testcase
<JibberJim> CV: The requirement would be the specification, the test would be the validation method
<JibberJim> chaals: Different people test validation in different ways, the sum of the tests is the validation, but perhaps the atomic tests aren't the same - there's no magic 1-1ness
<JibberJim> chaals: test cases point to one to many tests that your tool does, but the validation is the result.
<JibberJim> SAZ: an interpretation of ruleset/methodology would be to describe the procedure of doing the case. what would be in testCase?
<JibberJim> chaals: an identifier to the requirement you're meeting, e.g. a WCAG identifier for each checkpoint/conformance level.
<JibberJim> chaals: If I use those identifiers anyone can check to see if we meet wcag level A
<JibberJim> chaals: If there's not a public identifier from e.g. wcag we find and use URI's that are easily shared.
<JibberJim> chaals: A local test may be a wholly private one, but the identifier would still be unique even if not generally useful
<JibberJim> CV: I think that's not a testCase, it's a requirement.
<JibberJim> SAZ: I agree, test case isn't a great name.
<JibberJim> chaals: Changing a URI is a bad idea
<JibberJim> chaals: When we change to rec it's acceptable.
<JibberJim> SAZ: we can Change the label now, and then when we change to Rec and change all URI's we can change it to something like earl:requirement.
<JibberJim> CV: Could it not be confusing for people?
<JibberJim> chaals: people need to get used to how RDF might work...
<JibberJim> SAZ: We can say earl:requirement is the same as earl:testCase in the working draft, only dropping testCase later so as to not confuse people?
<JibberJim> chaals: I can live with that
<JibberJim> chaals: which will force people to do owl:sameAs
<JibberJim> chaals: Or something similar
<JibberJim> Nick: there's a distinction between a testCase and a requirement.
<JibberJim> SAZ: we've "decided" to have the ruleSet from the evidence directly into the assertion, and in there is the methodology - the how we tested a requirement
<JibberJim> SAZ: so testcase was confusing for e.g. wcag and we're looking to move to change the label to a requirement
<JibberJim> Nick: in acc-valet a testcase is a small atomic test distinct from a WCAG checkpoint
<JibberJim> chaals: We've seperated out methodology and tests.
<JibberJim> SAZ: earl:requirement or testRequirment?
<JibberJim> SAZ: drop testCase when we move to Rec, going to earl:requirement for property and earl:TestRequirement for the class
RESOLUTION: declare that earl:testCase is sameAs earl:requirement and earl:Testcase is sameAs earl:TestRequirement
<JibberJim> SAZ: ruleSet / methodology is now also needed
<JibberJim> chaals: we don't need a class, we just need a pointer to some sort of methodology
<JibberJim> SAZ: right
<JibberJim> chaals: not pointing to unknown things shoots us in the feet
<JibberJim> CV: we should have something in the methodology more than just any resource
<JibberJim> CV: something to actually describe the methodology
<JibberJim> chaals: requirement points to the thing we're actually testing
<JibberJim> SAZ: ruleSet thingy is just a stub that could point to anything
<JibberJim> Jim: I think ruleSet is a bad name, but a stub is fine
<JibberJim> SAZ: yes, just a stub that points to methodology
<JibberJim> chaals: yes might as well call it methodology
<JibberJim> chaals: points to the process/rules you used which is described in some way
<JibberJim> SAZ: proposal is earl:methodology as the property
<JibberJim> CI: testSet?
<JibberJim> SAZ: could be any old methodology not just a set of tests
<JibberJim> SAZ: are they related assertions or subAssertions
<JibberJim> SAZ: what is the evidence clause
<JibberJim> chaals: Just a list of assertions
RESOLUTION: We have a property called methodology which points to the detailed process or rules you used, defined in some other vocabulary
<JibberJim> JL: they're just a list of related assertions, exactly how they are related is open, and depends on methodology etc.
<JibberJim> chaals: the use case for them is that you can track down the assertions and see if you can trust the same results etc.
<JibberJim> SAZ: apart from the name, are there any comments.
<JibberJim> JL: chaals wanted it to be a collection, I'm happier with it to be completely open.
<JibberJim> chaals: a Collection is the only way to limit the scope of the evidence.
<JibberJim> SAZ: If someone else comes along and annotates an assertion, that could be useful
<JibberJim> chaals: I think there's a use case for making that impossible.
<JibberJim> SAZ: I think we should leave the limiting of the what annotations to trust to the consuming tools
<JibberJim> chaals: I think there are use cases for both.
<JibberJim> SAZ: If I want to compare 2 assertions each with 16 sub assertions, the query becomes enormous
<JibberJim> chaals: If you know the length it's opener.
<JibberJim> chaals: you could say a set of evidence is a collection is not allowed, but we could also say if you have a collection you have to set the size to make querying linear
<JibberJim> SAZ: can you say something is an rdfs:Collection?
<JibberJim> chaals: I think so.
[foo rdfs:subClass Collection /me forgets which one it is]
<JibberJim> SAZ: We say it's a collection or not a collection.
<JibberJim> chaals, if it's a collection we should say that it has to have a collectionSize
<JibberJim> chaals: we could just write this into the spec.
<JibberJim> chaals: then decide what we put in the spec...
<JibberJim> SAZ: In the assertion we have an earl:evidence property with assertionList class with properties...
<JibberJim> JL: maybe have assertionList assertionClass ?
<JibberJim> chaals: would you need that as you can already see if it's an assertion or a class?
<JibberJim> JL: I see collection use case solved in the non RDF trust level, gpg signing etc.
<JibberJim> chaals: I see querying collections as an easier problem than trust
<JibberJim> JL: I can't query collections yet, I've implemented interopable trust mechanism...
<JibberJim> chaals: Do we want to explicitly stop collections?
<JibberJim> SAZ: No.
<JibberJim> chaals: I want to explicitly do it, can I rely on EARL or just badger other people to interop?
<scribe> ACTION: Chaals make proposal for schema to describe how to add a Collection as evidence [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action01]
<JibberJim> SAZ: you should have an action chaals to come up with something, and if it doesn't cause any problems it can be ok
<JibberJim> SAZ: We want the ability to describe evidence without collections
<JibberJim> SAZ: the name evidence?
<JibberJim> JL: good name
<JibberJim> SAZ: Is it not just related or references or ... ?
<JibberJim> chaals: for simply related stuff is it not just rdfs:seeAlso
<JibberJim> chaals: evidence is more stuff that's important to the result
<JibberJim> SAZ: scared of fixing names
<JibberJim> JL: I think evidence is general enough to not cause a problem
RESOLUTION: earl:evidence property points to a list of Assertions (class called AssertionList ?)
<JibberJim> SAZ: There was a proposal to support an institution aswell as a Person
<JibberJim> SAZ: foaf:Agent was a proposal, currently marked as unstable - How widely supported is it? How many current users?
<JibberJim> CV: Is foaf widely used in industry
<JibberJim> chaals: more industry uses of foaf than most other forms dc / rss 1 only other vocabs that might be more common
<JibberJim> SAZ: I share the concern that foaf is a risky thing to use
<JibberJim> SAZ: foaf:Person is very widely used.
<JibberJim> SAZ: Even if foaf disappeared we cover what is needed by requiring foaf:name and foaf:mbox
<JibberJim> SAZ: we could subClass foaf:Agent?
<JibberJim> Nick: don't see that helps?
<JibberJim> chaals: yes, foaf:Agent is made stable by usage, subClassing just makes it messy.
<JibberJim> SAZ: Do we create earl:Institution or something?
<JibberJim> JL: we need something equivalent to foaf:Agent even if not that itself, because that's the use case we need.
<JibberJim> chaals: we don't want to invent our own unless we know it's not the same as an existing one, as it just bakes in the idea of invent your own property, which isn't a great idea. Using another encourages other people to use it.
<JibberJim> SAZ: If we take up foaf:Agent we need to make an explicit flag that we have some concerns about the use.
<JibberJim> chaals: we could say there's not consensus, I'm very much in favour
<JibberJim> SAZ: I just want to clearly highlight that it doesn't have consensus, even more so on foaf:Agent than foaf:Person
<JibberJim> SAZ: we'll take up foaf:Agent as a possible assertor
<JibberJim> SAZ: but highlight by property our concerns
RESOLUTION: We'll use foaf:Agent. Editor's notes to say that FOAF terms will be reviewed one by one before recommendation to determine whether they are stable enough for use or whether we need to roll our own
<JibberJim> CI: If we use foaf:Agent we don't need to use foaf:Person, we can drop foaf:Person or software.
[true, but it is helpful to keep them in there... (and foaf:Organisation or whatever it is called)]
<JibberJim> JL: I think it's good to highlight in the spec that foaf:Person can be used to encourage tools to highlight if it was a Person or whatever.
<JibberJim> SAZ: Should we make earl:Software a subClass of foaf:Agent
<JibberJim> SAZ: there's foaf:Group which is a compound assertor
<JibberJim> SAZ: We could just use foaf for all of the Assertor
<JibberJim> SAZ: I would be hesitant to take all of it from foaf
<JibberJim> SAZ So Assertor could just be a foaf:Agent.
<JibberJim> SAZ: And we'll flag that we're looking at this and give danbri big hugs
<niq> action items on danbri building up:-)
so danbri, what's the stability of foaf:Agent, Organisation... ?
<JibberJim> SAZ: It makes sense to use what's there, but if it's not stable, then we'll have to roll our own.
<JibberJim> SAZ: now we'll break for lunch.
<danbri> hi folks. hope ok to pop in here. Just wanted to put it in the record that in my opinion (as a foaf spec editor) foaf:Agent is ready to go stable, and I plan that for the next rev of the spec. If you've any further comments re the definition + accompanying text, rdfweb-dev@vapours.rdfweb.org is the list to use.
<JibberJim> A spec editor, so we need to get Libby to say that too!
<JibberJim> and resolve to give Libby hugs too
<niq> this meeting has existential angst about foaf:agent
<shadi> danbri, we'll need foaf:agent and some of the sub-classes too
<danbri> (I'm asking Libby)
<danbri> [[ danbri: Libby, the ER WAI group are discussing foaf:Agent etc., wondering whether to use or roll their own. I said foaf:Agent should go stable in next revision, probably the others too. What you reckon? (type something I can paste into the #er irc log btw :-)
<danbri> libby: I think foaf:Agent is pretty stable now - perhaps we just need one round of email/meeting to confirm that ]]
<danbri> --from private IM
<ericP> heya danbri_
<niq> 'squiet, innit?
<JibberJim> Where are the logs?
<sandor> SA: next Location, Confidence and Testmode
<sandor> Chaals: CSS selector
<shadi> something like <earl:locator rdf:datatype="something">value</earl:locator>
<sandor> NK: expression of location and how they are distinct from each other is one problem, the other thing is how to describe changes
<sandor> Chaals: use rdf:datatype, can be any rdf:resource - make loose restrictions
<sandor> SAZ: different cats of pointers: XPath, etc. on the other side: CSS selectors (numerical values), textual descr., fuzzy ptr.
<sandor> SAZ: do the different ptrs work with the expressed mode?
<sandor> Jim: problem with datatypes, some parsers don't handle
<sandor> Chaals: we should recommend people to put as much information they can!
<sandor> Chaals: definition of datatypes: XPath, ... it's actually an URI
<sandor> Chaals: XPath Spec URI may be used as datatype, find out if anyone uses this already
<sandor> ACTION: look into datatypes for XPATH, XQuery, XPointer, CSS selector [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action02]
<sandor> JK: is CSS locator precise enough?
PROPOSED RESOLUTION: Ask the community if they have a datatype for anything that we plan to use, and go with the existing usage as feasible
<sandor> Chaals: don't need to define all possible ptr's, or point out their usefullness - just define a well-defined set
<sandor> SAZ: categorize types: (line number, cols, ...), text message (in a language), datatypes (Xpointer, fuzzy, ...)
<sandor> Chaals: natural language, (line nr, etc.), XPath, Xpointer and everthing else
<sandor> Chaals: Single location - anonym. node, with many different ptr's
<shadi> proposed analysis: we have three overall approaches:
<shadi> 1. line/col/offset numerical value types
<shadi> 2. plain text description in a natural language
<shadi> 3. XPoint/XPath/XQuery/Fuzzy/CSS Selector/... datatype type values
<niq> 4. representational locator
<sandor> NK: rep. locator: pointing not to the original document, but a normalized form of it, e.g. only the structure
<sandor> SAZ: actually a representation fuzzy
<sandor> NK: subclass of the three approaches
<niq> ACTION: hide [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action03]
<shadi> ACTION: nick dig up work on fuzzy pointers and normailzation, and propose solution to the group [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action04]
<shadi> possible approach for type #3 <earl:locator rdf:datatype="something">value</earl:locator>
<shadi> ACTION: jim write up proposal for "earl:snippet" locator type [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action05]
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2005Oct/0002.html
<sandor> NK: single locator can have range in it, if a certain type (XPath)
<sandor> SAZ: potential misuse: one compound used to describe more instances
<sandor> JK: consistent navigation, do we use multiple testsubjects or compound locator?
<niq> "designed by committee, used by nobudy":-)
<sandor> RESOLUTION: all the information that is tested has to be in the testsubject
<shadi> DECISION: earl:Location should not contain pointers to earl:TestSubject (or earl:WebContent) to avoid evil recursions
BH: updated markup validator to use templates. Interested in EARL and what the use case is
<JibberJim> what's a markup validator?
<shadi> saz: should we remove earl:confidence? does it introduce more ambiguity than advantages?
<shadi> nick: we use it, i think chris too
<shadi> jim: we can't ever 100% confidence, even for objective tests (e.g. validator could have a bug, as opposed to a resource being invalid)
<niq> saz: confidence--
<niq> nrk: confidence++
<niq> nrk: we need to be able to distinguish between "probable pass" and "probable fail" when there is uncertainty
<niq> cmn: <confidence datatype="foo">value</>
saz: Could we deal with the use cases by subclassing cannotTell?
nrk: would be reluctant to drop the confidence I use now.
<niq> cmn: use confidence in statistical analysis
<niq> nrk: confidence helps with sampling from an automated analysis into a manageable amount of manual testing
<niq> jl:probable pass is meaningless
<niq> jl:probable pass is meaningless in at
<niq> jl:probable pass is meaningless in atomic tests
<Zakim> chaals, you wanted to say that probablyPass / ProbablyFail excludes interoperability except based on methodology...
<niq> RESOLUTION: confidence to have values defined by the implementation
<niq> saz: does testmode still have a role?
<niq> cmn: maybe. It's a convenient means of expression
<niq> jl: needs both assertor and methodology to render testmode redundant
<niq> saz: take it out
<niq> cmn: keep it in
<niq> jl: make it optional
<niq> RESOLUTION: keep it but make it optional; saz to deliver minority report
<niq> nrk: as with confidence values, we need different vocabularies to express different levels of reporting; eg technical detail vs executive summary
<niq> ci, saz: this has become messy. organisation is political; mixed mode is meaningless without further detail; auto vs manual is insufficient without mixed mode
<niq> ci: mixed mode as such is too meaningless
RESOLUTION: Add earl:mixed as a testmode
<scribe> ACTION: CarlosI check the wording and scream if it isn't clear enough [recorded in http://www.w3.org/2005/10/17-er-minutes.html#action06]
<niq> ci: role of earl:report?
<niq> saz: this is a nice general-purpose wrapper
<carlos__> URL for resources set: http://www.wabcluster.org/uwem05/uwem_0_5.xhtml
<shadi> rssagent, make minutes