Web Annotation Working Group Teleconference

Scribe selection, Agenda Review, Announcements?

<azaroth> Scribe: Paolo

<azaroth> Scribenick: PaoloCiccarese

Announcement: Paolo left and rejoin as an Invited Expert (change of status)

Ivan: relevant for this group (major users) IDPF published first draft of EPUB 3.1
... group that is a major user
... IDPF waiting for a version of the model they can refer to to replace the Community Group draft

Minutes Approval

PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/01/27-annotation-minutes.html

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/01/27-annotation-minutes.html

F2F Logistics

Rob: At the end of the call last week a Wikipage has been created for working at the Agenda

<azaroth> https://www.w3.org/2002/09/wbs/73180/anno-f2f-berlin-2016/

Rob: and a poll for the attandance
... to know who is going to be at the meeting
... any further announcements about F2F?

Issues

#117 - renderedVia

Issue: https://github.com/w3c/web-annotation/issues/117

<trackbot> Created ISSUE-27 - Https://github.com/w3c/web-annotation/issues/117. Please complete additional details at <http://www.w3.org/annotation/track/issues/27/edit>.

<azaroth> https://github.com/w3c/web-annotation/issues/117

Benjamin: do we have enough to get to a conclusion?

Rob: Can you summarize?

Benjamin: the objective is to include information on how the document was rendered
... in hypothes.is some were rendered in PDF or HTML and so on that have different representations
... annotation in the browser has little knowledge of the PDF features
... HTML pointers and XPath would do the selection
... knowing the original source format would help with optimizing the selectors usage

Rob: add renderVia property with SoftwareAgent as range
... with softwareVersion for the version of the PDF viewer for example

Ivan: no problem with the idea but worried about "do we want to set the schema.org property as required vocabulary? Isn't better to keep that open for using other vocabularies?"
... it seems it goes beyond our scope as there are other vocabularies
... that can be used for this

Rob: Banjamin how critical is software Version in respect to the other properties?

Benjamin: don't think i it is a deal breaker, we can switch back to another vocabulary such as DC
... schema.org seemed clearer in the definition

Ivan: I am ok to put in the document that schema.org is preferred but not required
... I would not block this feature either if everybody thinks it is needed

takeshi: what is the expected behavior when the client finds these properties?
... should the software be opening that specific software for rendering?

Benjamin: it is not expected, but if you have access you could
... it is more to keep historical info of what happened
... not a requirement for pushing to retrieve the right viewer
... more for using the proper selectors
... and optimizing the selectors usage

<azaroth> +1 to MAY

<bigbluehat> yes. renderedVia would be entirely optional

TimCole: renderVia I would assume is optional
... should be put as "this is how you would do it not because it is the only way that you can do it but more it is serving this use case better"
... has to be optional and a non normative approach
... not a hard requirement

<bigbluehat> this originating email has more of the backstory and thinking (and the emphasis on it being optional) https://lists.w3.org/Archives/Public/public-annotation/2015Nov/0226.html

TimCole: to provide guidance

PaoloCiccarese: I think we've gotten to something weird things, if I understand, it's only about the rendering. I can load a PDF in my pdf.js viewer
... I see the PDF rendered as HTML. I annotate it, and I know the doc is a PDF, but that it was rendered via PDF.js
... rather than some other system that displays PDFs and understands the encoding structure, so produces different HTML, and thus different actors

bigbluehat: Yes, they create HTML representations, and selectors could be generic for PDF like a text range or whatever, but to use renderedVia would be to use a DOM based selector as an optimization
... Then you can more quickly process those selectors, or try them first
... there's readium.js, epub.js and they have drastically different dom representations
... would be a waste of time to use the selectors in a rendering engine they weren't created against
... so just an optimization

PaoloCiccarese: I wonder if I write an application, then I know what I can understand. If I see something I don't understand, i'll ignore it

bigbluehat: There was a similar assumption at hypothes.is. You can't tell without looking at the URL and hoping .pdf is a PDF, which it isn't always
... without the context of knowing the client's rendering engine, you wouldn't know what to do. Also, the DOM structure would change a lot with different versions of pdf.js
... if we had version numbers, then you could do more optimizations
... the closed world assumption breaks across versions, so better to record the information at the time
... As much information, if optional, as possible would be better for people in the future

PaoloCiccarese: That last is convincing for me. the HTML is really scrambled.
... To rephrase then, as an implementer, if I access the same document and open the HTML version, and have a separate URL for a PDF of the same content, that's not in scope for this
... the scope here is a renderer in the browser

<bigbluehat> here's an example from the hypothes.is API https://hypothes.is/api/annotations/AVKyP2vKvTW_3w8Lyvo1

<scribe> scribenick: PaoloCiccarese

<bigbluehat> recent. like today

azaroth: Are we happy with non normative definition of renderVIa, do we need to keep the range open?
... what else could be the range?

TimCole: A community might use something different

azaroth: an example that include SoftwareAgaent but make sure the range is open

<bigbluehat> works for me

<azaroth> PROPOSAL: Add oa:renderedVia, with domain SpecificResource, and no defined Range. Examples would use prov:SoftwareAgent, as per generator

