Web Annotation Working Group Teleconference

Scribe selection, Agenda Review, Announcements?

<azaroth> scribenick: bjdmeest

azaroth: [discussing today's agenda]

dwhly: [about iAnnotate] all systems go
... registration is up right now

<dwhly> http://iannotate.org/2016/

ivan: and it works :)

<dwhly> :)

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/02/05-annotation-minutes.html

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

Issue discussions

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

azaroth: raised by Ivan, discussed briefly last time
... short proposal:
... issue is that timestate only allows recording a single point in time
... representation for an annotation needs an interval
... e.g., web archive etc. uses ranges, so seems easy to support
... proposal: sourceDateStart and sourceDateEnd, or sourceDate if single point in time
... using W3CDTF with fallback to xsd:dateTime, both are valid

shepazu: how did they do it in media fragments?

azaroth: this is unrelated
... this is about real-world datetime, about change

shepazu: this has nothing to do with range in a webpage, but a valid datetime?

azaroth: yes

<nickstenn> What's the proposed behaviour if sourceDateStart/sourceDateEnd are provided at the same time as sourceDate?

ivan: I am fine with this proposal

azaroth: other comments?

ivan: [about writing it down in the spec]: what about all three attributes are in the document, etc.
... these are specifics, when writing it down

fjh: is there an action?

ivan: editor will have to include this

azaroth: I'm fine to do it

<azaroth> PROPOSED RESOLUTION: Accept the proposal in #143 to add sourceDateStart / sourceDateEnd to TimeState

<azaroth> +1

<ivan> +1

+1

<PaoloCiccarese> +1

<fjh> +1

<shepazu> +0

<tbdinesh> +1

nickstenn: xsd:datetime already supports range, was that a concious decision not using that?

azaroth: last time we also discussed #+-141, so we could also support only dates if no time is known
... using xsd:datetime, you cannot do 'range between this day and this day' without including the time

<ivan> rq+

azaroth: so that's why two dates instead of datetime range

<ivan> https://www.w3.org/TR/xmlschema-2/#dateTime dateTime specification

ivan: xsd:datetime does not cover duration, that's a different datatype
... in xsd:schema
... so datetime is not a duration
... duration is a different datatype, as far as I can see
... and these are disjoint

azaroth: we could have sourceDuration with a single duration datatype

ivan: I would not want that unreadable syntax

<nickstenn> +1

RESOLUTION: Accept the proposal in #143 to add sourceDateStart / sourceDateEnd to TimeState

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

