.. retrieve the doc. compute hash on pointer and tell whether pointer is still valid or not.

13:35:09 [wendy]

.. if not valid, look to other elements that the pointer points to to see if have same hash

13:35:48 [wendy]

.. last bit beyond what we have implemented. but can based on what we have done.

13:35:56 [chaalsBRS]

WAC have you imlemented that - how common a requirement is it in practise?

13:36:20 [chaalsBRS]

WAC you are sharing pointers now?

13:36:41 [chaalsBRS]

NK pointer, hash, spec, HTTP details

13:36:56 [chaalsBRS]

... haven't implemented it, did proof of concept for html pointer and hashing

13:37:05 [chaalsBRS]

... with hashing the annozilla guy has done it too.

13:37:17 [chaalsBRS]

WAC didn't know you are hashing elements

13:37:26 [chaalsBRS]

NK we are hashing at whatever point we are interested.

13:37:58 [chaalsBRS]

...a node and children, a node and some children, etc.

13:38:04 [chaalsBRS]

WAC how do you decide what to hash?

13:38:22 [chaalsBRS]

NK test decides what it needs and hashes that.

13:38:35 [chaalsBRS]

... wich is recorded in the data we are then sharing

13:39:05 [chaalsBRS]

WAC where does nortmalisation happen?

13:39:13 [wendy]

dp sounds reasonably complex, is it worth it?

13:39:22 [chaalsBRS]

NK that is at the first place to get a DOm to make pointers into

13:39:33 [wendy]

jl try to evaluate almost anything, you will fail b/c doc changes everytime you evaluate it.

13:39:41 [wendy]

nk worked out through a bit of trial and error.

13:40:18 [chaalsBRS]

NK what I am talking about here is where we are at in terms of reverse engineering our stuff into something formal

13:40:26 [chaalsBRS]

WAC intersted in feedback...

13:40:47 [chaalsBRS]

WAC They didn't want this in HTML?

13:41:03 [chaalsBRS]

NK We proposed a canonicall normalisation, but they didn't want to touch that.

13:41:29 [chaalsBRS]

... this is a new proposal that can allow the use of whatever normalisation someone wants, plus how to repeat that.

13:41:32 [chaalsBRS]

WAC 3 questions.

13:41:43 [chaalsBRS]

1. Reactions from people?

13:41:55 [chaalsBRS]

2. Seems like we need to be proposing this to someone, but who?

13:42:02 [chaalsBRS]

NK In principle anyone talking about markup

13:42:08 [chaalsBRS]

WAC yes, but it needs to be blessed...

13:42:12 [chaalsBRS]

q+

13:42:45 [wendy]

cmn how much does this need to be blessed? not sure. don't think so. it's useful. it's a huge need for EARL.

13:43:04 [wendy]

.. needs to do html, not just xml. not situation for people developing xpath.

13:43:11 [wendy]

nk they might be itnerested in similarity measures.

13:43:16 [wendy]

jl i don't think it's sufficient as it is.

13:43:22 [wendy]

.. doesn't survive doc change.

13:43:30 [wendy]

cmn we can bless it if we find it useful.

13:43:41 [wendy]

. we're not reinventing someone else's wheel.

13:43:49 [wendy]

.. we're extending their wheels.

13:44:09 [chaalsBRS]

WAC where does it go in relation to the EARL spec?

13:44:17 [chaalsBRS]

... we would need some documentation of it.

13:44:19 [chaalsBRS]

q+

13:44:27 [chaalsBRS]

NK I can hack that documentation together

13:44:54 [chaalsBRS]

ACTION: Nick Kew - write up HTML pointer documentation

13:45:24 [wendy]

cmn make sure it works alongside what people are doing. can we do it with 2 or 3 normalizations. can we map between them?

13:45:47 [wendy]

.. if your tool was integrated into a few comemrcial products, you would have to do more than one.

13:45:51 [wendy]

