See also: IRC log
<shadi> http://www.w3.org/WAI/ER/EARL10/schema.html
Discussing prosed change to schema... continued
<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.
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.
<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, ...)
adjourned