See also: IRC log
saz: jim sent descriptin http://jibbering.com/discussion/fuzzy-pointers.html, first concept of fuzzy pointers
saz: we'll probably not be able to note all document changes
<chaals> Chris: this is astrategy we can use for things that are not well-formed. sounds like it would be ok. will we use other things as well, such as xpointers?
cr: fuzzy pointer for docs that are not well formed ok
<Zakim> chaals, you wanted to say good thing overall
<shadi> Chaals: Fuzzy Pointers are compatible with XPointers
<shadi> Chaals: FP is one strategies, we probably need more than one
<chaals> chaals: we will want several Locations at the same time, to give us good chance to find things
<shadi> example: /html/body/table/*/tr/td/img[@src='moomin.gif']
saz: example with tbody, is possible to express with xpointer
<chaals> SAZ: is it not possible to use an Xpointer for something in a table that is invalid becausee has no tbody (see example above)
<chaals> jim: It is possible, but less accurate, because you could have any number of things replace the * whereas with fuzzy pointer you know where the thing was.
<chaals> saz: we could use this to have a very rough pointer.. such as any images with teh following attribute...
cmn: fuzzy pointers are good thing to use, need examples
<niq> "this passcode is not valid" (many, many times). And when I ask for operator assistance, it's a recorded voice telling me to wait for an operator (but no end to the wait)
<chaals> chaals: propose that we include an example of how to use a fuzzy pointer as a location in next spec draft.
saz: what is the practical experience with fuzzy pointers
<chaals> jim: Was looking at it in the context of anotea
<chaals> ... got a lot of reliability across browsers for identifying things in browsers
<niq> fuzzy pointers: arises from when we wanted Jim's client code (various) to interoperate with my server stuff (Valet)
<chaals> ... You could define a similar pointer for cases like images - we should do some more work on how they would interoperate in earl context
saz: addition of rdf-id?
<Zakim> chaals, you wanted to exaplin the relevant bit of http://lists.w3.org/Archives/Public/public-wai-ert/2005May/0012.html
<chaals> cmn: not sure that it should be required to have an ID, although it is a good practice
cmn: do we really require it?
<chaals> cr: what is the purpose of it?
<chaals> saz: if you have a few assertions, and ask for the assertion with specific property, you get the assertions merged together
<chaals> cr: can't you jsut ask for information that differentiates the assertion?
<chaals> saz: there are sometimes multiple assertions with same subject, same result, same testcase, different tools...
<chaals> cr: there should always be something different in the assertions. I don't see a case where you need an id to differentiate them. Or is this to allow you to refer to them?
<Zakim> chaals, you wanted to give use case based on proposed evidence property
cmn: can't refer to a specific assertion without id
<chaals> cr: how do you generate the ID?
cmn: id tied to e.g. the URI of a page, no mix-up
<chaals> jk: if you merge two things with the same ID, what do you get?
<niq> twins? :-)
<chaals> cmn: this should be handled by RDF parsers...
<chaals> jl: I don't think it is bad, but I don't think we should make a comment in the schema to require it - this is more a good practice
<Zakim> chaals, you wanted to say "what jim said"
<chaals> saz: I thnk we shouldn't reinvent wheels reproducing vocabulary
<JibberJim> Rosco - http://swordfish.rdfweb.org/discovery/2003/08/validation/
<chaals> ... but do we want to have a minimal set of required data in earl
<chaals> ... and include in that an ID
<chaals> cmn: we should have a set of required information for an EARL assertion
<chaals> ... not convinced that ID should be part of that
<chaals> cr: should have minimal set...
<chaals> saz: question is does ID belong in that set. let's leave for later.
saz: rdf-id good think, optional or required not clear by now
<chaals> ACTION: cmn to look up how to define ID as required [recorded in http://www.w3.org/2005/05/03-er-irc]
<chaals> jim: the link above is a checker that says whether a FOAF file has enough useful information to be interoperable. that can be a more helpful approach than formally defininf rules in the schema
saz: next property location
<chaals> saz: pointer to a container of Locations
<chaals> cmn: good idea, only suggestion is that the URI for class and property look different
<JibberJim> classes are pascal case - properties are camel case I believe
saz: next property evidence
... based on the properties listed
cmn: shouldn't be restricted to assertions, rule is not an assertion necessarily
saz: should the range change?
<chaals> jim: don't see that removing the restriction will lose a lot of interoperability
cmn: expect a list of assertions + rules why
these are relevant
... most tools don't need to expect all the evidence
... without a rule we're providing random statements, should be possible to include reasoning
thx to all for helping out :