Telcon 2012-08-14

From http://titanpad.com/ywySVOdsH2

Open Annotation Telcon 2012-08-14

11 Attendees:

• Stian Soiland-Reyes
• Rob Sanderson
• Paolo Ciccarese
• James Smith
• Bob Morris
• Herbert Van de Sompel - following-by-pad
• Tim Cole
• Leyla Garcia
• Bernhard Haslhofer
• Dan Whaley
• Hugh Cayless

Regrets:

• Sebastian Hellmann

Chair: Rob
Minuting: Stian

Agenda (by Rob & Paolo) and Minutes

oa:Style proposal to move to Annotation

• Should it still be oa:hasStyle ? or just oa:styledBy? Or other?
  • Decision: oa:styledBy

• Should it move to OAX?
  • Core: Rob, Paolo, Stian, Tim
  • X: Bernhard, Bob
  • Decision: oa:Style oax:CssStyle

• Should there be a subclass for styled annotations? (and why?)
  • Decision: No, no requirement

• Is there a significant use case for XSLT transformations as styles for individual resources, as this is no longer possible in the proposal.
  • No use case

• The need for a CSS based Selector.
  • Yes, to go into OAX

Rob: Moved towards annotation. Making it easier to reuse a SpecificResource when it does not have style. Does not fit as nicely as state and context. Separate out how to display it. Any comments?

Paolo: Is there a link to the image showing how this would work?

Rob: http://www.openannotation.org/spec/proposals/proposal_style.png

James: Agree that it belongs on the annotation, not on the specific resource

?: the style is dependent on the thing being styled. With multiple targets you would need to associate it with the correct resource. A kind of applies-to?

James: It can't be reasoned over if the link to the resource being styled is embedded in the CSS

Rob: if it should be expressed in RDF rather than CSS.. then why move it from the specific target node?

James: To reuse the existing target. Yes, the Style would point into the target of the style. As an option.

Bob: In more general.. whenever you have multiple things that can be source of predicate, then the same kind of questions of how to say which one goes with which ones. In a manuscript we have.. there is no universally best way to do it. Cardinality restrictions, extra links, etc. Always get same argument about what you give up. My feeling is that for this multiplicity questions, there should be possible to have several kind of solutions with a best practice matter rather than a requirement on the ontology. Arguments on both sides.

Tim: What are we asking for the style? ?. If we expect people to comment on "No, I did not want the target to be red, it should be green", then we need to be able to refer to the colour of a target. If the annotator meant that when you show the annotation, these elements should be this colour, then attaching the CSS to the Annotation does that.

Rob: Any use case for it being in RDF?

James: So we don't have to parse the CSS to see what is styled. Decision on what you want to do with the information outside styling. Just styling will be given in both cases.

Paolo: So Target or Annotation. Sometimes you want to attach a colour, but why that colour is picked, it could just be a visualization. Some groups use them for coding, to say what is proteins, genes, etc. In their mind, as they export with a certain colour, then nobody else will of course understand what the colours are. In pure visualization, the other case there is deeper meaning behind the colours.

Paolo: Would argue that if there is a meaning, then it is a different kind of annotation saying what that meaning is. Colour is to keep track of it, but the meaning should be made explicit. In the other case, where an image is mainly black, and the colour is needed to make the annotation readable.

Bob: In graph theory yout alk about coloured graphs as a technical term, a kind of lable on the nodes with additional information. Already expressible in abstract.

Rob: So people feel generally that it is fine to attach it to Annotation for the purpose for the visualization - for more meaningful use of style/colours, then a different location/mechanism might be needed.

Paolo: Jim said he wanted to query styles and target a particular resource. In that case, most likely that is because there is a meaning behind the style. So querying for the meaning through the colour.

James: Yes, from my database/normalization side [eg good to be explicit about links]

Tim: Are colours associated with edges or nodes?

Bob: Duality, the roles could be reversed. Traditionally nodes. Colours don't necessarily have any visualization purpose, just a label. Like an abstract notation of a graph using set notation, where colours are just labels. But those labels are categorised in someway.

Tim: So in an annotation, ..., in a graph we tend to colour graph Note, .., etc. Trying to capture that in the graph.

Paolo: Bob said that we might need multiple mechanism. That is of course more complicated, but I see that using colours just for visualisation, then I would store it in the annotation node and figure it out so how. If that's a shortcut for something else, I might want to query it - and the mechanism to change. If you want you draw the link, or not. (?). We might need to do both.

