SW Coordination Group Telco

Ivan: Introducing Scott, Manu, David...

Admin

RESOLVED to accept: http://www.w3.org/2010/09/22-swcg-minutes.html

Next meeting

Ivan: will be in two weeks (as usual) - Wed Nov 17
... This will be meeting right after ISWC - so plan overview of what happened: Guus, Sandro, I will be there.
... W3C meetings are aligned with Boston time, so next meeting wll be same time (9am) in US as this week.

RDF Next proposed charter

Ivan: We had workshop in June. Lee, Scott, David, Ivan, Sandro and Guus were there.

<ivan> -> report of the workshop http://www.w3.org/2009/12/rdf-ws/Report

Ivan: Set up priority list what could be done in new version.
... Issues that could be taken up, with priorities.

<ivan> public questionnaire

Ivan: Followed by discussion in team - public questionnaire used the same entries as workshop, slightly reworded, collected 130 responses in one month
... Among respondees, not too academic. Based on questionnaire, charter proposal. Pleased that David and Guus will be co-chairs.
... Next Thursday at ISWC will give presentation - might be feedback - then will finalize and usual W3C mechanism kicks in - ask for votes....
... Could start end-January, early February - initial planning for two years.

David: Good summary.

<manu1> Charter says (FTE %: 20 each) -- but only gives 15% for two W3C Team contacts?

Ivan: Overall feeling of workshop, reflected in qstnnr - we know there are problems with RDF but let's try to minimize the changes.
... Looking at list, number of issues we decided not to put into charter. Tries to be minimalist.

Manu: A typo - charter says 15/20% team effort.

Ivan: 15% is maximum we can put in now.
... Going through each section...
... 2.1 Compatibility - graphs and entailments should remain valid. Too strong? People expect this.
... 2.2 Syntax: One thing not here - feeling that we will not touch RDF/XML (even if new features will come in). There is a general dislike of RDF/XML
... Someone said they _liked_ RDF/XML - a bit shocking :-)

Scott: Might have been me. Don't have problem with RDF/XML...

Ivan: Certainly need to put standard stamp on Turtle - also have to cross-check whether syntax and details fit with SPARQL.
... I personally don't think we should add anything significant, but standard status is important.
...High-priority: JSON syntax for RDF. If we want it to be used more by Web developers.
... In case of JSON, the charter...

<Zakim> manu1, you wanted to discuss JSON syntax for RDF.
...High-priority: In case of JSON, we allow in charter - might be some features not 100% mapped on JSON if it gets too complicated.

<manu1> http://json-ld.org/

<manu1> http://json-ld.org/spec/ED/20101024/

Manu: Mark Birbeck and I noodling around with JSON-LD - put up Website and mailing list, discussions over past months - Ian Davis and Richard Cyganiak - healthy discussion - very much aligned with this RDF WG serialization - we have spec with alot of same features as RDFa - meant to express RDF in JSON in way that's easy for Javascript users - would be good to look at this...

<davidwood> Talis also has a JSON syntax: http://n2.talis.com/wiki/RDF_JSON_Specification

Manu: Our company will deploy this by the end of the year. Have to make sure it expresses RDF pretty cleanly.

Ivan: I know this. Didn't put explicit references into charter. Know three different possible inputs: yours, IanD's, and Sandro's JSON syntax. On my slides for ISWC, list Manu. Not sure whether this should actually go into charter.

Manu: The doc is under a CC license - would be happy to move to W3C as starting point.

Ivan: One more thing not in charter: during discussion at workshop, even on qstnnr, profile mechanism for RDFa came up as possible technology we might want to add to Turtle or JSON or both. Not in charter, but.

David: Atom?

<Zakim> manu1, you wanted to discuss syntax and MongoDB/document-based storage systems.

Ivan: In previous version, issues around Atom - in meantime, discussion in Lyon - certain company may not commit to this work.

Manu: Tie-in with mongo-db and document-based storage systems. Interest in JSON-LD from group not traditionally interested in RDF. Not graph stores but alot use JSON to get info in and out of databases.
... mongo-db think in terms of RDF but not introduced to it.

Ivan: Must separate things that go into charter from broader issues we need to discuss. If you say they are using a JSON formalism, important to reach out to this community. May not be mature enough to be separate item in charter.
... "Named graphs" "Quoted graphs"...

<manu1> What about disjoint graphs - subclass of named graphs?

<manu1> blank graphs?

Ivan: several things relate to this feature. Semantics are not clear. Maybe we have several variants. Working group will need to clean up notions. What SPARQL does. Etc.

<manu1> http://json-ld.org/spec/ED/20101024/#disjoint-graphs

<mscottm> I think of graphs with URI's, so that you can talk about the graph and its provenance.

Ivan: See this as being the most controversial and complicated item to be done in the working group.
... Named Graph would have impact on syntax (Turtle, JSON) - should be able to express.

