Web Annotation Working Group Teleconference

15 Oct 2014


See also: IRC log


Dave Cramer (dauwe), Jacob Jett (Jacob), Jake Hartnell (JakeHart), Luc Moreau (Luc), Nick Stenning (nickstenn), Paolo Ciccarese (paoloC), Raphaƫl Troncy (raphael), Rob Sanderson (azaroth), Ben DeMeester (bjdmeest), Ivan Herman (Ivan), Doug Schepers (shepazu), Benjamin Youg (bigbluehat), Maxence Guesdon (MGU), Frederick Hirsch (fjh, on IRC only)
Frederick, Hirsch, Time Cole, Markus Gylling
Rob Sanderson
Dave Cramer


azaroth: any objections to minutes being approved?
... minutes approved

<fjh> RESOLUTION: 8 October 2014 minutes approved: http://www.w3.org/2014/10/08-annotation-minutes.html

azaroth: please do Present+ followed by your name

<azaroth> http://www.slideshare.net/azaroth42/multiplicity-and-publishing-in-open-annotation-tutorial

azaroth: agenda: last slide deck

Extended Data Model Introduction Continued - Multiplicity and Publishing

azaroth: this is much shorter, so hopefully we'll have more time
... if you're interested in model issues, serialization, etc
... two reasons to go through the slides
... first to give everyone background
... second FPWD of revised model is our first deliverable
... want to get done by TPAC
... it's not that we're ignoring apis and achoring
... just priorities
... slide 2
... issue is semantics of multiple bodies and targets
... slide 3
... issue 1 in github tracker is that this should be ordered list
... slide 4
... slide 5
... slide 8
... serialization can be cleaner if match on multiple classes

paoloC: another resource for what the community group has been discussion is the wiki

<paoloC> Open Annotation Community Group Wiki http://www.w3.org/community/openannotation/wiki/Main_Page

shepazu: How much of this is about RDF and how much is about data model?
... these are considerations put into data model for sake of RDF

azaroth: the list issue is a compromise
... for the difficulty of doing order in graph (schema)
... the composite is a valuable construct
... allows for multiple languages
... multiple uris for same content
... of the three constructs we have, choice is the most well-used
... the issue with lists can be made easier by reversing CG decision
... serializations would become cleaner
... I think there's a better compromise for list

paoloC: I agree
... I'm on the fence about composite
... when we have multiple targets with nothing else specified
... imporant if you want structured annotation
... these things that are spread out in doc can be put in formal model
... I think composite is important.
... on lists, most issues were related to RDF
... due to limitations of tech

shepazu: without addressing composites issue
... is having this composite model the only way of expressing this? Probably.
... I'm not saying we shouldn't consider RDF
... but I'd like to urge group to consider that we should work on data model first
... i.e. separate data model from its serialization

<paoloC> +1

<Jacob> With regards to composites, a use case that popped out of the digital emblematica work here at Illinois was what to do when the annotator is annotating the juxtaposition of two distinct resources.

shepazu: in CG data model is inseperable from RDF
... I want them to be separate
... so I can use JSON_LD :)

paoloC: so abstract model should be independent of serialization?

shepazu: we can consider issues of serialization
... but would like them to be separate
... i understand we need RDF serialization
... but we may convince lots of people to use the data model who won't be using RDF
... lists are hard to express in RDF--I'm not sure how we will get around that

azaroth: it's not that it's impossible
... if you have to expose the plumbing it gets ugly
... the current method exposes the plumbing
... let's discuss on list

shepazu: OK

Luc: I understand for multiple targets
... we may want to distinguish roles of targets
... if you come from JSON background you might want dictionaries
... key / target pairs
... why don't we look at other forms of collections besides lists?

azaroth: the role of the indiv. target didn't come up
... we decided it was too complex to deal with

paoloC: we started to talk
... composite is totally general
... I can distinguish role of target in body
... with structured body you can qualify targets
... we didn't formalize solutions due to infinite vocabs
... gets difficult for interop
... in body you can talk about target as body has a uri
... this gets close to specific use cases

<Luc> ok, i will think about it

azaroth: let's create issue

<Luc> paolo, yes please give us an example

paoloC: can you give example
... creating a triple out of two targets

<Luc> thanks

azaroth: moving on to slide 9
... we made explicit choice to not talk about protocols
... slide 10
... JSON-LD is recommended over RDF/XML