.. they don't normalize the same way.

13:46:25 [wendy]

.. at the moment they are using line/paragraph pointers. can you work that into the system to retrieve?

13:47:25 [wendy]

dp if you view the normalization as the first part of this interface, it should be viable.

13:47:38 [wendy]

cmn can we map between normalizations.

13:47:48 [wendy]

dp i can choose between diff parsers,

13:47:53 [wendy]

nk similar

13:48:19 [wendy]

dp you dno't care b/c input is normalized doc.

13:48:43 [wendy]

nk mozilla and x normalizes diff.

13:48:57 [wendy]

.. just what found when did it.

13:48:59 [Giorgio]

the comparisons service should be able to take as input EARL statements, the evaluated resource and store both of them and compute an internally used normalization.

13:48:59 [wendy]

jl not quite.

13:49:22 [wendy]

ack ericp

13:49:41 [Giorgio]

the service should get from EARL the problem location in the way in which it is computed by the tool.

13:49:58 [wendy]

ep i haven't heard much of what you said, but amaya has the ability to normalize one way

13:50:01 [wendy]

.. tidy does diff.

13:50:12 [wendy]

.. one question we run into is whether something like schema validation

13:50:20 [wendy]

.. was something you want to include in the xpath or not

13:50:40 [wendy]

nk tbody?

13:50:43 [wendy]

ep yes.

13:50:45 [wendy]

nk yes, have to consider.

13:51:03 [wendy]

.. leave that to the normalization, as long as specify can take it either way since can reconstruct.

13:51:26 [wendy]

ep require processing of xpath.

13:51:35 [wendy]

.. missed it (also hard to hear you)

13:52:00 [wendy]

wac acks cmn

13:52:06 [wendy]

wac acks chaalsbrs

13:52:06 [ericP]

a defined mapping to a well-formed XML document is all you need for XPath

13:52:10 [wendy]

wac acks chaalsBRS

13:52:22 [sbp]

s/acks/ack/

13:52:25 [sbp]

I think

13:52:30 [ericP]

the question is then, why would you want to add a dependency on schema validation

13:52:43 [chaalsBRS]

q+

13:52:49 [ericP]

one answer, some H

13:52:51 [chaalsBRS]

response to Giorgio:

13:53:15 [ericP]

XGML-MXML mappers do produce a PSV document

13:53:33 [wendy]

dp wasn't that the comment you (jl) was making? the simple URI is inadequate?

13:53:35 [wendy]

jl nods

13:53:49 [wendy]

dp yes, diff between time 0 and time 1.

13:54:24 [wendy]

nk reads giorgio's comments

13:54:48 [wendy]

cmn how's the tool going to compute what normalization was used

13:54:49 [wendy]

?

13:55:06 [Giorgio]

the service should use whatever data the tool provides

13:55:19 [chaalsBRS]

giorgio, do you mean that the normalisation used should be stored as part of the data?

13:55:26 [Giorgio]

no.

13:55:29 [wendy]

nk earl:normalization

13:55:39 [Giorgio]

the tool should use ,say line numebers

13:56:03 [wendy]

dp store data "this is what i tested"

13:56:05 [Giorgio]

the service gets this and using some sort of normalization finds where the problem is located

13:56:11 [wendy]

nk it is excessive if doing much of it

13:56:13 [wendy]

dp good alternative

13:56:15 [chaalsBRS]

I mean should the earl include a note about what normalisation was used, or that tools should be able to automatically figure out which normalisation was used?

13:56:15 [wendy]

nk not for me

13:56:26 [wendy]

gl have to eval something. it will change. then do you store the new one?

13:56:35 [wendy]

s/gl/jl

13:56:44 [wendy]

jl storing it versus storing a measure of it.

13:56:54 [wendy]

dp if changes one iota retest

13:57:02 [wendy]

jl not usable for many of the use cases.

13:57:06 [wendy]

nk often not necessary

