Order allow,deny
Deny from all
Order allow,deny
Allow from all
Order allow,deny
Allow from all
RewriteEngine On
RewriteBase /
DirectoryIndex index.php
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Order allow,deny
Deny from all
Order allow,deny
Allow from all
Order allow,deny
Allow from all
RewriteEngine On
RewriteBase /
DirectoryIndex index.php
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
13:58:29 RRSAgent has joined #rdfa
13:58:29 logging to http://www.w3.org/2011/04/28-rdfa-irc
13:58:31 RRSAgent, make logs world
13:58:31 Zakim has joined #rdfa
13:58:33 Zakim, this will be 7332
13:58:33 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 2 minutes
13:58:34 Meeting: RDF Web Applications Working Group Teleconference
13:58:34 Date: 28 April 2011
13:58:45 Chair: Manu
13:58:58 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Apr/0160.html
14:01:05 Zakim, code?
14:01:05 the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), MacTed
14:01:10 Zakim, who's here?
14:01:10 SW_RDFa()10:00AM has not yet started, MacTed
14:01:11 On IRC I see RRSAgent, tomayac, Steven, MacTed, danbri, Benjamin, ivan, webr3, manu1, manu, trackbot
14:01:17 Zakim, this is 7332
14:01:17 ok, MacTed; that matches SW_RDFa()10:00AM
14:01:21 Zakim, who's here?
14:01:21 On the phone I see tomayac, Benjamin, OpenLink_Software
14:01:22 On IRC I see RRSAgent, tomayac, Steven, MacTed, danbri, Benjamin, ivan, webr3, manu1, manu, trackbot
14:01:28 Zakim, OpenLink_Software is temporarily me
14:01:28 +MacTed; got it
14:01:30 Zakim, mute me
14:01:30 MacTed should now be muted
14:01:40 +??P14
14:01:50 zakim, I am ??P14
14:01:50 +manu1; got it
14:02:01 zakim, dial ivan-voip
14:02:01 ok, ivan; the call is being made
14:02:01 Zakim, unmute me
14:02:02 MacTed should no longer be muted
14:02:02 +Ivan
14:02:08 ShaneM has joined #rdfa
14:02:49 +??P15
14:02:56 zakim, ??P15 is ShaneM
14:02:56 +ShaneM; got it
14:03:23 +[IPcaller]
14:03:30 Zakim, i am IPcaller
14:03:30 ok, webr3, I now associate you with [IPcaller]
14:04:07 scribenick: MacTed
14:04:10 Scribe: Ted
14:04:49 zakim, dial steven-work
14:04:49 ok, Steven; the call is being made
14:04:51 +Steven
14:05:24 http://www.w3.org/mid/A0CD95FB-1D6F-43A1-8547-20A3D0E8C8BA@kit.edu
14:06:11 lol, yeah i replied too: http://lists.w3.org/Archives/Public/semantic-web/2011Apr/0214.html
14:06:24 Topic: RDF API and RDFa API
14:06:42 Danny -> http://www.aifb.kit.edu/web/Denny_Vrandecic/en
14:07:21 Ivan: Danny is working with Wikipedia
14:07:51 Denny Vrandečić
14:08:41 Gavin Carother's did a Python API as well
14:09:10 ivan: how far are we from API used in Tabulator?
14:09:23 webr3: rather far...
14:10:00 s/rather far/ quite close but with different method names and definitions/
14:10:48 Topic: Linked JSON Mailing List
14:11:44 RDF WG decided that JSON serialization was beyond immediate scope
14:11:54 manu: kit.edu
14:12:03 manu: RDF WG decided that JSON serialization was beyond immediate scope
14:12:56 manu: has been talking with others outside of RDF WG group, and several within, who are interested in this work
14:13:39 manu: Gavin Carruthers (sp?), Richard Cyganiak, Glenn McDonald (sp?), Harry Halpin... others
14:13:58 mailing list works now
14:14:23 webr3: Linked JSON mailing list is up and running
14:14:31 (link to same?)
14:15:20 mailing list: http://lists.w3.org/Archives/Public/public-linked-json/
14:15:23 manu: hopes we'll all populate the list, and then decide how to focus the work -- tangible goals, etc., starting from stripped down spec
14:15:48 s/spec/JSON LD spec/
14:16:14 webr3: also focused on Point Of Interest group right now
14:17:10 +1 for getting the nyt people involved
14:17:11 manu: thinks NYT could be enlisted for that group
14:17:28 manu: Brian Allen (sp?) at Twitter also potentially interested
14:18:35 Topic: RDF API
14:18:38 http://www.w3.org/2010/02/rdfa/sources/rdf-api/
14:19:28 -1 for separate document
14:19:32 +1
14:19:34 q+
14:19:37 webr3: 3 levels of API seem to be sketched out, (re)organization needs some work
14:20:33 ivan: favors separate docs for Developer, User, (third leve?) to avoid scaring people with details unnecessary to their purposes
14:20:41 +1 i have to admit
14:20:49 q+
14:20:54 ack ivan
14:20:55 q-
14:21:07 ivan: best to have documents that cover reader's needs without overwhelming
14:21:18 q+
14:21:23 ack manu1
14:21:45 manu: prefers to have one document so whole API can be seen in one place, rather than having scattered jigsaw puzzle pieces
14:22:20 +1 for one doc, as IMHO people who just want to code a mash-up won't read either...
14:22:21 (I favor clearly distinct, relatively standalone sections within one doc...)
14:22:34 ack ivan
14:22:40 q+
14:23:24 q+ to say that the OWL2 docs are very difficult to follow
14:23:31 ivan: examples of broken up docs include OWL2, RIF -- they have one small doc which sketches how the other docs work together
14:23:51 ack IPCaller
14:23:57 ack [IPCaller]
14:23:59 Zakim, [IPcaller] is webr3
14:23:59 +webr3; got it
14:24:45 webr3: very much feels splitting is needed, between tool makers and tool users
14:24:59 -> http://www.w3.org/TR/owl2-overview/ example for an overview document
14:25:22 webr3: lots of examples are needed, and a single doc will balloon
14:25:25 ack web3
14:25:54 manu, that could be the subject matter though.. OWL 2 is quite high level
14:26:04 ack manu1
14:26:04 manu1, you wanted to say that the OWL2 docs are very difficult to follow
14:26:12 manu: diagram example makes sense, but the need for the diagram expresses the argument not to split...
14:26:40 ivan: OWL2 is an example of how to do, not a picture of just what would happen here
14:27:38 q+ to discuss what would go into this 2nd level document?
14:27:49 ivan: RDFa esoterica (bnode, deep rdf discussions, 303, etc.) is likely to scare away the people we very much don't want to scare away
14:27:57 ack manu1
14:27:57 manu1, you wanted to discuss what would go into this 2nd level document?
14:28:09 manu: what would go in second level doc?
14:28:09 manu, imho - RDFa API but for general RDF
14:28:43 2nd level -> "a read only RDF API for end developers, like the RDFa API"
14:28:44 ivan: projection; document data interface; equivalent of RDFa environment (query, reference to RDF environment)
14:28:50 q+ to recommend popular linked data use cases be backed by the second lewvel api
14:28:58 ack Benjamin
14:28:58 Benjamin, you wanted to recommend popular linked data use cases be backed by the second lewvel api
14:29:03 Benjamin +1
14:29:24 q+ to discuss charter scope?
14:29:25 Benjamin: remembering, RDFa API was originally named Linked Data API ...
14:29:38 Benjamin: thinks we should create this second level API
14:29:59 ack manu1
14:29:59 manu1, you wanted to discuss charter scope?
14:30:11 manu: are we chartered to work on such a second doc? are there toes we're going to step on?
14:30:14 q+
14:30:17 RDF Core API?
14:30:32 q-
14:30:34 ivan: RDF Core API, RDF API ... we can play around with names
14:30:41 or "RDF Interfaces"
14:30:49 q+
14:30:51 +1 to RDF Core API and another RDF API doc
14:30:52 for this api that is, and new one as "RDF API"
14:31:44 macted: "Linked Data API" would imply that "RDF" is all there is to "Linked Data" ... which isn't the case
14:31:57 q?
14:32:00 act tomayac
14:32:03 ack tomayac
14:32:08 manu: anyone with other concerns about splitting this?
14:32:53 tomayac: people outside w3c are unlikely to look at these docs anyway... why are we concerned with addressing them?
14:33:05 tomayac, that would be sad if they don't imho - I'd want this doc to be focussed for those people, and if we are doign docs wrong, lets change that
14:33:14 ivan: that seems to ask "why do this at all?"
14:33:48 ivan: hopefully, if we do this well, letting people quickly do simple/easy things, without having to immediately dive into difficult things, that's a win
14:34:06 ivan: this will expose them to other things they may want to do, which require they learn the complex stuff, but that's OK
14:34:31 in my experience, all js coders search for js docs by $searchterm +mdc to make sure the mozilla docs come up. i can imagine something similar to happen for a browser-vendor-implemented rdfa api.
14:34:48 ivan: for instance, quick-and-dirty read-only joins of DBpedia with Gene Data should be enabled by these docs
14:35:10 toayac, i do that :p lol +mdc
14:35:18 q+
14:35:28 manu: "+mdc" search term isn't that common in my experience
14:35:53 ivan: we should realize that w3c is currently developing *MANY* APIs ...
14:36:11 ivan: and if people are relying strictly on mozilla docs, then this is pointless ... which doesn't seem true
14:36:52 ivan: if we have the Core, others can implement extensions and other layers atop the Core to empower other uses
14:36:56 q+
14:37:00 ack ivan
14:37:02 ack ivan
14:37:03 ack webr3
14:37:30 webr3: reiterating ivan's point, we build the Core / bare minimum that community can then build upon
14:37:47 to put it the right way: i was talking about core js, which mdc does a great job on documenting it, no one goes to the ecma script spec for simple questions
14:37:50 q+ to say that people may want to add stuff to the RDF API (not RDF Core API)
14:37:58 webr3: we can then standardize/unify the things which others innovate and implement differently
14:38:22 ack manu1
14:38:22 manu1, you wanted to say that people may want to add stuff to the RDF API (not RDF Core API)
14:38:43 manu: another pro for the split is we can standardize RDF Core and few will want/need to change that
14:38:52 manu: RDF Core - literals, graphs, nodes, etc.
14:39:09 manu: RDF API - query mechanisms, document interface(s), etc.
14:39:21 +1 agree
14:39:26 +1
14:39:27 manu: future innovation is expected to take place in RDF API, not in RDF Core
14:39:44 q+ to bring focus back
14:39:58 ack webr3
14:39:58 webr3, you wanted to bring focus back
14:39:58 ivan: RDF Core will basically reflect RDF concepts in JavaScript
14:40:18 s/RDF Core/RDF Core API/
14:40:27 webr3: 1. are we going ahead with two docs?
14:40:43 webr3: 2. if so, we need to change the name from "RDF API" now...
14:40:50 PROPOSAL: The current RDF API document should be split into two documents - the RDF Core API and the RDF API
14:41:10 webr3: 3. are we getting rid of tripleset; are we sticking with node-node-node definition or constraining to RDF; etc?
14:41:19 +1
14:41:19 +1
14:41:21 +1
14:41:25 +1
14:41:26 +1
14:41:27 +0
14:41:28 +1 but review name
14:41:45 (I don't like the name RDF Core API really)
14:41:50 Don't feel strongly in this case
14:41:52 RDF Core API, or RDF Interfaces ?
14:41:55 +0 name strange
14:42:50 lol
14:42:51 naming confusion...
14:43:06 XHTML+RDFa, HTML+RDFa, RDFa Core, RDF Core API, RDF API, and RDFa API
14:43:07 +1 to what ivan just said
14:43:28 RDF Interfaces, RDF API, RDFa API
14:43:38 sounds good
14:43:40 "RDF Core API" becomes "RDF Interfaces API"; keep "RDF API" and "RDFa API"...
14:43:44 RESOLVED: The current RDF API document should be split into two documents - the RDF Interfaces and the RDF API
14:44:15 s/"RDF Core API" becomes "RDF Interfaces API"/"RDF Core API" becomes "RDF Interfaces"/
14:44:46 Subtopic: Removing Triple Set / Graph Literal
14:44:56 q+ to discuss removing Graph Literal
14:45:01 -Benjamin
14:45:35 ivan: what we said... (roughly) "the RDF WG is currently discussing the notion of graph identification. this WG will act based on their decision."
14:46:20 ack manu1
14:46:20 manu1, you wanted to discuss removing Graph Literal
14:46:50 + +44.123.456.aaaa
14:47:01 zakim, i am aaaa
14:47:01 +Benjamin; got it
14:47:19 [discussion of undefined term "Graph Literal"]
14:47:37 q+
14:47:44 ack MacTed
14:48:17 Ted: We don't need to define everything - we can use an ambiguous term for the time being
14:48:41 Ted: We just say that we are not defining it, but we're putting it in as a placeholder.
14:49:00 Ivan, placeholder text, or interface with a note?
14:49:02 Ted: It's up to the RDF WG to define this stuff, we make that clear in the document
14:50:21 Ivan: Defining WebIDL that states that a Triple Set extends a Node and a Literal, it makes a technical decision, it oversteps our bounds
14:50:22 q+
14:50:37 Ivan, as you said "what is the datatype" :p (not does it have a datatype)
14:50:47 Ted: But why can't we just put a warning stating that the interface could change over time, based on what RDF WG finds.
14:51:16 ack Benjamin
14:52:05 Benjamin: I think we should model RDF Interfaces by what has general consensus ... since this doesn't have general consensus, maybe it's not "core" yet?
14:52:23 q+
14:52:47 we can define them (TripleSet/GraphLiteral) as extensions to the RDF Interfaces, just like OWL, or entailment, or SPARQL might
14:52:55 (at a later date)
14:52:55 manu: seems like this will belong in RDF Interfaces once it's defined, so putting it outside "for now" is troublesome
14:53:28 ack ivan
14:54:27 ivan: handwave is what's called for here
14:55:28 ivan: already because SPARQL does some loose association here, adding something about a "graph may have a URI" seems appropriate
14:57:03 +1
14:57:04 PROPOSAL: The RDF Interfaces should mention a Graph identification concept, but should not specify any WebIDL yet - we should note that the RDF WG is currently discussing the details of this mechanism.
14:57:08 +1
14:57:14 +1
14:57:23 +1
14:57:23 +1
14:57:26 +0
14:57:27 ..... +1
14:57:27 +1
14:57:56 Steven: has no strong feelings... hence +0
14:58:09 all that's left is: (node node node) or (rdfresource, namednode, node)
14:58:32 ivan: 2 things remaining...
14:58:40 and: literal needs to keep lexical form from a serialization for comparison
14:58:43 -ShaneM
14:58:51 [discussion of remaining...]
14:59:15 Subtopic: Generalized Triples
14:59:41 sorry - had to bail.
14:59:42 ivan: webr3 found good set of argumentation why we would keep with (node node node) approach
15:00:15 ivan: thinks we should do so, include that text, and see whether community jumps at us
15:00:51 webr3: basic argument is to allow more flexible code use/writing
15:01:16 ivan: what is "literal as predicate"?
15:01:29 manu: use case is in JSON conversions
15:01:38 so does anybody object to node,node,node ?
15:02:04 PROPOSAL: keep (node node node)
15:02:07 +1
15:02:09 +1
15:02:09 +3
15:02:11 +1
15:02:13 +1 for keeping node^3
15:02:14 +1
15:02:16 +1
15:02:28