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