Evaluation and Repair Tools Working Group Teleconference

01 Apr 2009


See also: IRC log


Mike, Shadi, Johannes, CarlosI


EARL 1.0 Schema

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009Mar/0025

MS: there are still some typos in the EARL draft
... assertedBy property: do we have to add foaf:Agent, etc. to the property's range?

SAZ: no

no substantial comments on the current draft

SAZ: each object of earl:assertedBy is an earl:Assertor, it may also be something else
... please look at RDF schema and the issue list; we are required to process every comment
... Mike, please fix all typos; and record editorial changes -> note
... others, in case of found typos, please send mail to Mike or SAZ
... in our documents we have values, e.g. earl:Passed is sub-class of earl:OutcomeValue
... so you can further sub-class them, e.g. NearlyPassed subClassOf earl:CannotTell
... what happens when someone creates an instance of type earl:Passed and give it a different meaning?
... 1. possibility: leave as it is; 2.: change back to instances; 3.: create a parallel instance for each class

<shadi> JK: shouldn't do #2 because it restricts

<shadi> JK: #3 sounds good but may be too much

<shadi> JK: if we create earl:Passed, it does not have the type earl:OutcomeValue

<shadi> earl:passed instanceOf earl:Pass

<shadi> earl:Pass subClassOf earl:OutcomeValue

<shadi> JK: should ask Ivan if worth the effort

<shadi> JK: for HTTP-in-RDF, it does not make sense to create a class for status code 404

<shadi> ...maybe for "Redirect" or "Error" but not for individual status codes

MS: a difference between status codes and outcome values is: status codes are predefined with specific meaning, whereas outcome values may be sub-classed to create more specific values
... not sure into which class modes fall
... perhaps test mode is more like status code than outcome value

so change back to instances

<shadi> [Proposal: add instances to each subclass of earl:OutcomeValue; change subclasses of earl:TestMode to instances; change HTTP-in-RDF status code groups to subclasses of status; keep HTTP-in-RDF status codes as instances (of the status code group classes)]

<shadi> RESOLUTION: Shadi check with Ivan on dual class and instance approach; everyone review schema.rdf and known issues list; Johannes do changes to HTTP-in-RDF per the above proposal; Mike take and editorial pass on the EARL 1.0 Schema spec

Next and future meetings

SAZ: next meeting April 8th 2009
... chaired by Mike
... CI, please record comments to pointers draft

CI: think they are only editorial; I'll do necessary changes

SAZ: put pointers draft on agenda for 15th or 22nd

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/04/01 20:35:31 $