13:57:12 [wendy]

jl human eval expensive to redo.

13:57:22 [wendy]

.. don't want to invalidate just b/c one date changes.

13:57:37 [chaalsBRS]

I don't see that tools are going to be able to calcualte automatically the normalisation used by a different tool, unless it is specified and there is potenitally a service to show what that mapping is.

13:58:07 [sbp]

agreed. you have to note the normalization

13:58:24 [sbp]

unless you point to an archive of the normalized result

13:58:28 [wendy]

cmn still trying to understand what giorgio's saying.

13:59:09 [wendy]

.. to reuse that info (the earlier evaluation) and check later. you have to reproduce that normalization

13:59:13 [Giorgio]

My point is that it is far easier to make tool vendor to provide EARL statements with things like line number, offsets, DOM index

13:59:15 [wendy]

..in order to find where that thing was.

13:59:21 [wendy]

.. and know what the original normalization.

13:59:29 [Giorgio]

.. rather than to agree to adopt a specific normalization.

13:59:34 [wendy]

.. then require in earl, carry problem, location of problem, part of location, what normalization is used.

13:59:51 [Giorgio]

.. That said, we need to work on the interface of a service that accepts this data and

14:00:18 [chaalsBRS]

I agree that we shouldn't require a particular normalisation - they can just specify whatever they do already.

14:00:24 [Giorgio]

.. somehow integrates it into the internally used normalized version of the document being tested.

14:00:53 [sbp]

<+q>the thing is, we can't require that people say what normalization was used: we can require that they note that *some* normalization was used, and recommend strongly that the ydocument it,a nd perhaps provide the hash and an archive link to the normalized output or whatever</+q>

14:00:55 [wendy]

nk you can look at line and column, what i'm saying is that we can do more useful things than that.

14:01:24 [chaalsBRS]

q+

14:01:41 [wendy]

jl why can't we require them to provide which normalization was used?

14:01:46 [wendy]

.. even if private, they can say which was used.

14:01:55 [wendy]

nk they would have to share if they want it to be useful to a 3rd party.

14:01:55 [ericP]

i was going to ask that too

14:02:28 [wendy]

cmn rereads end of giorio's last comment

14:02:35 [wendy]

cmn take data from another tool...

14:02:42 [wendy]

nk each dev needs to specify what doing.

14:02:53 [sbp]

in reply to JL: well, what information are we going to say that we should require? a link to the source code of the normalization algorithm? an RDF representation of that algorithm? the name for the algorithm? the human-readable documentation for it?

14:03:06 [ericP]

just an identifier

14:03:23 [wendy]

people agree - just an identifier.

14:03:26 [wendy]

nk it could be any

14:03:26 [chaalsBRS]

agree with ericP

14:03:28 [wendy]

jl hopefully all

14:03:29 [ericP]

i invent an alghorythm and maybe i document it

14:03:34 [sbp]

right, hence that "we can require that they note that *some* normalization was used"

14:03:52 [ericP]

someone happens to re-implement that algorythm so they use the same identifier

14:03:58 [wendy]

jl they need to give a ref to the normalization, so can compare...if two people use same tool we can compare.

20 minute break. Back at 3.30 local time to talk about cleaning up the schema.

14:11:19 [Zakim]

-BristolF2F

14:12:08 [Zakim]

-EricP

14:12:09 [Zakim]

WAI_ERTWG(SW f2f)9:00AM has ended

14:21:52 [sbp]

[chuckle]: "(not yet a) W3C Working Draft"

14:23:08 [wendy]

:) you like that eh, sbp?

14:23:19 [wendy]

we'll pull that off once we go to tr.

14:23:34 [sbp]

very much so. TimBL and DanC were moaning about people publishing pseudo-WDs very recently on #rdfig

14:24:14 [sbp]

nadia: actually, TestCase is *not* the range of object; it's restricted to that when used on an earl:Assertion. the distinction between using range/domain and using DAML restrictions is something that shouldn't be missed

