17 May 2005


See also: IRC log


Chaals, Sandor, Nick, Chrisoula, Chris


<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html

Discussing prosed change to schema... continued

Assertor properties

<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html#prop-assertor

SAZ: try to discuss things and come back later if they are tricky
... above link is where we got to.
... There is an Assertor. We prefer to use a FOAF Person to describe a person, but it might make sense to define a Tool (i.e. not a person)
... We might want to seperate the properties according to whether we have a tool or person.
... tool has a title, version
... Fora Person we can use foaf's properties for name, email
... Don't think using dublin core is very elegant - maybe we should be defining something else.

<niq> whynot DC where relevant?

SAZ: There is also the proposed property "using", for someone who is using another tool

CMN: Agree with Niq - it is a good idea to use Dublin Core where there is existing Dublin Core property

<niq> DC is the most widely supported namespace, yesno

SAZ So should we use dc:title for tools

scribe: think it is misused

CMN I think it is the clearest, most used, and hardest to get really wrong - do you have some explanation of what isn't good about it?

SAZ: I think title is more in DC context to describe the titles of documents of publications rather than the name of a tool. It could work still.

<niq> are you suggesting earl:[title|name] as subclass of dc:title?

SAZ: would prefer to have something like earl:toolName as subProperty of dc:title
... not clear about how title reflects what we are talking about.

CMN: dc:title is the title of a resource - docments are the most common, but can be other stuff

SAZ What about hasVersion

CMN: wrong property - we have to do it the other way around, saying that the tool we are using isVersion of a particular Tool which is more generic

SAZ haven't found any properties for tool versions

ACTION Sandor: - look at DOAP (description of a project) for properties on versioning

SAZ: propose that next two properties are dropped in favour of FOAF equivalents
... note that we need to look at how to describe this in the spec

<niq> sounds fine

SAZ: Next - usingTool - to say that an assertor is using tools. I don't know i that is the model we want to use

CMN: We use a property that does this already, because we wanted that information

<niq> yes. What does sidar call this?

CMN: It is called "using" in english or "usando" in spanish, and the URI starts with sidar's URI and I forget the rest.

<niq> not important. agree with having it in under whatever name:-)

CMN: in my original proposal I give an example - see email.

Resolved: We want a using property - Shadi will edit it in.

Test subject properties

SAZ describes a format, and reprOf

scribe: reprOf only applies to Web Content, which is a subClass of Test Subject
... added the date, and Dublin Core hasPart and isPartOf to describe relations between test subjects in an overall report.

<niq> http header: should tie that in to HTTP negotiation

<niq> We want to record http headers concerned with negotiation

<niq> others don't need recording

ACTION niq post to list discussing HTTP headers and what to use

<niq> Vary: header is used for conneg

SAZ Could be useful to know things like content-length - in other contexts

CMN Any header can be used by a server - some are definitely useful, some of them we don't know that they were not used.

<niq> Another point regarding headers: we need to distinguish Request and Response

<niq> no, URL as such isn't an HTTP header

CMN reproduction Of shouldn't point to a rdf:resource="http://some.uri/" as a way of identifying what ws requested

scribe: we should have a propoerty that is a literal, of datatype URI.
... avoids running into the TAG's HTTP-range problem (which they haven't been able to solve yet)

SAZ I like having the headers of the request, as well as server responses

[CMN agrees that we should have access to the entire request/response information]

<niq> Will post email tomorrow

SAZ reprOf has domain of Test Subject, range of Resource. That could be anything - a URI, a local file name, a chunk of RDF, ...

<niq> this is an old chesnut: RDF/HTTP mismatch in use of URI

<niq> conent-location as header doesn't always exist

SAZ for Web Content subjects we need to record the HTTP transaction (somehow - wait for niq's thread)

scribe: for Test Subjects in general, we could have a location property...

<Zakim> chaals, you wanted to talk about reprOf and to ask how we know what was used for negotation and to suggest dc:location

<niq> Location is a good word to use since it agrees with HTTP location

CMN I suggest we use dc:location

SAZ so suggesting using dc:location instead of reproduction of, and for Web Content use something to collect the HTTP transaction

[niq agrees with chaals]

so resolved

SAZ So there are also Dublin Core format properties that we want to use.

CMN agree that they are useful, and that we need ot figure out how to explain this in the schema, without redefining the schema.

SAZ We want some way to validate EARL...

scribe: (as per discussion of last week)
... seems like OWL is the only way to go there. But if we are using OWL full it might be hard to find appropriate parsers

<niq> should someone ask the Bristol folks about parswer?

CMN looked into the particular question of being able to check that something had an identifier, and posted response to the list, as part of action item from last week or week before

SAZ There are parsers, the trick is to be conservative in how much we require implementors to implement

CMN Notes that W3C maintains (or doesn't) a vocab for HTTP that is used in Annotea products

scribe: would be better to clean that up as necessary than to rewrite a different one.
... for describing HTTP transactions.

<niq> annotea gets very confused about HTTP. Or at least it used to

<niq> I haven't looked at it recently

<niq> OK, I'll look at it.

Properties of test results

<niq> I see precision is new. Remind me: was that in NMG-strawman?

SAZ proposed changeing earl:message to dc:description, and adding a precision property

scribe: this is applicable to heuristic evaluations
... so: Validity (pass, fail, etc)
... think that is pretty fundamental.

CMN Sidar subclassed fail, to provide a value of partial. Should EARL bother looking at those things, or should we just suggest other poeple do that.

SAZ This comes up later in teh discussion

<shadi> n-ary

SAZ: dc:description - any comments on that?

CMN this one makes me uneasy, and I would prefer to suybclass dc:descritpion and rdfs:comment - especially if they are messages about the result that are not necessarily describing it as such, but rather adding more detailed information

Resolved - for now we do dc:description, noting that at least chaals is uneasy but not at this stage objecting.

confidence and precision to be discussed for next time.

SAZ please don't hesitate t mail your comments - we can discuss it on list and get a lot of the work out of the way.

scribe: would also like to focus on how we deal with other vocabularies that we are using (DC, FOAF, ...)


Summary of Action Items

[NEW] ACTION: Sandor - look at DOAP (description of a project) for properties on versioning
[NEW] ACTION: niq post to list discussing HTTP headers and what o use
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/05/18 13:51:38 $