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