See also: IRC log
<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
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