<trackbot> Date: 12 November 2014
<fjh> ScribeNick: bjdmeest
fjh: reviews agenda
<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
<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
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
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
<fjh> thanks bjdmeest for scribing!