Tim: second case, where I want the colours to be able to query them, then properties of my resource, might have to be specified in the OA, certain type of annotation, what do the colours do, this is a category of genes, etc. In many cases you would have an ontology they want to use instead.

Rob: So in order to move forward, we should distinguish between visualization and semantic shortcuts.

Paolo: Agree, solve visualization first. The other side of the story needs more work.

James: If style is only for visualization should stay outside of annotation. If OA has recommendation for style to be used only for visuatlization, and not semantics. If you are going to do that, use semantics, and then visualize it in the application.

Paolo: So is that totally somewhere elsE?

James: If you are trying to mark semantics, and then style based on that, that styling should be detached from the semantics. Say labelling with 5 ontologies, and one colour per ontology, then that should be provided by the application that does that.

Paolo: but what about interoperability, I send it to someone who does not know those colours

Bob: we argue that; in our extension of AO, that annotations moving around the network. The annotation has an expectation about what the users should do with it. Two kind of consumers: Publisher of original data, expected to take some action on some database (but their choice, of course). We hope that this gets expressable.

Bob: We don't think about style, just data. But someone who does care about the visualization is doing the same that we do about expectation - what Tim said, some purposes of annotations *are* for several parties to discuss in a certian visualization. The annotator has an expectation of appearance. Two people sitting at their screens, hoping it will look somewhat similar. See this as the same as someone annotating data with expectations on what they hope consumers will do.

Tim: If I have an image with black rectangle on black, I want to say that you should use a white rectangle.

Paolo: If visualization colours is up to domain and application, then we don't care bout exporting them. but if we expect the other end to see it, then I would attach it to the annotation node. But if it has deeper meaning, model it differently. (But still to annotation node).

Rob: And other clients might ignore it

Bob: Yes, we often accept that consumers might reject the expectation of the annotation, but might require them to explain why they rejected it; as a new annotation. A system with a lot of understanding that the consumer may very well have good reasons to not follow the style or other expectation.

Paolo: Do we agree that if the style is for visualization, then we move the current :hasStyle to the Annotation node? A proposal to change the name ; perhaps :styledBy? I think this would help the understanding. Or just :styled

Bob: It is reasonable for someone to want different styles on different targets, so you get this problem, need an intermediate way to express which style to which target/source.

Paolo: In the example in the picture we have a pointer to the style. With multiple targets you can say which styles. If multiple styles on same target, that is different.

Bob: Perhaps no need to express that relationship. I think Tim would agree that if you have multiple targets, then there might be multiple styles.

Tim: The idea is that you should not need to query that ; in CSS there are alredy selectors for this purpose. You just can't do anything semantically about it, can't query it as RDF.

James: All targets of the styles need well defined names then.

Rob: @document url(http://example.com/SPTarget/) {

   color: red; 

}

But Jim's argument is that you can't query ; Paolo says that if you have multiple styles, then what do you do. Follow one?

Paolo: Same problem in HTML. Multiple selectors for same thing? The last one wins. (Stian: or most specific..) - Would not do anything more than that.

James: Just need a warning ; this would not work with blank nodes as you can't refer to them from the style.

Rob: Do we want to use a different name than hasStyle? To distinguish from hasTarget/hasBody etc. - this is different. oa:style or oa:styledBy ?

James: styledBy more similar to other properties.

Rob: Move it to oax: or keep it in oa? Seems quite cross community and well thought-through, so perhaps just keep it.

Paolo: Keep it - specialized now.

Bernhard: Move it to extension. Not yet convinced about tte use case. Want to see that before we move it into core. Extension might be better at this stage.

Bob: That's also my argument.. don't know if there has been a good criteria for what goes in core or extension. An application that only implements core is useful to a large community, that is my criteria.

Rob: Current distinction is that core contains base classes, matching web architecture. Extension more specific to media types and other communities. I would therefore fall back on the core, as it comes from multiple communites. If it was specific to implementation.

Bob: Not talking about it required or not, but minimal or not.

Rob: Yes, but that is not the current split.

Stian: it should be in the core as it is a need shared by multiple communities but specific implementations like the CSSStyle should be in the extension.

Rob: Decision: As above for now?

Consensus: yes

(Stian: what was the properties? oa:style)

Rob: There was a suggestion for StyledAnnotations. I think not, what does it mean with a StyledAnnotation without a style.

Paolo: If I see an annotation and I want to style it ; I could do it as another annotation - that would be a StyledAnnotation!

Tim: Still confused about subclasses of Annotation. See them being used for many different things.