14:25:44 [sbp]

missed out in the specification, that is... dunno how best to represent it in that table

14:30:03 [nadia]

sean: have you looked at my reorganization that i just sent?

14:30:21 [nadia]

i'm not sure what you mean by what you said

14:30:28 [sbp]

yep, that's what I was commenting on

14:30:39 [sbp]

well... the range of rdf:subject is not earl:TestCase

14:30:51 [sbp]

otherwise reficiation would be pretty useless to 99% of the world :-)

14:30:57 [sbp]

I refer to the table in section... um...

14:31:06 [sbp]

"4. Properties of Classes"

14:31:07 [libby]

ericP?

14:31:09 [nadia]

wendy did that

14:31:23 [libby]

do you want to dial in again?

14:31:36 [nadia]

look at sections 2 (missing the number) and 3

14:31:59 [nadia]

i wanted to replace the "properties" and "classes" sections with something that's a bit clearer on the actual structure

14:32:21 [wendy]

oops - yes, i see my error. what i was trying to say is that on an earl:assertion, the object is limited to earl:TestCase.

14:32:52 [wendy]

s/object/subject

14:33:04 [nadia]

all i did was organize properties by their domain, and the minor classes by the property they were associated with

just playing around w/representing the data in various forms to make the schema easier to understand.

14:35:37 [wendy]

section: earl as rdf

14:36:09 [wendy]

title of doc: version 1.0 spec

14:37:55 [sbp]

the range of object is not TestCase, and it'd be confusing to say otherwise. I'm not sure how to put it clearly, but object has a DAML restriction on it such that the values that it can take when used on earl:Assertion are limited to instances of earl:TestCase

14:38:07 [wendy]

giorgio, sbp, eric? which of you wants to be on the phone for the next session?

14:38:20 [wendy]

we'll be talking about cleaning up the schema. danbri has posted a proposal.

14:38:47 [nadia]

um, wendy's tables are really useful as a quick reference

14:38:50 [danb_lap]

I have to admit that I _don't_ know the current EARL schema very well. So I resolved to keep my mouth shut rather than bluff.

14:38:57 [sbp]

yep, agreed

14:39:08 [nadia]

perhaps you could say "earl suggests TestCase" in the tables

14:39:22 [sbp]

