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
14:51:08 <manu> Regrets: Steven, Ivan
14:54:02 <manu> Chair: Manu
15:00:31 <Zakim> SW_RDFa()10:00AM has now started
15:00:41 <Zakim> + +3539149aaaa
15:00:51 <Knud> aaaa is me
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 <webr3> zakim, i am +1.441.592.aacc
15:09:13 <Zakim> +webr3; got it
15:11:18 <Zakim> -webr3
15:13:03 <Zakim> +[IPcaller]
15:13:22 <webr3> Zakim, i am +[IPcaller]
15:13:22 <Zakim> sorry, webr3, I do not see a party named '+[IPcaller]'
15:13:32 <webr3> Zakim, i am ?
15:13:32 <Zakim> sorry, webr3, I do not see a party named '?'
15:13:34 <manu> zakim, IPcaller is nathan
15:13:34 <Zakim> +nathan; got it
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> 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> 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: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 <webr3> 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 <webr3> for(x in graph)
15:36:21 <manu> Nathan: There is no way to do that in JavaScript
15:37:08 <webr3> ir = graph.iterator(); while(it.hasNext()) { triple = it.next() }
15:37:46 <webr3> 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 <webr3> process()
15:39:56 <webr3> 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 <webr3> 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 <webr3> 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 <webr3> 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 <webr3> with: graph.import
15:56:43 <webr3> c = createGraph(); c.import(a); c.import(b)
15:56:58 <webr3> c = a.merge(b)
15:57:00 <webr3> or
15:57:06 <webr3> a = a.merge(b)
15:58:39 <webr3> or we can define import() and merge()
15:59:23 <manu> Nathan: Any objections to just supporting .merge() right now, which returns a new Graph.
15:59:25 <webr3> 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:03:49 <manu> Manu: I'll also propose to close ISSUE-51.
16:04:01 <manu> Nathan: Yep, that one is a no-brainer, not changing it as this point causes more issues.
16:04:12 <Zakim> -manu
16:04:13 <Zakim> -Knud
16:04:15 <Zakim> SW_RDFa()10:00AM has ended
16:04:17 <Zakim> Attendees were +3539149aaaa, +1.540.961.aabb, manu, Knud, +1.441.592.aacc, webr3, nathan
17:35:00 <Zakim> Zakim has left #rdfa
17:46:38 <manu> trackbot, bye
17:46:38 <trackbot> trackbot has left #rdfa
17:46:40 <manu> rrsagent, bye
17:46:40 <RRSAgent> I see no action items