Rob: So is there an XSLTTransformation as style? Then we should have an oax:XSLTStyle saying how to style a particular resource - which you can't do in XSLT alone. Any other usecase?

(no)

Rob: Can use CSS as a selector , "everything with class .content" etc, as a Selector. oax:CSSSelector.

Support from Paolo, Stian, ?.

Chicago Meeting and other logistics

Tim: We've had contract with the same place as OAC had meeting a few weeks ago, a meeting room there. http://www.gleachercenter.com/

Club Quarters hotel on South Wacker, Gleacher Business School http://www.clubquarters.com/loc_chicagoWacker.php

$150/night.

Tim: Possible to get support from the foundation. But need to tell us before we get our of seats. About 30 spaces possible.

Tim: Would want to get a 1.0 version of the specification by the end of the year. Funding for next year. Any particular questions on logistics?

Bob: will you make the reservations or should we call Club Quarters ourselves?

Tim: We'll give them a list of people we know are coming to ensure they get the right rate. Anyone we're covering we're reimbursing. Jakob is following up with details on the next flight or not. Same with booking flights and then reimbursed.

Tim: We are signing contracts this week.

Rob: To reaffirm Tim, we would like to have all the fundamental stuff down to a recently degree at the end of the meeting, so Rob and Paolo can work on the next version of the document and be confident we won't have to rediscuss everything. Encourages everyone to come. We'll try to send notes to the mailing lists, and that kind of thing. By end of meeting would want to have a consensus about direction to move in.

Tim: On focus groups, trying to keep a master list of issues. And from there the individuals/groups to develop separate wiki page for those issues, so we can comment etc. ahead of the meeting. Then use that documentation. Might be some things that go into the FAQ to decide the decision/consensus.

Tim: I know I've added some issues to the list that came up in OAC. Would be talking to people about getting a shepherd for "their" issues.

Paolo: Can we say something about focus groups? Not sure everybody follows that.

Leyla: And how they would work..

Focus Groups

• Volunteers to lead focus groups on the different open issues, especially:
  • Versioning and Dynamic Annotations
  • Specification of State
  • Data/Semantic/Actionable Annotations
  • Semantics of Multiple Targets and Bodies

(please see http://www.w3.org/community/openannotation/wiki/Open_Issues )

Paolo: In last OAC meeting we identified topics important for different groups. Need to think about it, and compile reports on those topics, as possible options or ways to tackle those issues. Listed in the wiki, Open Issues. Other targets, multiple targets, etc. Few people working out solutions or way to go. Then have these documents ready as a week or 10 days before chicago meeting. Not sure if every topic is moving. Need to check.

Tim: What has worked well in the past is relatively small groups. Some by just emails, other to do smaller conference calls. We can show how to help. Skype. Any mechanism, but put on the wiki page so people can comment.

Tim: Only half the issues have list yet! So need to recruit people ; also from outside. Expect there to be a few more issues, but we want to keep it under control.

Paolo: What could happen is that if enough topics have been

(Scribe changes from Stian to Rob)

Rob: another call in two weeks time. Doodle poll on mailing list and close three days before the call. Will add Asian time zones as possibilities.

Paolo: SubClassing is still strange to many people. Keep it as it is for the moment. Bob -- thinking about motivation and expectation after meeting in boston, initially we tried but had reactions that made us go the way we are now. If we could have a motivation/expectation group, it might have an impact on the subclassing question.

Bob: Paul and I have been discussing the issues that come up with type as expression of motivation. We have a point of view.

Tim: Results that surprised us was the amount of other types of subclass use

Bob: Could be good or bad news :)

Paolo: Please contribute on the wiki or mailing list.

Bob: Favor wiki.

Rob: Please post a message to hte list when available

Tim: Anyone interested

Rob: Announce on the list to put names in the wiki

Bob: Data and semantics, actionable annotations -- very interested.

Leyla: Interested in that as well.

Tim: We need to add that one

(end of call)

Context

(postponed to the next call)

• How significant is the use case for annotating a resource with its own URI only when it appears in the context of another resource (eg image in HTML)?
• Is hasContext the right mechanism, and is it sufficiently expressive?
• Do we need a different mechanism for physically embedded files (eg image in ePub)?

Jim will post some new ideas on the list over the next couple of days

Publishing and Network Transport

(posponed to the next call)

• Which of: prov:alternateOf / skos:closeMatch / oa:equivalent / other?
• What status do we give to JSON-LD?
• Should the core/extension documents only express the model and the network layer be moved to a different document?