See also: IRC log
saz: outlines possibilties in uri above
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> <owl:Class rdf:about="&earl;Assertor">
<shadi> <rdfs:label xml:lang="en">Assertor</rdfs:label>
<shadi> <rdfs:comment xml:lang="en">Person or Tool that claims assertions</rdfs:comment>
<shadi> <owl:oneOf rdf:parseType="Collection">
<shadi> <owl:Thing rdf:about="&earl;Tool"/>
<shadi> <owl:Thing rdf:about="&foaf;Person"/>
saz: this is a way of referencing a foaf:person
as an assertor
... avoid duplicating 'person' directly use person
cmn: good idea
<shadi> <rdf:Property rdf:about="&earl;ToolName" rdfs:label="Name of a Tool">
<shadi> <rdfs:domain rdf:resource="&earl;Tool"/>
<shadi> <owl:sameAs rdf:resource="&dc;title" />
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
<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.
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"
saz: don't want to get into too deeply w/out rest of the group.
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
... SWBPIG has published something about datatypes and n-ary relations that may be useful.
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]