azaroth: (wasn't a github issue yet, I made one)
... whether it was possible and/or desirable to validate the fragment selectors
... e.g. a fragment claiming it is a media fragment, but doesn't conform to the media fragments spec
... should we be able to check that?
... proposal: this is an implementation concern
... a validation suite can be constructed around it, but we as WG don't concern ourselves as specifying that

<davis_salisbury> +1 tp letting it go

<fjh> close it

<ivan> +1 to kill it

<azaroth> PROPOSAL: Close #148, not in scope of WG work

<nickstenn> the important thing is the construction rule: `source + "#" + fragment`

<PaoloCiccarese> +1 to not tackle

RESOLUTION: Close #148, not in scope of WG work

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

azaroth: [from europeana] about language tags in rdf, and how that works
... [see example] valid RDF and valid JSON-LD, but very confusing

<azaroth> https://github.com/w3c/web-annotation/issues/149#issuecomment-181462980

azaroth: discussion about language tag was an early one
... two reasons for using dc:language instead of @en
... (1) datatype + language tag cannot happen simultaneously in RDF
... we do allow them, but then we get type and @type, value and @value, and language and @language
... changes of this going wrong is high
... we should not do that
... al their use cases are covered (language choices, explicit language)
... I think we can close this, no new requirements are proposed
... there are good reasons for our current way of working
... questions, comments?

[crickets]

<nickstenn> the point of the shorthand was to make minimal conforming implementations simpler...

azaroth: having language on the resource instead of the literal makes it easier for human understanding

<azaroth> PROPOSAL: Close #149, no change needed

<fjh> +1

<PaoloCiccarese> +1

<nickstenn> +1

<ivan> +1

<davis_salisbury> +1

<azaroth> +1

+1

RESOLUTION: Close #149, no change needed

Annotation Lists https://github.com/w3c/web-annotation/issues/50

azaorth: issue: how we manage ordered groups of things
... if it were pure JSON, it would possibly be a non-issue, just an array
... but we also want to be compatible with RDF via JSON-LD
... ignoring ordering from a spec perspective, there are several times when this issue becomes relevant
... easiest one: how to have a list of annotations, or a group of annotations
... requirement from the protocol perspective
... e.g., search matched list of annotations, annotations in this container, harvesting lists of annotations, list of annotations to upload, etc.
... IDPF and DPUBIG have a real requirement for this
... some additional constraints/requirements, i.e., lists have properties
... e.g. DVD extra's equivalent as set of annotations
... so some metadata (label/price/...)
... not just a JSON array, but also some extra data

ivan: thus this is not only a JSON-LD issue

azaroth: we need to think about the modelling in RDF for the resource that is a set

PaoloCiccarese: other use case: teaching
... when teaching, we have a set of annotations to publish for students with extra metadata
... it's seen as a collection, not a single annotation
... there many use cases in teaching and science as well

<davis_salisbury> +1 to Paolo

<azaroth> (+1 to Paolo too!)

shepazu: what is the relation between collection and ordered collection?

azaroth: the order of collections has be requested, e.g., for list of annotations that are on a particular web page, ordered by relevance to the user (e.g., social network)
... would make response more useful (good stuff first)

shepazu: why JSON vs JSON-LD issue?

azaroth: in JSON-LD, an array is used for 2 different purposes
... both look the same in JSON-LD, but are different in RDF
... e.g., unordered collection [2, 4, 9049, 1]
... or ordered collection, which is an RDF list, e.g., [1,2,3,4]
... proposal: we only do ordered collections, we don't do unordered collections at all
... there are modelling reasons why you might want to have a set of unordered items, the serialization will always be in order
... the order just might not be static
... you have systems that always return annotations in order, moving to another system that doesn't have order could give bad results for the user

ivan: essentially: we do like JSON, i.e., always a list (implies ordering)
... and that's where we stop
... I am very sympathetic to this approach
... but that also means that all the sections about multiplicity constructs go down the drain in the model spec?
... in the case of the protocol, it is clear, but what do we do with other places that talk about something like a collection?>

azaroth: referring to #92: is this choice consistent for multiplicity?
... same for #145
... proposal: we drop composite (Because we only do ordered)
... choice is a subclass of list of things
... and use orderedcollection of activityStreams
... we do need to keep the discussion about language, i.e., choice about displaying language
... to keep them working

ivan: we decide by principle, to keep only an ordered list

<azaroth> +1

ivan: underlying principle is that this is the approach we take in both documents
... if there are specific cases, we open extra issues for these issues, and discuss this subclassing further there
... proposal: close all issues, and say we use ordered always, and new issue is opened for discussing the rewriting of the multiplicity sections

PaoloCiccarese: I'm ok with accepting only ordered list
... as implementer: am I supposed to keep that order?
... in use cases where I don't care about order
... is it mandatory it keep order across transformations?

ivan: answer is: you have to keep order, to keep the same RDF
... so can I add a proposal?

azaroth: sure

<ivan> Proposed RESOLUTION: we close issues #50, #92, #145 with the principle that, whenever we can, we use ordered list only. Exceptions should be subjects of specific issues.

<azaroth> +1

+1

<davis_salisbury> +1

<ivan> +1

azaroth: we aim for compatibility for RDF via JSON-LD

<tbdinesh> +1

ivan: for the end-user, this is the simplest thing

azaroth: and also for the end-user developer

<PaoloCiccarese> +1

<nickstenn> +0

<shepazu> +0

<fjh> +0

RESOLUTION: we close issues #50, #92, #145 with the principle that, whenever we can, we use ordered list only. Exceptions should be subjects of specific issues.

AOB

azaroth: AOB?
... some broad topics: testing and html serialization

ivan: how far are we to have a virtual last call?

<azaroth> https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Atelco+

azaroth: amount of open issues has decreased a lot
... by the end of march, we could have a last call for issues internally

ivan: so another month and a half?

azaroth: certainly before the end of march

ivan: because we have 4 open issues, some are relatively minor
... e.g., selector to the wide world is discussed a lot, with restricted influence
... multiple states and selectors are dependent of todays resolution
... I'd like us to publish it by the end of march

azaroth: good
... adjourn