RE: Reminder: [updated] EARL 1.0 Schema]

Hi group,

> Ref: <http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Schema-20081106>
> 
> Updated editor's draft of EARL 1.0 Schema is available for review. We
> will be discussing this during this week's telecon call. Please note
the
> following questions (also marked as editor's notes inline):
> 
> 
> ## Editorial questions ##
> - Move section 1.1 as lead-in for section 2?

+1

> - Format of "related properties" in section 2.1 vs section 2.2

Based on the input from Michael I'm more in favour of the DLs structure.

> - Inline conformance sub-sections (see section 2.1 vs section 2.2)

Not strong feelings about this, but would prefer not to have this
information repeated (inline and conformance section)

> - Usage of "external link" icons, see section 2.2 for example

Think it's a usuability improvement, so +1

> ## Substance questions ##
> - Adopt foaf:Document as TestSubject? (see section 2.3)

Not sure. It's currently flagged as "testing" and its concept of
Document may be too much wide and ambiguous

> - Add dc:title to http:Connection and repr:Content? (see section 2.3)

Not sure, do you have an example of the kind of information that you may
include in that title?

> - Add dc:date to TestResult? (see section 2.5)

Not sure about whether there is a use case for this, but in any case I
can live with it if it is optional.

> - Definition of TestMode (see discussion on definition of Outcome)
> - Class name Outcome versus OutcomeValue? (see section 2.7)

Would prefer outcomeValue property and Outcome class, but can live with
this.

> - Add dc:date to Software class? (see section 2.8)

The use of a dc:date for the "production date" sounds quite strange for
me, as versions, not dates, are the common distinction

> - Check definition of mainAssertor (see section 3.6)

Looks as clear as it can be ;o)
 
> ## Specific questions ##
> - Definition of Outcome: as classes or as resources? See list
discussion
> http://lists.w3.org/Archives/Public/public-wai-ert/2008Nov/0023
> - Adoption of DOAP: should we adopt it? If yes, how (using property,
> using an equivalent class approach like FOAF, adopt new terms, ...)

After checking with our Semantic Web people, they think DOAP is not as
stable and mature as the rest of vocabularies we are using, and
additionally it is more related to projects that to software products.

They recommend me to keep on with our current Software class.

> - Conformance section: what should be in this section versus what
should
> be in-line within the sections. Should we (re-)use tables?

I think the tables may be useful, but not sure about as "conformance
information"


Regards,
 cI.

Received on Tuesday, 9 December 2008 16:18:27 UTC