<TimCole> +1

<ivan> +1

<azaroth> +1

<bigbluehat> +1

<takeshi> +1

+1

RESOLUTION: Add oa:renderedVia, with domain SpecificResource, and no defined Range. Examples would use prov:SoftwareAgent, as per generator

https://github.com/w3c/web-annotation/issues/133

azaroth: What we can normatively reference
... my proposal is to put anon normative space to the list

Ivan: not sure

azaroth: we can put it in the spacs and look for feedback

Ivan: what is exactly the proposal?

azaroth: would be nice to have a reference to the list but where to put such reference?
... probably easier to have the link in the document rather then the end of it
... for readers

<ivan> https://www.iana.org/assignments/media-types/media-types.xhtml ?

Ivan: is the proposal to refer to the list of media-types?

<bigbluehat> works for me.

Ivan: we can try that
... I agree

azaroth: any disagrememnt to add the link to the media-types?

<azaroth> PROPOSAL: Refer to https://www.iana.org/assignments/media-types/media-types.xhtml in the main body of the model and vocabulary specifications

<ivan> +1

<azaroth> +1

<TimCole> +1

<bjdmeest> +1

+1

RESOLUTION: Refer to https://www.iana.org/assignments/media-types/media-types.xhtml in the main body of the model and vocabulary specifications

<bigbluehat> +1

https://github.com/w3c/web-annotation/issues/134

<bigbluehat> s/(sorry)//

<azaroth> http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

azaroth: there is also a registry of language tags at IANA
... list of languages

takeshi: I think that the JSON-LD covers sub-language as well? en_US for example

<bigbluehat> agree with takeshi

Ivan: that is correct

<azaroth> +1 to takeshi

Ivan: then what we could do is to refer to the I18N reference

<ivan> http://www.w3.org/International/articles/language-tags/

Ivan: it is like saying see that for further info

<azaroth> PROPOSAL: Refer to http://www.w3.org/International/articles/language-tags/ informatively regarding languages

+1

<bigbluehat> +1

<ivan> +1

<takeshi> +1

<azaroth> PROPOSAL: Refer to http://www.w3.org/International/articles/language-tags/ informatively regarding languages and verify with I18N review

<TimCole> +1

<azaroth> +1

<ivan> +1

RESOLUTION: Refer to http://www.w3.org/International/articles/language-tags/ informatively regarding languages and verify with I18N review

https://github.com/w3c/web-annotation/issues/141

azaroth: Issues around dates

Ivan: the point is that the model is now requires to fill in the full date-time so I need to make up times
... we could be less precise and allow for union of different types
... or we can define a union ourself (more complicated)

<ivan> DCMI definition: dcterms:W3CDTF

Ivan: Dublin Core uses

<ivan> Formal definition is here: http://dublincore.org/documents/dcmi-terms/#terms-W3CDTF

Ivan: dcterms:W3CDTF
... covers the different time/dates formats
... we could use that as a DataType
... we can put dates without time

<ivan> Examples for allowed forms: https://github.com/w3c/web-annotation/issues/141#issuecomment-174576427

azaroth: do we use this for all dates in the model?

TimCole: inclined to agree but it will make an annotation qualified by just the year as compliant

Ivan: the dates will need to be parsed by software and understood, implementation more complex

TimCole: less precise filtering

Ivan: I have the impression that people will produce complete datetimes anyway
... but if I only really need the date
... I could put just that
... without the T00:12:12

TimCole: agree

Ivan: by referring to that we ask the implementation to handle that

azaroth: do we still recommand one format and allow for all the others?

Ivan: that is less permissive than the usual libraries but it means that you can write dates with different precision

azaroth: given annotation will be mostly created by machines... precise about tiem
... so we recoommend to be precise down to seconds and allow for the other

Ivan: I would probably store the format that matches the input
... so I turned into a date but keep the original precision/format
... I would propose we adopt this but we explicitly say in the document as a feature at risk saying that implementations feels that is to complex to handle
... we might go back to use DateTime
... feature at risk

<azaroth> PROPOSAL: Adopt dc:W3CDTF as feature-at-risk, to fall back to xsd:datetime. Recommend full ISO8601 form.

+1 (with some chills)

<TimCole> +1

<azaroth> +1

<ivan> +1

<takeshi> +1

<bjdmeest> +1

RESOLUTION: Adopt dc:W3CDTF as feature-at-risk, to fall back to xsd:datetime. Recommend full ISO8601 form.

https://github.com/w3c/web-annotation/issues/143

azaroth: do we also want to have intervals?

Ivan: don't remember a precise use case

azaroth: Time state is the document at this point in time

Ivan: I could say I talk about this document between two dates
... this is restricted to Time State
... not to all time sin general

takeshi: Time State would work for hand writing?
... handwriting takes time and it is an ongoing process we could keep track of
... could we use those for this purpose

Ivan: we tried to concentrate on one thing to not open it too much
... and becomes uncontrollable
... the notion of interval would apply to many thing but we should not do that

azaroth: we can come up with a proposal and put it for next week

<ivan> -- adjurned

<ivan> trackbot, end telcon