ERT WG -- 24 May 2005

Referencing External Vocabulary in EARL

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0031.html

saz: outlines possibilties in uri above

cmn's response: http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0036.html

cmn: we shouldn't add things we don't need.

saz responds, concern about stability - http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0037.html

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: 3 points for discussion - 1. foaf stability 2. referencing external vocabulary (e.g., dc:date) 3. owl constraints to select a person or tool as an assertor

<shadi> <rdfs:label xml:lang="en">Assertor</rdfs:label>

<shadi> <rdfs:comment xml:lang="en">Person or Tool that claims assertions</rdfs:comment>

saz: this is a way of referencing a foaf:person as an assertor
... avoid duplicating 'person' directly use person

cmn: good idea

jl: we should use foaf:person

saz: reuse whatever is defined in dc.

<Zakim> chaals, you wanted to say bad idea

cmn: if we're creating something that's the same as something else, why not just use the something else?

saz: how do we formalize?

cmn: 1st e.g., formalizes nicely.
... either foaf:person or a tool
... tools must have a dc:title

saz: need to dig into owl to determine how to express something like that.

<JibberJim> No, just agree with him, very noisy here

<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html

<chaals> ACTION: chaals dig out how to require some non-earl property in the earl spec, using OWL [recorded in http://www.w3.org/2005/05/24-er-minutes.html#action01]

cmn: refers to email http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0041.html
... conformance to earl spec

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.

Identifying Assertors of Type "Tool"

saz: sandor sent about doap - http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0032.html
... not stable and not widely distributed.
... either define own versioning, or follow owl and dc path - provide hooks for specific domains to develop own versioning OR continue searching for something.

<Zakim> chaals, you wanted to say let's keep looking

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

saz: don't want to get into too deeply w/out rest of the group.

<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html#prop-result

saz: new property - precision

<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

<chaals> ACTION: chaals to find paper on modelling probability in RDF as an example of better approach. [recorded in http://www.w3.org/2005/05/24-er-minutes.html#action02]

cmn: agree that interoperability is the issue.
... SWBPIG has published something about datatypes and n-ary relations that may be useful.

http://www.w3.org/TR/swbp-n-aryRelations/

http://www.w3.org/TR/swbp-xsch-datatypes

http://www.w3.org/2001/sw/BestPractices/

saz: remove high/med/low?

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]

ERT WG

24 May 2005

Attendees

Contents

Referencing External Vocabulary in EARL

Identifying Assertors of Type "Tool"

(Continued) Proposed Changes to the EARL Schema

Summary of Action Items