None.
14:50:45 <RRSAgent> logging to http://www.w3.org/2010/11/11-rdfa-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2010/11/11-rdfa-irc ←
14:50:47 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
14:50:49 <trackbot> Zakim, this will be 7332
Trackbot IRC Bot: Zakim, this will be 7332 ←
14:50:49 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 10 minutes
Zakim IRC Bot: 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
(Scribe set to Manu Sporny)
14:54:06 <manu> scribenick: manu
15:00:31 <Zakim> SW_RDFa()10:00AM has now started
(No events recorded for 6 minutes)
Zakim IRC Bot: SW_RDFa()10:00AM has now started ←
15:00:41 <Zakim> + +3539149aaaa
Zakim IRC Bot: + +3539149aaaa ←
15:01:02 <Knud> zakim, aaa is me
Knud Möller: zakim, aaa is me ←
15:01:02 <Zakim> sorry, Knud, I do not recognize a party named 'aaa'
Zakim IRC Bot: sorry, Knud, I do not recognize a party named 'aaa' ←
15:01:11 <Zakim> + +1.540.961.aabb
Zakim IRC Bot: + +1.540.961.aabb ←
15:01:16 <manu> zakim, I am aabb
zakim, I am aabb ←
15:01:16 <Zakim> +manu; got it
Zakim IRC Bot: +manu; got it ←
15:01:18 <Knud> zakim, I am aaa
Knud Möller: zakim, I am aaa ←
15:01:18 <Zakim> sorry, Knud, I do not see a party named 'aaa'
Zakim IRC Bot: sorry, Knud, I do not see a party named 'aaa' ←
15:01:32 <Knud> zakim, I am aaaa
Knud Möller: zakim, I am aaaa ←
15:01:32 <Zakim> +Knud; got it
Zakim IRC Bot: +Knud; got it ←
15:08:56 <Zakim> + +1.441.592.aacc
(No events recorded for 7 minutes)
Zakim IRC Bot: + +1.441.592.aacc ←
15:09:13 <nathan> zakim, i am +1.441.592.aacc
Nathan Rixham: zakim, i am +1.441.592.aacc ←
15:09:13 <Zakim> +nathan; got it
Zakim IRC Bot: +nathan; got it ←
15:11:18 <Zakim> -nathan
Zakim IRC Bot: -nathan ←
15:13:03 <Zakim> +[IPcaller]
Zakim IRC Bot: +[IPcaller] ←
15:13:22 <nathan> Zakim, i am +[IPcaller]
Nathan Rixham: Zakim, i am +[IPcaller] ←
15:13:22 <Zakim> sorry, nathan, I do not see a party named '+[IPcaller]'
Zakim IRC Bot: sorry, nathan, I do not see a party named '+[IPcaller]' ←
15:13:32 <nathan> Zakim, i am ?
Nathan Rixham: Zakim, i am ? ←
15:13:32 <Zakim> sorry, nathan, I do not see a party named '?'
Zakim IRC Bot: sorry, nathan, I do not see a party named '?' ←
15:13:34 <manu> zakim, IPcaller is nathan
zakim, IPcaller is nathan ←
15:13:34 <Zakim> +nathan; got it
Zakim IRC Bot: +nathan; got it ←
15:15:05 <manu> Shane and Toby are IRC-only - Shane is having dial-in issues.
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
Knud Möller: 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.
Knud Möller: 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.
Manu Sporny: 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
Knud Möller: Perhaps we should put something in the RDFa Primer outlining this ←
15:16:18 <manu> Manu: Good idea.
Manu Sporny: 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.
Manu Sporny: 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.
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.
Manu Sporny: 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.
Nathan Rixham: 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
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.
Manu Sporny: 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?
Knud Möller: 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
Manu Sporny: Ah yes, we did remove "RDF" from the name ←
15:20:00 <manu> Manu: What about Graph or DataGraph?
Manu Sporny: What about Graph or DataGraph? ←
15:20:13 <manu> Nathan: I think we have a clear separation from Data* and other concepts.
Nathan Rixham: 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.
Nathan Rixham: I don't think that Data makes sense - either Graph or RDFGraph. ←
15:21:36 <manu> Manu: How about Graph?
Manu Sporny: How about Graph? ←
15:21:47 <manu> Knud: Hmm, we did discuss this.
Knud Möller: 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.
Manu Sporny: 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.
Nathan Rixham: 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.
Manu Sporny: Yes, but we do want to make sure there is a natural grouping. ←
15:23:56 <manu> Manu: Leaning heavily towards RDFGraph, then.
Manu Sporny: Leaning heavily towards RDFGraph, then. ←
15:23:58 <manu> Nathan: Me too.
Nathan Rixham: Me too. ←
15:24:00 <manu> Knud: Ok
Knud Möller: Ok ←
15:24:37 <manu> Knud: We specify in the goals that we want to support non-RDFa parsers... Microformats, Microdata.
Knud Möller: 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.
Manu Sporny: 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.
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
Manu Sporny: 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()
Manu Sporny: We don't support map() ←
15:26:24 <manu> Manu: Any reason for that?
Manu Sporny: Any reason for that? ←
15:26:53 <manu> Nathan: That functionality would be almost impossible to implement over a triple store.
Nathan Rixham: That functionality would be almost impossible to implement over a triple store. ←
15:27:00 <manu> Nathan: It's very complex
Nathan Rixham: 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.
Toby Inkster: 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().
Nathan Rixham: 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.
Manu Sporny: 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.
Nathan Rixham: 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
Nathan Rixham: 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()
Nathan Rixham: 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().
Nathan Rixham: 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.
Manu Sporny: Sounds good to me. ←
15:31:12 <manu> Nathan: unsure about mentions(), iterator(), merge()
Nathan Rixham: unsure about mentions(), iterator(), merge() ←
15:31:24 <manu> Manu: Let's talk about mentions()
Manu Sporny: Let's talk about mentions() ←
15:31:47 <manu> Manu: If it exists in subject, predicate or object, you get true?
Manu Sporny: If it exists in subject, predicate or object, you get true? ←
15:31:50 <manu> Nathan: Yes.
Nathan Rixham: Yes. ←
15:32:21 <manu> Manu: One other way was just subject or object - but that seems arbitrarily limiting.
Manu Sporny: One other way was just subject or object - but that seems arbitrarily limiting. ←
15:32:28 <manu> Nathan: Yes, right.
Nathan Rixham: Yes, right. ←
15:33:03 <manu> Manu: I'm fine w/ it operating on subject, predicate and object.
Manu Sporny: I'm fine w/ it operating on subject, predicate and object. ←
15:33:06 <manu> Knud: I agree.
Knud Möller: I agree. ←
15:33:17 <manu> Manu: Let's discuss iterator()
Manu Sporny: Let's discuss iterator() ←
15:33:55 <manu> Nathan: Question as to whether it is required in the first place or not.
Nathan Rixham: 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()
Nathan Rixham: No way to do a iterate in Javascript - .forEach(), .iterator(), .toArray() ←
15:36:03 <nathan> for(x in graph)
Nathan Rixham: for(x in graph) ←
15:36:21 <manu> Nathan: There is no way to do that in JavaScript
Nathan Rixham: There is no way to do that in JavaScript ←
15:37:08 <nathan> ir = graph.iterator(); while(it.hasNext()) { triple = it.next() }
Nathan Rixham: ir = graph.iterator(); while(it.hasNext()) { triple = it.next() } ←
15:37:46 <nathan> graph.toArray() <-- much easier
Nathan Rixham: graph.toArray() <-- much easier ←
15:38:34 <manu> Manu: While it does make it nicer, it's not absolutely necessary.
Manu Sporny: 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.
Manu Sporny: This would be most useful in language that doesn't support dynamic functions/closures. ←
15:39:46 <nathan> process()
Nathan Rixham: process() ←
15:39:56 <nathan> Class Process { function process(); }
Nathan Rixham: 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.
Manu Sporny: 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.
Knud Möller: 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.
Nathan Rixham: 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()
Manu Sporny: Let's discuss merge() ←
15:43:32 <nathan> Array.concat()
Nathan Rixham: Array.concat() ←
15:43:40 <manu> Nathan: To do this properly in JavaScript - you have .concat()
Nathan Rixham: 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()
Nathan Rixham: 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
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array ←
15:46:06 <nathan> my preference: var mergedgraph = graph.merge(otherGraph);
Nathan Rixham: 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.
Manu Sporny: 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);
Nathan Rixham: or.. var graph = graph.merge(otherGraph); ←
15:49:31 <Knud> sort() and sort!()
Knud Möller: sort() and sort!() ←
15:49:41 <manu> Knud: Ruby has a convention that supports both - inplace and copy
Knud Möller: 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
Nathan Rixham: JavaScript has options for in-place and return a copy too ←
15:50:46 <manu> Manu: Any strong objections to supporting both?
Manu Sporny: Any strong objections to supporting both? ←
15:50:53 <manu> Knud: If people are going to have both, we should do that.
Knud Möller: If people are going to have both, we should do that. ←
15:51:21 <manu> Nathan: well, this is a bit strange for JavaScript
Nathan Rixham: well, this is a bit strange for JavaScript ←
15:51:33 <manu> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/push
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/push ←
15:52:13 <manu> Nathan: difficult to implement - one is computationally expensive.
Nathan Rixham: 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.
Manu Sporny: 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.
Knud Möller: 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
Nathan Rixham: 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?
Nathan Rixham: 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
Nathan Rixham: with graph.import ←
15:56:43 <nathan> c = createGraph(); c.import(a); c.import(b)
Nathan Rixham: c = createGraph(); c.import(a); c.import(b) ←
15:56:58 <nathan> c = a.merge(b)
Nathan Rixham: c = a.merge(b) ←
15:57:00 <nathan> or
Nathan Rixham: or ←
15:57:06 <nathan> a = a.merge(b)
Nathan Rixham: a = a.merge(b) ←
15:58:39 <nathan> or we can define import() and merge()
Nathan Rixham: 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.
Manu Sporny: Any objections to just supporting .merge() right now, which returns a new Graph. ←
15:59:25 <nathan> prefer "RDFGraph merge(in RDFGraph graph);"
Nathan Rixham: 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.
Knud Möller: 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
interface RDFTripleCallback ←
16:00:28 <manu> Manu: Looks good
Manu Sporny: Looks good ←
16:00:33 <manu> Nathan: Yep, pretty simple.
Nathan Rixham: Yep, pretty simple. ←
16:00:38 <manu> interface RDFTripleFilter
interface RDFTripleFilter ←
16:00:44 <manu> Everyone seems to think that's fine.
Everyone seems to think that's fine. ←
16:01:13 <manu> Manu: Have we covered everything in the proposal, Nathan?
Manu Sporny: Have we covered everything in the proposal, Nathan? ←
16:01:16 <manu> Nathan: Yes, we have.
Nathan Rixham: Yes, we have. ←
16:01:40 <manu> Manu: I'll put together a proposal to close this issue.
Manu Sporny: I'll put together a proposal to close this issue. ←
16:01:45 <manu> Manu: I'll also propose to close ISSUE-51.
Manu Sporny: I'll also propose to close ISSUE-51. ←
Formatted by CommonScribe