See also: IRC log
<trackbot> Date: 08 July 2015
<RayD> ray
<fjh> ScribeNick: Jacob
<fjh> Web Annotation Protocol FPWD published, https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0023.html
fjh: Add tweaks / clarifications to the agenda
<fjh> proposed RESOLUTION: Minutes from 24 June approved, http://www.w3.org/2015/06/24-annotation-minutes.html
RESOLUTION: Minutes from 24 June approved, http://www.w3.org/2015/06/24-annotation-minutes.html
<fjh> doug: no need to change schedule
doug: no change to schedule, re: ivan had conflict
<fjh> TPAC Annotation schedule unchanged, Mon/Tue
doug: [doug] attending web anno but popping out to help with other working groups as needed
<fjh> no change to Annotation schedule
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0275.html
<fjh> fjh: is there an action here for someone?
fjh: is someone taking an action to actually do the testing that Rob suggested?
<chrisbirk> I can take that
<TimCole> here's the list of SPARQL queries used by Open Annotation for Community Group work
<TimCole> https://github.com/uq-eresearch/lorestore/blob/master/src/main/resources/OAConstraintsSPARQL.json
azaroth: should test feasibility and report back to the group with a summary of how it works, if it fufill its requirements, and what it would take to update moving forward
<PaoloCiccarese> q
chrisbirk: can take this action item
TimCole: pasted in link to the Anna's list
of SPARQL that were used for testing the OA community specs
... useful starting place, could examine if they can be used to suggest
the form of protocol testing, happy to help with that action
<davis_salisbury> Davis (me) has called in
<ivan> Davis
<Kyrce> I am muted on my phone, I am not muted on webex.
<Zakim> azaroth, you wanted to offer help, & re protocol testing
fjh: confirming the Chris volunteered to conduct that testing, Tim volunteered to help
azaroth: also volunteering to help; familiar with Anna's queries, can confirm which ones still apply and which need changing
<fjh> tasks - confirm that query approach can work, review exisitng queries for needed change, share draft of test results
azaroth: mentioned protocol testing, once
queries have been examined, then protocol testing (for HTTP conformance)
can be approached separately
... once model is testable, is much easier, can examine whether or not
headers, status codes are correct
<azaroth> +1 to not testing protocol yet
<Zakim> fjh, you wanted to mention protocol
fjh: may be premature to test the protocol until collections and similar issues are resolved
<azaroth> +1 to Paolo, re testing the /model/ vs testing the /serialization/ [which we can also do]
PaoloCiccarese: regarding queries, even if
the rdf structure is changed, recompiling the annos out of the triple
store, they can be compiled different ways, testing queries is helpful
because they ignore the order (structure) of the rdf, however, it is a
major task
... in addition to this kind of testing, we need to consider framing and
how to test framing, may be difficult to validate
<azaroth> http://json-ld.org/spec/latest/json-ld-framing/
PaoloCiccarese: framing -- precise json-ld structure, (because serializations can be different)
<azaroth> Sample annotation frame: https://github.com/IIIF/iiif.io/blob/master/source/api/presentation/2/annotation_frame.json
PaoloCiccarese: annotation parts can be put into different places in the serializations, so client-side is complicated because a annotation can have many possible permutations of serializations
<Zakim> azaroth, you wanted to distinguish application level validation, vs testing requirements for implementation conformance
PaoloCiccarese: SPARQL always works, but other forms of validation will be much more complex
azaroth: verbally +1 distinguishing testing
the model from testing the serialization
... also application vs. incoming requests, etc. [lost some of the
permutations Rob discussed]
<Zakim> fjh, you wanted to ask if we need annotation canonical serialization
fjh: will we have to define serialization canonicalization and test this, will it be complicated?
azaroth: simpler in our case because can test json keys and bits and pieces, similar to past epub work
<azaroth> EPub oriented json-schema for OA: http://www.idpf.org/epub/oa/schema/oa-epub-schema.json
ivan: framing document -- general framing
algorithm was quite complicated and community group could not come up
with a satisfactory algorithm that could be tested and meet the
requirements
... important to understand where the problems are when framing is
defined
<ivan> http://w3c.github.io/csvw/csv2json/#nesting-objects
ivan: useful to have a target to help define the shape of the serializations, one example of such a thing is csvw solution
PaoloCiccarese: using framing for a while,
normal framing works pretty well, using framing from CG to avoid
creating own, easy if structure is simple, but becomes complicated when
annos are structured
... because of the SPARQL queries, was able to implement a two-level
strategy for validation, one syntactic validation and one semantic
validation
TimCole: first, these are two separate
issues, need way to validate annos to assure that docs are proper,
however, most folks will not want to deal with rdf and so we'll
accommodate that
... one solution could be to develop some services that offload some of
the validation work
... need to face up to the fact that most folks won't add validation to
their clients
shepazu: if this is the case, is there
another way to test the model
... problem seems specific to semantic web and not data models
... specific entities (structures) might be necessary but not in a
specific order
... don't need to spend the energy on an rdf frame
fjh: need to clarify what our goal is and
what we're going to do
... Chris, Tim and Rob going to work on the testing of the model
azaroth: do we want to track testing related issues in the current git repo or do want a new/separate one?
<chrisbirk> I think a separate would be easiest
ivan: no set rule, in the csv group, we just
have a single repo, but if it is easier to manage...
... whoever is managing should give their preference
fjh: moving further discussion offline
<fjh> +1 whoever manages tests should arrange tracking
fjh: what is the time estimate for this activity
chrisbirk: sometime in the next week or so
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0011.html
fjh: seems to be general agreement on the
list to go with the web anno namespace
... can expect additional changes in the future but no reason not to
move to the namespace now
azaroth: naming change ok, best practice is
not to change namespace unless absolutely necessary, personal preference
not to change namespace
... should consider the namespace issue separately from the naming issue
PaoloCiccarese: is web anno going to
supersede the open anno name / namespace; what is the public message to
the folks who have already implemented older versions of the oa model?
... are we saying that open anno is dead?
azaroth: don't want to change the namespace
if we change to something that is not 100% back compatible
... market will decide on which model will be used
ivan: problem with namespace issue, in
practice, is back compatibility, old foaf files are still valid foaf
files, same has been done with rdf and owl, those cases are clear
agreements in the charters to focus on back compatibility
... web anno has no such agreement, the message is that -- web anno is a
more advanced version of the older open anno doc/standard
<fjh> merit to Paolo's concern and Tim's rationale
TimCole: understand and sympathetic to that position, CG members also understood that the working group's output was going to be an evolution; so if we create a new namespace it seems like it could bifurcate the community
<fjh> existing implementations matter
TimCole: risk that some current implementers may see the new namespace as a competing standard rather than a new rendition of open anno
fjh: shouldn't change namespaces just as a "hygiene" issue, do we have a compelling reason to make the change?
<azaroth> http://www.openannotation.org/spec/core/
<ivan> there is probably no reason, fjh, to do it *now*
<fjh> I think we should reserve the right to change, but only if we need to, when we have good reasons. I don't hear that we are at that point now. Agree we can, but we should give it consideration later.
azaroth: final thought, CG did not publish a definitive document, output was a draft, updating the draft could mitigate some of the potential problems, so the namespace issue may not be a big deal
fjh: not ready to make a decision on this call, no compelling rush, can we continue this discussion on list?
azaroth: clarification, the documents should talk about web anno but not so with the namespace
<shepazu> http://w3c.github.io/rangefinder/
shepazu: range finder draft, primary change
based on feedback, may need different kinds of unicode folding for
different languages
... changed from boolian value to typed value
<shepazu> http://w3c.github.io/rangefinder/#idl-def-UnicodeEquivalenceType
shepazu: for the UnicodeEquivalenceType
<fjh> ACTION: chrisbirk to propose model testing, review existing Sparql testing for Web Annotation Model (with Tim Cole and Rob) [recorded in http://www.w3.org/2015/07/08-annotation-minutes.html#action01]
<trackbot> Error finding 'chrisbirk'. You can review and register nicknames at <http://www.w3.org/annotation/track/users>.
shepazu: records which kind of equivalence is preferred, but not sure if browsers are going to be willing to something this complicated for unicode equivalence matching
<fjh> I think Doug is suggesting MUST for one Unicode type support
shepazu: would be surprised if they do more
than one kind, so we should probably pick one, should see if the
internationalization group can make progress on convincing the browser
group to do different kinds of canonicalization
... if anyone has any feedback on the draft would be interested in it
<fjh> +1 to publish FPWD soon
ivan: can we publish this document as a fpwd?
shepazu: would like to make an additional round of editing to make the examples match the existing api, then would be ok to publish, so possibly by next week...
<azaroth> +1
<TimCole> +1
ivan: publishing community is interested in this, so publishing the draft will be helpful
<ivan> +1 to azaroth
fjh: Ray's suggestion for naming the protocol document may be helpful for working around some of the issues on the list, seems like folks are talking past one another
azaroth: Erik's concerns seem deeper than that
fjh: missing why this is breaking the web, what is the problem?
azaroth: my understanding, architecturally, a generic http client should only be governed by the http spec, and the reason the web is successful is because there is no typed coupling at the app level betweem clients and servers using http
<fjh> don't media types create coupling?
azaroth: the protocol doc tries to constrain
this by suggesting a simple header rather than spelling out every
permutation [?]; Erik's concern is that http doesn't require that every
uri handle POST
... if we agree with that position then we would have to have a protocol
that requires creating annos using post, patch, etc. becausre http
doesn't require it, but that seems to defeat the entire purpose of the
anno standard
... would make testing impossible and conformance meaningless
... everything would be consume only, whereas we're trying to get beyond
that
<fjh> we can ask the tag to look at our protocol spec regarding this concern
ivan: why is he happy with ldp but unhappy with what we have?
azaroth: could reuse some of the weasel words in ldp
<fjh> thanks Jacob for scribing
<ivan> trackbot, end telcon