Evaluation and Repair Tools Working Group Teleconference

Welcome

SAZ: last week went over some of the submitted comments.
... Some interesting questions about location of conformance section.

Continue processing comments

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/

SAZ: go through the issues one by one.
... last week got till 004.

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/0005.html

KV: Don't agree we have to modify the schema for this; it's clear.

SAZ: Model is explained that way. There are examples in pseudo code.
... The question is how to model the verbs themselves and make Assertion subclass of RDF statement.
... This can have consequences.
... Assertion class is parent node with testsubject etc. With partial info (test module for part of assertion) ... it's easier to use the current model.
... Making this change would restrict EARL in some way.
... Discussion similar to discussion on object-oriented programming.
... "Firefox 3.5 passes CSS test case 1.026" can be modeled with current approach.
... Don't need to open the model based on that comment.

<shadi> RESOLUTION: beware to explain the basic EARL model in the Developer Guide, but not reopen the fundamental design of EARL (Assertion)

<kostas> i aggree

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/0006.html

Comment 006: Extensibility Policy

<sinarmaya> I agree with Sean in this point: I think that is very important that the report has all the information about the applicable policy and extensions if there are any.

SAZ: No reference to what EARL report would need to contain regarding extensions.
... Sean's comment is the group's original thought on how extensibility would work.
... ... especially with tools that have some heuristics and that make guesses like "probablyPasses"
... probablyPass would e.g. be a subclass of "unknown"
... This would allow tool-specific vocabulary to be used and still conform.
... 4 or 5 types of outputs, with extensibility policy

<shadi> http://www.w3.org/TR/EARL10-Guide/#extension

SAZ: Guide does not really explain extensibility. Many XML snippets, but code like in Sean's e-mail would be useful.
... extensibility needs to be better explained and needs to be referenced from the conformance section.
... EGYRS raises important point; new angle that is not in the submitted bug.
... The example in the comment would meet the conformance requirements, but this needs to be better explained.
... The new term, e.g. "probablyPasses" would need to be explained somewhere; it should be public or it should be part of the report.

<shadi> RESOLUTION: better explain the extensibility model in the Developer Guide and provide a cross-reference from the conformance

<shadi> ^^section

<shadi> RESOLUTION: consider adding requirement for providing the information about vocabulary extensions in EARL reports so that consumer tools can process/disambiguiate the terms

<sinarmaya> (tools and humans) .-D

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/0007.html

Bug 007: Vocabulary Control

SAZ: status of the vocabulary is reflected in the spec text but not in the machine-readable schema.
... could use the vocabulary used by FOAF for annotation.

<shadi> RESOLUTION: accept suggestion and better explain the status/maturity of the vocabulary within the schema

<kostas> ok

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/0008.html

Comment 008: Ingenious Tool Range

SAZ: earl:tool property in earlier version of EARL.

<sinarmaya> agree with Sean, this can be useful

SAZ: People did not exactly know how to process original tool code, so Software class was added.
... Properties for consumption by humans, ...
... Go back to a "tool" that can be anything: homepage of tool, documentation, etc.?

KV: Prefer to keep it as it is. It is currently clear.

SAZ: Use case for approach from commenter?

EGYRS: A way to say the same thing... Can be used as in Sean's example ...

SAZ: Assumes that the statement is made by a tool, but we now have an Assertor, which need not be a tool.
... It is more structured and more processable now.
... If you want to bring back the old earl:tool property, please bring in use cases.

EGYRS: I suppose that Sean knows the new approach.
... Maybe he has reasons that we don't know.
... If the new way is better, then that is OK. Then we need to explain this to him.

SAZ: We can ask if he has something particular in mind.

<shadi> RESOLUTION: respond to Sean explaining the benefits of the current approach rather than the previous earl:tool approach, and ask if he has use cases that make it necessary to re-add the old approach

<shadi> http://lists.w3.org/Archives/Public/public-earl10-comments/2011May/0009.html

Comment 009: Vocabulary Terms are Not Reusable

SAZ: Comment on earlier draft of EARL: add domain and range to properties to conform to best practice.
... OWL can be used on top of RDF Schema. Orthogonal discussion whether we use OWL or not.
... Possibly respond that we understand that this is best practice...
... If you use a term to point to something else than in our vocabulary, it would no longer be the same term. Possibly double-check with W3C Semantic Web people.

<sinarmaya> It seem logical for me, the question is if it is easy to do or not ;-)

<shadi> RESOLUTION: respond to Sean saying that it is the group understanding that it is RDF best practice to always provide doman and range for properties, and that the use of OWL in additon to the RDF Schema is an orthagonal issue

CS: If RDF Scheme says A needs to refer to B etc, how would adding OWL make the vocabulary more reusable?

SAZ: Separate OWL schema, which can be used either together with the RDF Schema or separately.
... Earlier attempt to use OWL made it too restrictive.
... Good idea to remove domain and range from properties? Does not seem to be good practice.
... Think about next comment (010) by next week.

Upcoming meeting schedule

<sinarmaya> me/ sorry, netx week I will be out of my city