See also: IRC log
<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
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
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
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
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.
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