W3C

Web Annotation Working Group Teleconference

12 Nov 2014

Agenda

Attendees

Present
Ben_De_Meester, Benjamin_Young, Dan_Whaley, Dave_Cramer, Doug_Schepers, Frederick_Hirsch, Jacob_Jett, Jacob_Jett(IRC), Kyrce_Swenson, MGU, Matt_Haas, Maxence_Guesdon, Mxence_Guesdon, PaoloC, Paolo_Ciccarese, Rob_Sanderson, Robert_Sanderson, Ray_Denenberg
Regrets
Antonio_Olmo_Titos, Ivan_Herman, Kristof_Csillag, Luc_Moreau, Markus_Gylling, Raphaël_Troncy, Tim_Cole, Újvári_Gergely, Antonio_Olmo-Titos
Chair
Frederick_Hirsch, Robert_Sanderson
Scribe
bjdmeest

Contents


<trackbot> Date: 12 November 2014

<fjh> ScribeNick: bjdmeest

fjh: reviews agenda

Minutes Approval

<fjh> proposed RESOLUTION: 28 October 2014 F2F minutes approved: http://www.w3.org/2014/10/28-annotation-minutes.html

RESOLUTION: 28 October 2014 F2F minutes approved: http://www.w3.org/2014/10/28-annotation-minutes.html

Digital Publishing Use Case Document

<fjh> updated, see http://w3c.github.io/dpub-annotation/

azaroth: we are going to finalize the dpub use case document

<azaroth> http://w3c.github.io/dpub-annotation/

azaroth: if I don't get any additions (final warning), this will get finalized
... If you want them edited in the current note, let me now asap
... it will be published next thursday

shepazu: I want to talk about how we do use cases

fjh: let's do it later
... move on the web annotation data model

<azaroth> http://w3c.github.io/web-annotation/model_fpwd/static.html

Web annotation data model

fjh: we have an updated editors draft

<fjh> Review updated ED draft http://w3c.github.io/web-annotation/model_fpwd/

fjh: we like to publish a FPWD the end of this year
... 2 points to do:
...1: publish a FPWD

<fjh> shortname annotation-model
...2: decide on shortname
... we are at annotation-model
... decisions need to be done formally
... FPWD is fyi just a draft, does not have to perfect
... there are IPR implications when we publish, so it is beneficial to do it quickly
... we do not want to publish on the very last day
... so we should publish by the 16th of december
... editors need some time
... call for consensus is needed soon
... then we can request the transition to get it published
... So now, we should see where we are with the draft
... from I understand, we have simple text, List vs Choice, and ???