<Zakim> davidwood, you wanted to discuss named graphs in Turtle

<manu1> +1 - agree with David, we really need to consider named graphs in each syntax.

<LeeF> I also agree

David: My biggest fear - if we do not address in common syntaxes, will have impact on alot of implementations and storage systems, will have to take in graph identifier in some non-standard way. Is it worth the pain to put in syntax optionally. Must seriously consider.

Ivan: Do you mean that the syntax for NG in Turtle should be optional?

<LeeF> Oh wait, maybe I don't agree :)

David: Making it mandatory would break old implementations - would be out of compliance with charter. But we want to introduce feature in new Turtle standard so that if you want to name graph, can.

<LeeF> FWIW, speaking as a vendor/W3C member (rather than a CG member), I'm strongly strongly strongly in favor of basing named graph syntax on TriG

David: No stomach to deal with RDF/XML, so only JSON left.

Ivan: We have N3, way to express NG in SPARQL - and two syntaxes not same.

Guus: We are already going into WG discussion. It's a main rationale. Good thing: implementations have looked at ways to handle this. Clear need.

Ivan: We may end up having two different notions of NG. Are they immutable? Can they change?

<mscottm> immutable triples is a much higher demand than naming a knowledge base (of course).

Manu: Write language for what's a NG - alot is already in RDFa spec.

Ivan: We should not put input documents into the charter.
... Other things listed: errors accumulated since 2004. IRIs versus URIs. Effect of using IRIs needs to be clarified.

<mscottm> Using URI's to refer to a knowledge base (or RDF graph) could be considered a best practice rather than a specification. Although, you don't get very far with a string (!) as an identifier for a graph.

Ivan: One point: that other W3C recs produced things that should be part of core RDF/RDFS document - might be good idea to collect references. OWL WG introduced literals as datatypes.
... [Lists groups that extended RDF] - need to bring this existing work together, not re-do. Something like Horst semantics as part of standard would make sense.
... Alot of discussion at WS and elsewhere on deprecating features. Top two: reification and containers. Is in charter: "weakly deprecate" (listing these as examples). Deprecation does not mean we take them out of the language because we do not want to break existing graphs, e.g., XMP.
... Two other things: took over SPARQL terminology - "if we have time and energy" but if not, ok w.r.t. charter.

<LeeF> You can do it with a FILTER, also.

<LeeF> Right.

Ivan: When you do SPARQL queries, problem: string can be plain literal or w/datatype or xxx - today, have to consider all options.
... Number of features arising: not clear whether they should be recommendation-level. Probably want to make thorough update of RDF primer. What follow your nose means. Things that are part of practice, should be written up. Examples are old. Work to be done on RDF primer.
... Comments?
... Restrictions in current RDF. Literal as subject discussion - two extreme positions.

<davidwood> What was the third RDF JSON syntax discussed? Talis', Manu's and which other?

Ivan: because of extreme positions, we felt this is something that does not have community consensus.
... Probably the most controversial item on the mailing list.
... Lee? In SPARQL, discussion of removing these restrictions, but SPARQL does not have in rec?

Lee: SPARQL _does_ allow literals in subject position, but does not match graphs.

Ivan: Curious what reaction of community will be - whether there will be strong push to add to charter.

<LeeF> In the SPARQL grammar, the subject of a triple can be (among other things like variables) one of these http://www.w3.org/TR/rdf-sparql-query/#rGraphTerm

David: Discomfort about this.

Ivan: It would screw up RDFa - big-time. Could not express in RDFa.
... Whole issue about semantics of b-nodes. Get rid of model-theoretic sematnics altogether?
... WS saikd: We have learned to live with it - let's not touch.
... David, Sandro had thoughts on JSON serialization - see blog.

<manu1> http://decentralyze.com/2010/06/04/from-json-to-rdf-in-six-easy-steps-with-jron/

<manu1> I think that's Sandro's try at RDF/JSON

<danbri> [I can't see RDF's woes being addressed by fiddling with the core design; better to have funding to improve the tooling ...]

Scott: Interesting discussion on the Dutch SW Mailing list, Peter Boncz.

<danbri> (you all saw Jeni Tennison's http://twitter.com/#!/JeniT/status/29554923286 slides? )

<davidwood> Jeni++

Lee: Would prefer that charter not say that syntax for NG be based on N3 and SPARQL - we would prefer that it be based on Trig

Ivan: We can not ignore the SPARQL syntax.

Lee: Cannot use SPARQL to exchange graphs - people use Trig.
... Can we simply say a syntax is needed without specifying what it should be based on?
... From charter standpoint, satisfied if Trig listed as possibility.

Ivan: Can live with that.

<LeeF> TriG - http://www4.wiwiss.fu-berlin.de/bizer/TriG/

Ivan: "syntax should take into account..." all of these.

David: Could imagine WG taking Trig and Turtle as input into Turtle.