(um, agreed that they're a very useful reference, that is)

14:40:06 [sbp]

if we went with DanBri's proposed line, this would no longer be a problem

Note: When restricting the range of a property, as we are doing here, there is an important difference between using a toClass restriction and using rdfs:range (as we did for the hasFather property). An rdfs:range element has a global scope: any use of the hasFather property for any class must always yield a male. A toClass restriction (as used in the Person class) on the other hand has a local scope: the parent of a person must be person, but the parent of any oth

how would people add their own extensions, which Nick et al. have already done? via. some m12n mechanism?

14:57:14 [danb_lap]

much as per rss 1.0

14:57:23 [sbp]

um... I don't agree with that at all

14:57:55 [sbp]

DAML+OIL is in every way as stable as those languages in my opinion, and perhaps more so than FOAF. just because it's more complex doesn't mean that it doesn't get maintained

14:58:30 [nmg]

my point is more that it stands to be superceded by OWL

14:58:50 [sbp]

so we have to wait for Godot before we can go to NOTE/Rec?

14:58:51 [nadia]

imho, i don't think the problem is that daml+oil might be unstable, i think just that it's unnecessary and confusing in the schema itself

14:59:14 [danb_lap]

ie you'd have an XML-based 'file format', with particular portions of the XML syntax allowing other namespaces.

14:59:27 [ericP]

nadia, i bet putting the rdfs stuff at the top would help

14:59:32 [sbp]

danbri: then you couldn't have a DTD/XML schema for it

14:59:36 [ericP]

it would give folks a lay of the land

14:59:50 [danb_lap]

sbp, I'm on the DAML+OIL committee. I don't see it being maintained. The DAML+OIL baton was passed to WebOnt WG.

14:59:59 [danb_lap]

sbp: yes you could.

14:59:59 [ericP]

sbp, when i last looked, the daml schema schema didn't use Disjoints for validation

15:00:48 [sbp]

danbri: would you be willing to produce the DTD/XML schema for EARL, then? I'm pretty sure that even in ANY, you have to decalre the elements being used

15:01:09 [danb_lap]

A schematron schema, perhaps...

15:01:10 [sbp]

as I found out when I tried to modularize RDF into HTML

15:01:23 [sbp]

but schematron is not endorsed by the W3C!

15:01:27 [ericP]

it would be feasible to write a DTD/XML schema/relaxNG schema to validate a particular form of an earl document.

15:01:40 [sbp]

yep

15:01:54 [ericP]

it wouldn't be validate all the RDF isomorphisms of an instance of that document

15:02:05 [sbp]

nor extensions

15:02:08 [danb_lap]

that'd be ok. It'd be a syntactic profile of RDF>

15:02:09 [danb_lap]

.

15:02:18 [danb_lap]

You could do it in prose, even.

15:02:21 [ericP]

it also wouldn't permit extensibility except in ways that the schema designer expected and designed for

15:02:22 [sbp]

it's the extensions that I'm worried about

15:02:34 [libby]

group wonders whether to talk about other aspects of the schema

15:02:51 [ericP]

so then you get into the general problem of expressing constraints for an extensible object

15:02:59 [libby]

nmg brings up an issue about subclassing rdf:property

15:03:14 [ericP]

this is what description logic is good for

15:03:15 [sbp]

eric: well, XHTML m12n is the model to look at

15:03:21 [libby]

...which will confuse fancy inference engines

15:03:34 [sbp]

eric: i.e. the best precedent amongst W3C recommendations

15:04:03 [libby]

...you separate out the ontology from the ontology langauge - not using rdf:propertyu breaks this divide

15:04:16 [ericP]

miscalculation

15:04:17 [sbp]

modularization

15:04:20 [libby]

wendy: what is the benfit of creating subclasss of property

15:04:20 [libby]

?

15:04:21 [sbp]

lol

15:04:21 [ericP]

modularization

15:04:26 [ericP]

i'll bet it's that one

15:04:35 [ericP]

maybe multiplication

15:04:37 [libby]

sbp? what d'you reckon?

15:04:52 [libby]

wendy - maybe from a OO point of view

15:04:55 [sbp]

subClassOf Property where?

15:05:02 [nadia]

ResultProperty

15:05:02 [sbp]

what are we referring to?

15:05:04 [libby]

nmg - subclassing is deemed ok...

15:05:05 [sbp]

cheers

15:05:54 [ericP]

sbp, do you have a specific proposal derivative of XHTML miscalculation or a hunch that that's the way to go?

15:05:56 [sbp]

well the range of rdf:predicate is rdf:Property, so I didn't have much of a choice :-)

15:06:15 [libby]

libby says her stuff can't deal with subproperties

15:06:51 [sbp]

eric: it's mainly a hunch that that would be the direction to take if we started producing XML schemata for EARL, but I'm not sure how much value that approach has anyway

15:07:04 [danb_lap]

danbri: I'm worried that EARL's use of RDF falls between two worlds. It does some stuff that Description Logic (DAML+OIL etc) reasoners will likely barf on. And things like having subclasses of property mean simple triple stores can get confused too.

15:07:17 [libby]

libby: so if we got rid of rdf reification the subclassing propeerrty would go too?

15:07:44 [sbp]

it'd be O.K. to infer out some triples, e.g. stating that earl:fails a rdf:Property

15:08:04 [libby]

nmg offers to go away and write a review of the schema - at the moment the rationale is ratther spare so outsiders find it difficult to underxstand who certain decisions were made