14 Jun 2005


See also: IRC log


Shadi, Chris, Chaals, Sandor, Jim
Carlos, Wendy, Johannes


Identify issues in the proposed EARL Schema

Shadi: I added Owl restrictions to schema, today we'll go through the schema marking stuff to discuss

SZ: from the top, nothing controversial to Assertion

Chaals confirming that we'll use UTF-8 ?

SZ: yes we agreed on 26th April

CMN: fine

SZ: concern with server issues, but we'll go with UTF-8 and drop the entities
... Into Assertion, previously the schema was split by classes first, I've re-ordered to make it clearer, grouping classes with properties for readability
... We agreed the properties, now added OWL restrictions limiting the number of assertions etc.

<shadi> ach chaals

<Zakim> chaals, you wanted to request that we drop the maxcardinality

CMN: There are cases where you may want more than one result etc. so we need to be careful to limit the constraint now unless we're absolutely sure it's a constraint we want, as it's easier in OWL/RDF to add restrctions rather than take them away

SZ: So your concern is compatibility between drafts

JL: I agree with chaals.

SZ: I've thought it through and think max-cardinality is right but can see that we need to get agreement on the group.

<Zakim> chaals, you wanted to say yes, agree that we should note that we are looking at further constraint as an issue

RESOLUTION: take out max-cardinality for now and re-visit later.

SZ: dropped location and evidence for now for future discussion

on to Assertor

SZ: added OWL properties
... an assertor could be a tool or a foaf:person, or after CMN's email could be more

<Zakim> chaals, you wanted to say at some point that it seems like a good idea in the next spec draft to note "further issues" as their own section, rather than necessarily tied to a

SZ: also added usingTool property

CMN: location and evidence aren't clear where they should go in the schema, we should add an other things we're planning in the draft.
... I object to requiring foaf:mbox

SZ: can we flag that for now

<Zakim> JibberJim, you wanted to would like to propose one of the foaf IFP's

SZ: we need to limit things so we don't just get oddness.

<Zakim> chaals, you wanted to say there are two things. One is that we want to identify people, but requiring foaf:mbox runs against current practice which was established precisely

JL: we could limit it to requiring any of the IFP's from foaf:

CMN: I agree, we need to make sure we don't go against foaf current practice and discourage people from publishing junk data just to meet the constraint.

SZ: do we want to require mboxsha1sum or should we just require nothing?

CMN: at this stage I suggest we don't put any constraint yet, but should postpone it til we've thought about it more.

SZ: change minCardinality to 0 to make tools aware they should be handling it.
... check in with FOAF guys

CMN: I can live with that

RESOLUTION: change min cardinality to 0 and add mboxsha1sum

SZ: stability of foaf needs to be investigated
... need to keep an eye on it.
... Tool was a subclass of an assertor, it's not any more.
... added in title and version and required cardinalities

<Zakim> chaals, you wanted to suggest dropping domain/range on DC properties, and to try and explain again the hasVersion/isVersion issue.

CMN: domain/range of the properties shouldn't be there
... you need to be able to say you've used a tool SOMETHING1 that is a type of tool SOMETHING. so we need to look at versioning of tools that develop over time.

SZ: is the restriction on having a dc:title etc. enough or should we say more?

CMN: I don't think we should have the constraint on hasVersion, we should not require a version.

SZ: I'd like to get a resolution that we drop the properties at the bottom of the tool section

RESOLUTION: drop the rdf:Property constraints at the end of the tool section on dc:title and dc:hasVersion

<Zakim> JibberJim, you wanted to say I'd like to find an IFP for tools

<Zakim> chaals, you wanted to say that versioning doesn't work across IFPs (I don't think)

JL: I'd like to find some sort of IFP in RDF terms to identify a tool

CMN: I think that's a risky business as versions change.

JL: I was imagining a mixture of tools and versions such there was a combination of the 2 tools and versions of tools.

SZ: I think we should wait for Sandor to look at them as he's currently doing
... We should just wait and see
... change dc:isVersion minCard 0, and dc:title minCardinality 1

CMN: I'm happy with that

RESOLUTION change dc:isVersion minCard 0, and dc:title minCardinality 1

SZ: TestCase
... added a minCardinality of 0 to hasPart/isPartOf to keep it clear for readers of the schema
... we should tighten up the range so that a testCase can only be part of another testCase
... everyone accepts that as is.
... TestMode - added the constraints that say it's one of automatic etc.
... should we add inferred too?

CMN: heuristic actually means its automatic, we can leave it as is and just change the label to make it simpler for the future.

SZ: I think inferred is useful as people use of heuristic in different ways
... we could maybe sub-class of automatic, or just add another term

CMN: Disagree as we don't need it, if heuristic is misused we can change it.

SZ: people using heuristic at the moment for non-inferred things

CMN: propose we leave it as is for now.

<chaals> [But note that we are loooking at interoperability of current practice and may change it if there is a problem]

SZ: I think the fact it's called heuristic is a risk as it will give people expectations from the word

CMN: adding inferred but not removing heuristic will break historical interop. I'm not yet convinced if it's a good or a bad thing.

SZ: Namespaces could solve the historical interop, but maybe not, we'll need to check carefully if we have a new namespace
... clarify heuristic and flag that we may need inferred or other
... testResult has at least one desc. at most one confidence and exactly one validity property

CMN: you think description should be optional?

SZ: CMN you think description should be optional?

CMN: yes

SZ: we should have a description but we should probably have this discussion later

CMN: yes, again we should not have overly tight constraints now but likely will require a description

SZ: confidence has max 1

CMN: we should allow more than 1 as we don't really know what it will look like yet, could have confidences on different scales e.g. fredsScaleHigh and joesScaleMedium

SZ: we can go more complicated in the confidence property but keep the fact there is a confidence here

CMN: we shouldn't force a model until we have an agreement on confidence - so we should allow 0 or more confidence for now

SZ: validity should be exactly 1, it's the key thing of the result and doesn't make sense to have more than 1

CMN: Works for me

CR: I'm happy with everything to

RESOLUTION: change to min cardinality of 0 on confidence/description and flag for later discussion

SZ: confidenceLevel, lots of discussion on this
... waiting on high/med/low descriptions from nick
... I propose we leave that in for now as is acknowleding the issues

CMN: I'm happy with that as long as it's clear it's at risk

SZ: we'll leave it for now as is
... ValidityLevel

<chaals> [happy with validity as is]

SZ: maybe subclass "cannotTell" to help in the confidence area.
... we'll leave validityLevel as is
... TestSubject, we dropped tool and useragent, and just have generic test subject, I've added in some restrictions must have a date, at least one location and exactly 1 format

CMN: I don't think we should have any of these restrictions, they only really apply to WebContent as a TestSubject, rather than all TestSubject
... I think restrictions on format are bad, remove maximum cardinality.
... test subjects could be a collection of formats e.g. WCAG example

SZ: having nothing in test subject will make it more complicated for generic earl processors to know how to process things
... a toaster might not have a format, but we need to be clear so there is a minimum set of things in a subject

<Zakim> chaals, you wanted to say that the only thing TestSubjects have in common is that they are TestSubjects

SZ: and move the web specific things into webcontent

CMN: the only thing that test subjects have in common are they're a test subject, but we can't say that a production run of toasters and a webpage are really the same thing

SZ: I think we should re-visit this next time.
... thanks all, see ya next week.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/14 18:06:42 $