Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-11-11
From RDFa Working Group Wiki
See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.
14:50:45 <RRSAgent> RRSAgent has joined #rdfa 14:50:45 <RRSAgent> logging to http://www.w3.org/2010/11/11-rdfa-irc 14:50:47 <trackbot> RRSAgent, make logs world 14:50:49 <trackbot> Zakim, this will be 7332 14:50:49 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 10 minutes 14:50:50 <trackbot> Meeting: RDFa Working Group Teleconference 14:50:50 <trackbot> Date: 11 November 2010 14:51:03 <manu> Present: Manu, Knud, Nathan, Toby, ShaneM 14:51:08 <manu> Regrets: Steven, Ivan 14:54:02 <manu> Chair: Manu 14:54:05 <manu> Scribe: Manu 14:54:06 <manu> scribenick: manu 15:00:31 <Zakim> SW_RDFa()10:00AM has now started 15:00:41 <Zakim> + +3539149aaaa 15:01:02 <Knud> zakim, aaa is me 15:01:02 <Zakim> sorry, Knud, I do not recognize a party named 'aaa' 15:01:11 <Zakim> + +1.540.961.aabb 15:01:16 <manu> zakim, I am aabb 15:01:16 <Zakim> +manu; got it 15:01:18 <Knud> zakim, I am aaa 15:01:18 <Zakim> sorry, Knud, I do not see a party named 'aaa' 15:01:23 <ShaneM> ShaneM has joined #rdfa 15:01:32 <Knud> zakim, I am aaaa 15:01:32 <Zakim> +Knud; got it 15:03:15 <tinkster> tinkster has joined #rdfa 15:08:56 <Zakim> + +1.441.592.aacc 15:09:13 <nathan> zakim, i am +1.441.592.aacc 15:09:13 <Zakim> +nathan; got it 15:11:18 <Zakim> -nathan 15:13:03 <Zakim> +[IPcaller] 15:13:22 <nathan> Zakim, i am +[IPcaller] 15:13:22 <Zakim> sorry, nathan, I do not see a party named '+[IPcaller]' 15:13:32 <nathan> Zakim, i am ? 15:13:32 <Zakim> sorry, nathan, I do not see a party named '?' 15:13:34 <manu> zakim, IPcaller is nathan 15:13:34 <Zakim> +nathan; got it 15:15:05 <manu> Shane and Toby are IRC-only - Shane is having dial-in issues. 15:15:08 <manu> Topic: Hand-authoring RDFa 15:15:18 <manu> Knud: Did a presentation this monday to non-technology folks on RDFa 15:15:34 <manu> Knud: Reminded how difficult it is for non-techies to grasp the concept of RDFa. 15:16:02 <manu> Manu: Perhaps we should focus more on telling people that RDFa is easier for people that are non-techies if they use a CMS system to publish it - like Drupal or WordPress. 15:16:11 <manu> Knud: Perhaps we should put something in the RDFa Primer outlining this 15:16:18 <manu> Manu: Good idea. 15:16:23 <manu> Topic: ISSUE-52: Lightweight DataStore aligned with ECMAScript 15:16:53 <manu> Manu: I think we're close, let's go through this one by one. 15:17:01 <manu> ISSUE-51 moves the create*** methods from DataStore to DataContext. 15:17:15 <manu> Manu: I think that's a good idea... nobody seemed to have an issue w/ that. 15:17:35 <manu> Nathan: I don't think anyone has an issue w/ that - don't know. 15:17:46 <manu> This interface may need to be named RDFGraph an used to represent a graph 15:18:44 <manu> Manu: Definitely agree w/ this - rename DataStore to RDFGraph. Push DataStore to W3C Note. 15:18:59 <manu> Knud: I thought we didn't want to put RDF on the front of the names? 15:19:53 <manu> Manu: Ah yes, we did remove "RDF" from the name 15:20:00 <manu> Manu: What about Graph or DataGraph? 15:20:13 <manu> Nathan: I think we have a clear separation from Data* and other concepts. 15:20:27 <manu> Nathan: I don't think that Data makes sense - either Graph or RDFGraph. 15:21:36 <manu> Manu: How about Graph? 15:21:47 <manu> Knud: Hmm, we did discuss this. 15:22:02 <manu> Manu: Yes, we did remove 'RDF' from the front of names - but this isn't a generic Graph. 15:23:28 <manu> Nathan: It's only the name of the interface - not that big of deal. 15:23:40 <manu> Manu: Yes, but we do want to make sure there is a natural grouping. 15:23:56 <manu> Manu: Leaning heavily towards RDFGraph, then. 15:23:58 <manu> Nathan: Me too. 15:24:00 <manu> Knud: Ok 15:24:37 <manu> Knud: We specify in the goals that we want to support non-RDFa parsers... Microformats, Microdata. 15:25:00 <manu> Manu: We do support that stuff, but they must be converted to triples to be stored. 15:25:24 <manu> This proposal/issue aligns DataStore methods with ECMAScript-262 v5 to provide a familiar lightweight store which is constrained to remove unexpected functionality. 15:25:55 <manu> Manu: These are the array additions to ECMA v5: https://developer.mozilla.org/en/New_in_JavaScript_1.6#Array_extras 15:26:20 <manu> Manu: We don't support map() 15:26:24 <manu> Manu: Any reason for that? 15:26:53 <manu> Nathan: That functionality would be almost impossible to implement over a triple store. 15:27:00 <manu> Nathan: It's very complex 15:27:00 <toby> I have to go, but am generally happy if we accept all of Nathan's proposals. Think moving the createX methods to DataContext is especially important - ISSUE-51. 15:27:32 <manu> Nathan: I thought we might as well provide toArray() - that would allow them to define map(). 15:28:13 <manu> Manu: I don't understand why this is difficult to do. 15:28:56 <manu> Nathan: I think that if we provide map(), we should provide reduce() - reduce() is the hard part. 15:28:59 <nathan> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/reduce 15:29:37 <manu> Nathan: if we have map(), we should have reduce() and reduceRight() 15:29:54 <manu> Nathan: Those are v. difficult to do, and we provide a mechanism for them to do this via toArray(). 15:30:12 <manu> Manu: Sounds good to me. 15:31:12 <manu> Nathan: unsure about mentions(), iterator(), merge() 15:31:24 <manu> Manu: Let's talk about mentions() 15:31:47 <manu> Manu: If it exists in subject, predicate or object, you get true? 15:31:50 <manu> Nathan: Yes. 15:32:21 <manu> Manu: One other way was just subject or object - but that seems arbitrarily limiting. 15:32:28 <manu> Nathan: Yes, right. 15:33:03 <manu> Manu: I'm fine w/ it operating on subject, predicate and object. 15:33:06 <manu> Knud: I agree. 15:33:17 <manu> Manu: Let's discuss iterator() 15:33:55 <manu> Nathan: Question as to whether it is required in the first place or not. 15:34:42 <manu> Nathan: No way to do a iterate in Javascript - .forEach(), .iterator(), .toArray() 15:36:03 <nathan> for(x in graph) 15:36:21 <manu> Nathan: There is no way to do that in JavaScript 15:37:08 <nathan> ir = graph.iterator(); while(it.hasNext()) { triple = it.next() } 15:37:46 <nathan> graph.toArray() <-- much easier 15:38:34 <manu> Manu: While it does make it nicer, it's not absolutely necessary. 15:39:44 <manu> Manu: This would be most useful in language that doesn't support dynamic functions/closures. 15:39:46 <nathan> process() 15:39:56 <nathan> Class Process { function process(); } 15:41:18 <manu> Manu: I say keep it out for now, we already have multiple mechanisms to iterate over a graph. 15:41:38 <manu> Knud: Don't see a reason to have it in, no strong feelings on that. 15:42:02 <manu> Nathan: Let's keep it out for now, but if we need it in the future, we can put it in there. 15:42:12 <manu> Manu: Let's discuss merge() 15:43:32 <nathan> Array.concat() 15:43:40 <manu> Nathan: To do this properly in JavaScript - you have .concat() 15:44:40 <manu> Nathan: I think the merge() we're talking about is more like an addAll() 15:45:15 <manu> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array 15:46:06 <nathan> my preference: var mergedgraph = graph.merge(otherGraph); 15:47:38 <manu> Manu: Maybe people will just use .parse() w/ the same graph to do an in-place merge. 15:47:58 <nathan> or.. var graph = graph.merge(otherGraph); 15:49:31 <Knud> sort() and sort!() 15:49:41 <manu> Knud: Ruby has a convention that supports both - inplace and copy 15:50:03 <manu> Nathan: JavaScript has options for in-place and return a copy too 15:50:46 <manu> Manu: Any strong objections to supporting both? 15:50:53 <manu> Knud: If people are going to have both, we should do that. 15:51:21 <manu> Nathan: well, this is a bit strange for JavaScript 15:51:33 <manu> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/push 15:52:13 <manu> Nathan: difficult to implement - one is computationally expensive. 15:54:47 <manu> Manu: No way to get around the computationally expensive issue - we can't have duplicate triples, etc. 15:55:00 <manu> Knud: BlankNode merging must also be taken into account, generate new identifiers. 15:55:08 <manu> Nathan: Memory issue is the only thing to be concerned about 15:55:40 <manu> Nathan: If we take the approach where it imports, how would one put two graphs together to create a new one? 15:56:16 <nathan> with graph.import 15:56:43 <nathan> c = createGraph(); c.import(a); c.import(b) 15:56:58 <nathan> c = a.merge(b) 15:57:00 <nathan> or 15:57:06 <nathan> a = a.merge(b) 15:58:39 <nathan> or we can define import() and merge() 15:59:23 <manu> Manu: Any objections to just supporting .merge() right now, which returns a new Graph. 15:59:25 <nathan> prefer "RDFGraph merge(in RDFGraph graph);" 15:59:50 <manu> Knud: We should point out in the spec that this is always computationally expensive as well as expensive from a memory standpoint. 16:00:24 <manu> interface RDFTripleCallback 16:00:28 <manu> Manu: Looks good 16:00:33 <manu> Nathan: Yep, pretty simple. 16:00:38 <manu> interface RDFTripleFilter 16:00:44 <manu> Everyone seems to think that's fine. 16:01:13 <manu> Manu: Have we covered everything in the proposal, Nathan? 16:01:16 <manu> Nathan: Yes, we have. 16:01:40 <manu> Manu: I'll put together a proposal to close this issue. 16:01:45 <manu> Manu: I'll also propose to close ISSUE-51. # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000135