ERT WG -- 26 Apr 2005

Proposed Changes to the EARL Schema

SA: suggested real changes to EARL schema - page was sent to list
... some changes not controversial, can be accepted on call
... would like group to vote on changes though
... asking for overall impressions

Jim: sounds good

CR: overall good, still need to review in detail

SA: no major objections on list
... will review item by item now, if needs discussion will flag for further discussion
... trying to find which part of doc needs work

<chaals> item - change character set

<chaals> [chaals agrees]

SA: header? move to formal vote
... doctype? concerns over FOAF

CMN: suggests drop entities
... should not have entities in schema
... should not define classes

<Zakim> chaals, you wanted to suggest we drop the entities stuff

<JohannesK> http://www.w3.org/2000/01/rdf-schema#

JK: new namespace for RDF schema above

<Zakim> chaals, you wanted to respond that we should have OWL at some point...

CMN: at some point we need to define OWL restrictions

SA: we need to let other discussions settle before deciding on entities

CMN: would rather have whole name
... including entities can create problems

Jim: not every tool supports entities so should be dropped

JK: can be dropped as is shorthand for "lazy people"

SA: RDF root will include full name
... will wait untill other discussions resolved
... core classes -----
... 'location' was added and used in assertion
... OK to keep for now?

CMN: OK to have location
... would not put in subclasses as resources, redundant
... would like to see labels and comments and language
... all human text should have language
... do not to say subclass of resource, apparent from schema but needs label

<chaals> for example

<chaals> <rdfs:label xml:lang="en">Location information</rdfs:label>

<chaals> <rdfs:comment xml:lang="en">A piece of information that describes a relevant location in the subject of a particular result</rdfs:comment>

SA: move to next point, return later
... added 'software' class - without discussion on list. OK?

CMN: not sure how define things like flash or other content builders
... some specs may not be on the web

SA: everything in spec we will need implementations and tests
... can live for now with one class of web content

general agreement

SA: assertor class -------
... there are no sub classes of these

CMN: big point of discussion
... bad manners to redefine other people's terms
... first person should not be assertor
... discussion regarding tool being assertor
... no point in defining person at all

Jim: leave person out

CMN: "tools" class - nervous about adding

SA: properties of assertor --------

<chaals> [because there are then potentially two kinds of tools - one that does tests and one that gets tested, and if people mix them up you get some very nasty modelling errors]

SA: different properties for person as opposed to tools?
... collapse into one type of assertor?

CMN: they have different properties
... questions whether they should be sub classes of assertor

<JibberJim> foaf:Agent actually which probably does apply to tools

CMN: unless we have additional things to say about it we don't need to redefine it

Jim: don't drop tool completly. But things like foaf are already defined so we can reuse.

SA: will flag and come back

CMN: claim may be different depending on agent - uses Bobby & APrompt as examples

Niq: different type of assertion - automatic and with person

CMN: same as HERA, some assertions by person alone, some with help from HERA

SA: uncomfortable dropping EARL "person" just to provide difference

<niq> assertor = {person?, tool*}

SA: should be explicit in schema - should say there are persons and there are tools

Jim: could also be a number of tools in combination, not just one tool

<chaals> so we would go for something like

<chaals> <rdfs:label xml:lang="en">A software agent rather than a Person</rdfs:label>

Jim: allow for multiple tools

CMN: HERA uses multiple tools like W3C validator and other validators

SA: questions whether this is useful

CMN: gives example of how HERA uses multiple validators to provide result

SA: still questions - should each tool provide assertion?

CMN: even so no change to schema is required

SA: current model is one assertor and one result

CMN: should push people to be more descriptive to describe what went into assertion
... would not say they are all assertors
... not all tools are assertors - could create nasty looking graph - "tools are tools"

SA: how about defining person the same way?

CMN: we don't have anything unique to say about an EARL person

<chaals> CMN Tools are probably disjoit with foaf:Organisation too (another defined subclass of foaf:Agent if I recall correctly

SA: action - will update proposals and send to list
... thanks Jim for sending fuzzy pointers to list - will discuss next week

ERT WG

26 Apr 2005

Attendees

Contents

Proposed Changes to the EARL Schema

Summary of Action Items