cmn: for each, determine if stable. if it has
wide implementation it is likely stable.
... don't need to say anything about the property or class itself - add owl
constraints and use rdf:seealso to point to it.

<chaals> cmn: where we find something that
we have created is the same as something else, we should say so, but we
should avoid doing it if possible

saz: need to discuss at some point. plan to
send requirements draft in next week.
... considering minimum earl (for interoperability).
... tool that outputs earl doesn't necessarily need to know owl. but tools
that validate earl, will need to. be careful to ensure we're using things
that are supported by parsers/tools.

cmn: let's keep looking. write requirements for
vocabulary and include in requirements doc.
... have other things to do first, so can put off for a while. if finish
everything else, then fill the gap w/our own.

saz: it's not essential now. may be other ways
to identify a tool.

<JibberJim> I can take it if needed, but
I'm quite busy if it's not urgent

saz: i'll follow-up with sandor to see if he
wants to do more searching.
... while foaf is widely spread, libby said that only 1 entity was fully
tested. others are not stable. don't want to take foaf as a given and at a
later stage discover can't depend on.
... will continue discussions with libby, but will need to consider again.
"foaf ornot to foaf"

(Continued) Proposed Changes to the EARL Schema

<Zakim> chaals, you wanted to say yes to
dc:description, no to earl:precision as currently modelled... should use
datatypes or (as a last resort) the class model DanC calls curried

cmn: yes to dc:description, no to
earl:precision as currently modelled... should use datatypes or (as a last
resort) the class model DanC calls curried something
... either be similar to TestResult (datatype for non-literal) or ...
... confidence isn't clear how it works, therefore not a great idea to add
another property that describes something we don't understand yet.
... confidence is (likely going to be) one property that could be refined by
datatype or by a collection of possible values.

saz: how to use confidence and/or precision?
how is it derived? currently, open and arbitrary.
... what are the use cases? one is a tool that knows heuristics. perhaps
create requirements from that.

<Zakim> chaals, you wanted to agree and
suggest that this is why we shouldn't make a second property that is
currently arbitrary

cmn: agree and suggest that this is why we
shouldn't make a second property that is currently arbitrary

cmn: yes. however, maintain confidence for now
since several people had use cases for confidence info.

saz: could wcag checkpoints be marked as
auto/human test?

wac: tests certainly, but not
checkpoints/success criteria since usually a combo of the 2. not sure how
useful hi/med/low confidence levels be for tests since writing them for hi
confidence on all. i.e., writing to be unambiguous, therefore we should have
hi confidence that if people are knowledgeable they are going to get a good
answer.

saz: hi/med/low is nice and simple. a scheme of
how to flag test results would interoperable.

<Zakim> chaals, you wanted to say it is
simple, but has no obvious interoperability beyond trivial case (100% or 0%
confidence

cmn: it is simple, but has no obvious
interoperability beyond trivial case (100% or 0% confidence)
... we're likely solving problems that we don't have.

saz: confidence in test description not
result.

<Zakim> wendy, you wanted to say confidence
is in the evaluator or the test and less on the result

wac: confidence is in the evaluator or the test
and less on the result

jl: confidence is something consumers have
about a tester rather than a particular test

<chaals> [the value in confidence is that
there are examples where it is useful, just that particular confidence levels
are beyond our current ability to describe usefully]