<Luc> ;-)

azaroth: slide 11
... slide 12
... slide 13
... slide 14

Luc: [is very quiet]

shepazu: minor point
... in OA CG list, some said "has body"
... those sort of RDF-ish predicates
... change from has body to body?

azaroth: that was discussed
... there was some support
... there was more support for keeping the same predicate names as in the ontology
... to avoid confusion
... e.g. would be weird to remember body in one place and hasbody in another place
... the advantage of JSON-LD is that it looks like JSON, it would be good to have intuitive keys

<paoloC> +1

shepazu: let's raise as issue

ivan: content structure in json-ld gives us freedom to use whatever keys we want
... should be closer to user
... worth noting is that the context key and context value can be completely hidden
... can get json-ld through http, as link in http header
... if app is not interested in context it can be disregarded, can be delivered for those who want rdf stuff

azaroth: multiple contexts can exist that do different mappings into same set of predicates

paoloC: there's a framing issue
... it's possible to frame JSON-LD so it looks always the same
... framing with multiple graphs is not yet supported

ivan: json framing is not part of rec

paoloC: I'm using framing extensively

<Luc> Luc notes that we seem to alternate between serialization issues and data model ...

paoloC: I thought framing now is stable, but might be extended

azaroth: there's an rdf shapes WG, framing would fall in there
... talk to Phil Archer?
... slide 15
... slide 16

shepazu: I'm not happy with the way you framed either CSS or SVG
... i think it's unduly limited

azaroth: what do you mean by framing?

shepazu: I was using it in the sense of human language, the way you expressed it and limited it
... i have suggestions.

azaroth: excellent
... slide 17
... slide 18
... slide 19
... slide 20
... slide 21
... slide 22
... slide 23-24
... questions?

shepazu: this isn't a question
... want to clarify
... when will we be publishing this as FPWD?
... do we need to solve some of these issues first?
... splitting out data model from RDF, deciding how the data model will be expressed
... I'd be more inclined to getting a draft out early, then revising
... with quick iterations
... rather getting everything perfect

azaroth: we should do some work before FPWD
... this is a working group that is doing stuff
... rather than cut/paste from CG spec
... which might give impression of rubber-stamping

shepazu: I'm sympathetic to that

<azaroth> +1\

ivan: Let's rework document so that it is fundamentally JSON-LD based

<shepazu> +1

ivan: we should do that before FPWD
... once that's done, the details of the models and open issues
... let's put it out to make it clear what we're working on
... if we can rework towards JSON-LD, let's publish then, address issues later

shepazu: that particular change would be biggest symbol we could send to community

paoloC: good idea to rework spec using JSON-LD
... we say use JSON but all our slides don't use it
... mixed feelings about putting it out right away
... we mix up core and extensions in single namespace

shepazu: quick straw poll?
... should we convert to JSON before FPWD?

<nickstenn> +1

<paoloC> +1

<azaroth> +1 to converting

<ivan> +1 +1

<MGU> +1

<bigbluehat> +1 to converting

shepazu: is converting to JSON sufficient for FPWD?

<Bill_Kasdorf> +1

<rayd> don't care

<azaroth> -1 to sufficient

<bjdmeest> +0

<paoloC> +0

<bigbluehat> +0 on the FPWD part

<MGU> +0

<Bill_Kasdorf> +0 to sufficient

ivan: one more thing

<shepazu> +1 to converting, +1 to sufficient for FPWD

ivan: if we use JSON-LD then whole issue of namespaces becomes secondary
... since they can be hidden in the context

<azaroth> +1 to ivan :)

ivan: it has effect on formal RDF output

<paoloC> +1 sounds good

ivan: but that is not crucial issue
... it is cheating, but helpful :)
... let's people concentrate on important things

Luc: what does group mean by data model?
... data model needs to be expressed in schema language
... that should be in FPWD

ivan: what do you mean by schema language in this case?

Luc: UML or JSON schema
... even OWL

<shepazu> relaxng?

Luc: lots of possibilities

<shepazu> WebIDL?

ivan: the RDF is used to express data model
... the OA guys have formal schema for data model
... it's down there in the deep roots

<azaroth> thanks Dave!

ivan: I don't need to do some things specific

shepazu: let's do on list

azaroth: thanks everyone! Let's discuss some things on list

<raphael> +1 on converting and using consistently JSON-LD examples

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-10-16 11:40:49 $