azaroth: We have
... The string literal body
... with the restrictions as discussed on F2F
... we changed composite and choice, to be real RDF
... leaved the composite
... we used RDF-value for simple text
... we remerged the documents (there were 4)
... it is now 1 document
... The string literal (body's) have to come first, for the simple model
... we left some things out
... the use of graph for the body
... + we need to look at how RDF and JSON-LD does graph
... the second item is the OA equivalent to relationship
... for federated system
... different copies at different URI of the same annotation
... serializedBy's should not be merged together
... in the document, we also put both JSON-LD and TTL both as serialization (JSON default)
... the last point was:
... in the doc: we have both JSON-LD and TTL
... And, we renamed the keys in JSON-LD to be more intuitive
... than just mirroring the RDF

PaoloC: you did not mention the semantic tag
... it was just a tag to URI for an ontologic term
... now it changed (Fig 7)
... now, we create a resource for the semantic term
... that allows us not to add the semantic tag to the URI

fjh: this is about the scope, like mentioned

<Zakim> shepazu, you wanted to ask about "hasBody" vs. "body", etc.

<azaroth> ISSUE: reference CG draft, list changes

<trackbot> Created ISSUE-14 - Reference cg draft, list changes. Please complete additional details at <http://www.w3.org/annotation/track/issues/14/edit>.

shepazu: few comments

<shepazu> http://w3c.github.io/web-annotation/model_fpwd/#vocabulary

shepazu: obvious one: looking at eg first vocabulary

<paoloC> http://w3c.github.io/web-annotation/model_fpwd/#diagrams-and-examples

shepazu: [hasBody, Type, Body Target], I do not get how you can have different label between JSON-LD and RDF

PaoloC: in section 1.2, there is a note
... how to transfer between terms JSON-Ld and RDF
... labels are different because you have a context
... note might not be seen, so it might seem strange

shepazu: this might be a matter of how it is presented?
... someone skimming the doc might miss the note
... suggesting to add a column:
... this is the thing, its value, and its equivalent in RDF

PaoloC: theoretically, anyone can use a different context, we provide a default

<fjh> or put a note there

shepazu: I would suggest calling it... use language like 'keyword'
... more familiar to average web developper
... 'name' maybe
... ''body' is this, RDF equivalent is this

<fjh> ‘equivalent JSON property name'

<fjh> default context for JSON-LD has …

shepazu: it would help to make it clear what is the distinction
... this is througout the doc

fjh: this needs to be cristal clear

PaoloC: classes don't change

shepazu: disambiguate from the beginning
... have the names serve the human-readable version of the name

<fjh> ISSUE: make implications of context clear for each example in document

<trackbot> Created ISSUE-15 - Make implications of context clear for each example in document. Please complete additional details at <http://www.w3.org/annotation/track/issues/15/edit>.

PaoloC: the only problem I see
... the way JSON-LD works, is that it can have different contexts
... we have to be clear that that is the default behaviour

shepazu: elaborate on note: the name is equivalent to this name in RDF

<fjh> ISSUE: Expand note regarding how context allows different names in Note Well in 1.2

<trackbot> Created ISSUE-16 - Expand note regarding how context allows different names in note well in 1.2. Please complete additional details at <http://www.w3.org/annotation/track/issues/16/edit>.

shepazu: you can change the context (which is a pro thing), but make it so that the average user understands it clear

<stain> perhaps every place there is a Vocabulary table there should be two columns, called "Term" and "JSON-LD key" or something

azaroth: It looks like a good idea to get a default key, and a table for each of the vocbulary levels

<stain> "Item" is strange --- but these are usability things on the spec that can be tweaked at a later stage

shepazu: the abstract is abstract, I should put in more wording
... I will send some suggestions

<fjh> ISSUE: Update abstract

<trackbot> Created ISSUE-17 - Update abstract. Please complete additional details at <http://www.w3.org/annotation/track/issues/17/edit>.

shepazu: third comment: looking at non-semantic tags
... you guys consider it as bodies
... it seems really verbose, even in JSON-LD, to encode non-semantic tags

<fjh> http://w3c.github.io/web-annotation/model_fpwd/#tags

shepazu: maybe there is a way to make it simpler
... attach a tag to a body
... the reason I bring this up: I showed this spec to some implementers
... they found it too verbose, too complex

<Jacob> Wasn't the simple textual body supposed to be the workaround for this?

azaroth: tags needs to be associated with a body, not with an annotation

PaoloC: We had another term, defined only tags
... if there are two flavors, you need to consider both

<stain> also it can give the impression taht you are tagging the annotation or the body, rather than the target

PaoloC: becomes complex

<fjh> jacob, I believe you need a type to know it is a tag

azaroth: make tag subclass of body

shepazu: suggestion: tag is a type of body

<Jacob> Unless you leverage the information from motivation. e.g., I might have a bunch of simple textual bodies and the motivation "tagging" and just call it a day.

shepazu: some are content, some are tags
... could you allow a tag to be part of a body, rather than whole of a body?
... you could have a body that contains tags and content

fjh: seems more complex instead of simpler

PaoloC: if you want to combine tags with content, you could have structured bodies
... like Rob mentions, problems with graph
... that's a new relationship, new complexity
... maybe type, I don't know
... a subtype of body (type = tag): would kind of make the case...
... we discussed this at length, don't know if we want to open that pandora box

shepazu: I like structured bodies
... eg: I select a passage
... (text)
... I have a (content) body, type, value, ... and target
... in the target, I store everything (selectors etc)

<stain> (my apologies, I have to catch that train now)

shepazu: then, I add some tags
... I have to repeat all that information again?"

PaoloC: If you have tags that apply to the same content, you just add a new body
... you don't have to repeat the target part

shepazu: is that specified in the spec?

rob: 3.2.9

<paoloC> Deprecated: http://www.w3.org/community/openannotation/wiki/SE_Multiple_Semantic_Tags_an_Image

<Jacob> multiple bodies

PaoloC: If you look at the cookbook example, that shows this

<paoloC> Deprecated: http://www.w3.org/community/openannotation/wiki/Bookmarking_and_Tagging_a_Webpage

PaoloC: also this link
... multiple body, you have both content as text, and 2 tags

rob: what is the conclusion? doug asked: can we be more efficient?

PaoloC: unless you want multiple annotations (comment is made by one, tag by another), then you might have 2 selectors
... if prov is the same, there is one annotation, and multiple bodies

fjh: that makes sense to me

shepazu: If there is no other way, we should have a composite example:
... here is what an average annotation looks like, with all features

<fjh> ISSUE: add example showing annotation including tag + some text

<trackbot> Created ISSUE-18 - Add example showing annotation including tag + some text. Please complete additional details at <http://www.w3.org/annotation/track/issues/18/edit>.

shepazu: some stuff escaped me
... a general example would help

PaoloC: in the past, we were thinking about writing a primer
... what I see: If you show an integrated example
... it is difficult for people to understand the model
... so instead of polluting the spec, maybe we should make a primer?
... there are a lot of variations

<fjh> Updates needed to draft: status, abstract, context clarification, additional example

rob: my proposal: change multiple body/target example to one with one target, and one with content and a tag

PaoloC: I suggest the same

fjh: I want to go a FPWD to approve
... it seems logical to update the draft, then decide
... editors: could you make a new draft and send to the mailing list?

rob: I can do some stuff this afternoon, Doug can you give me your comments?

shepazu: tomorrow probably

fjh: I would suggest: rob, when all edits are in place, we start a CfC?

rob: I suggest: plea for additional comments on the list, to integrate then at the same time

<paoloC> +1

rob: we had a lot of missing people today, there might be a lot of issues
... give them the opportunity, before having a CfC

fjh: yes, ask for additional comments, integrate simple stuff
... more complex stuff: delay after FPWD

propose RESOLUTION: agree on shortname

<fjh> propose agree to shortname annotation-model

<azaroth> PROPOSAL: shortname is annotation-model

RESOLUTION: shortname is annotation-model

shepazu: it seems fine to me to make a resolution

rob: we can talk about a next f2f, we can talk about the social stuff

Social API Use Cases

shepazu: there are too many regrets to talk about next f2f

<fjh> follow up to TPAC, http://lists.w3.org/Archives/Public/public-annotation/2014Nov/0007.html

shepazu: about social:
... we talked with social group, there is some overlap
... basically, API and protocol stuff about publishing annotations
... that could be addressed by the Social Web WG
... They already published something
... Activity Streams 2.0
... I talked to the chair: how is the progress going, what process they were going to use to meet both needs?
... he proposed: review their use cases, to see where they missed something

<fjh> doug: social API effectively annotation publishing API

shepazu: It does not seem a rigorous approach
... let's find a set of people to create a publishing use cases doc, to make sure what they make meets our needs

azaroth: my concern with the Social WG, they are working on variety of topics
... we should better find a set of people to with both WG, to get in alignment

fjh: about joint use cases: we have a use case about annotations...
... their work would be very limited concerning annotations

shepazu: I don't think to dwell about the joint use cases, just put them together for us, send it to them, see what they can do with it
... let's come up with some use cases

fjh: there was some confusion about annotation vs activity streams: what is the target, what is the body
... we should clarify that

shepazu: maybe we should set up an informal call?

dwhly: question: about whether we might dogfood Annotator on the draft

<rayd> Do it!

<fjh> if we are ready ok, with me

shepazu: I would like to defer this to next week, to make sure we are ready
... maybe at the end of next weeks call?
... so that it does not consume telcon time

fjh: plan: FPWD, CfC once edits are completed
... Doug sends abstract
... agreed on shortname
... we will follow up on Social Web WG

Adjourn

<fjh> thanks bjdmeest for scribing!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-11-12 17:11:46 $