Chatlog 2010-12-09

From RDFa Working Group Wiki
Jump to: navigation, search

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

15:00:29 <RRSAgent> RRSAgent has joined #rdfa
15:00:29 <RRSAgent> logging to
15:00:31 <trackbot> RRSAgent, make logs world
15:00:31 <Zakim> Zakim has joined #rdfa
15:00:33 <trackbot> Zakim, this will be 7332
15:00:33 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start now
15:00:34 <trackbot> Meeting: RDFa Working Group Teleconference
15:00:34 <trackbot> Date: 09 December 2010
15:00:40 <manu1> Agenda:
15:00:42 <manu1> Chair: Manu
15:02:27 <ShaneM> ShaneM has joined #rdfa
15:03:17 <ShaneM> Scribe: ShaneM
15:03:18 <ShaneM> scribenick: ShaneM
15:03:45 <manu1> zakim, are you dead?
15:03:45 <Zakim> I don't understand your question, manu1.
15:03:50 <manu1> zakim, who is on the phone?
15:03:52 <Zakim> SW_RDFa()10:00AM has not yet started, manu1
15:03:54 <Zakim> On IRC I see ShaneM, Zakim, RRSAgent, Benjamin, tinkster, manu1, ivan, Nathan, trackbot, markbirbeck
15:03:58 <manu1> Present: Ivan, ShaneM, Manu, Toby, Nathan, MarkB, Benjamin, Knud
15:03:59 <ivan> zakim, dial ivan-voip
15:04:04 <Zakim> ok, ivan; the call is being made
15:04:43 <tinkster> zakim, mute me
15:04:43 <Zakim> sorry, tinkster, I don't know what conference this is
15:04:57 <manu1> zakim, this is rdfa
15:04:57 <Zakim> ok, manu1; that matches SW_RDFa()10:00AM
15:04:57 <tinkster> zakim, this is 7332
15:04:57 <Zakim> tinkster, this was already SW_RDFa()10:00AM
15:05:00 <Zakim> ok, tinkster; that matches SW_RDFa()10:00AM
15:05:07 <manu1> zakim, who is on the phone?
15:05:11 <Zakim> On the phone I see tinkster, ??P26, Shane, ??P28, Ivan
15:05:41 <Benjamin> zakim, I am ??P28
15:05:41 <Zakim> +Benjamin; got it
15:06:07 <Benjamin> zakim, mute me
15:06:07 <Zakim> Benjamin should now be muted
15:06:14 <manu1> zakim, I am ??p26
15:06:14 <Zakim> +manu1; got it
15:06:25 <Knud> Knud has joined #rdfa
15:06:46 <Zakim> +Knud
15:07:01 <ivan> zakim, who is here?
15:07:01 <Zakim> On the phone I see tinkster, manu1, Shane, Benjamin (muted), Ivan, Knud
15:07:03 <Zakim> On IRC I see Knud, ShaneM, Zakim, RRSAgent, Benjamin, tinkster, manu1, ivan, Nathan, trackbot, markbirbeck
15:08:01 <markbirbeck> zakim, code?
15:08:01 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), markbirbeck
15:09:24 <Zakim> -Benjamin
15:09:40 <Zakim> +??P44
15:09:47 <markbirbeck> zakim, i am ?
15:09:47 <Zakim> +markbirbeck; got it
15:09:55 <Zakim> +??P28
15:09:58 <manu1> zakim, I am ??p28
15:09:58 <Zakim> +manu1; got it
15:10:12 <Benjamin> zakim, who is on the phone
15:10:12 <Zakim> I don't understand 'who is on the phone', Benjamin
15:10:24 <Benjamin> zakim, who is here?
15:10:24 <Zakim> On the phone I see tinkster, manu1, Shane, Ivan, Knud, markbirbeck, manu1.a
15:10:26 <Zakim> On IRC I see Knud, ShaneM, Zakim, RRSAgent, Benjamin, tinkster, manu1, ivan, Nathan, trackbot, markbirbeck
15:10:27 <manu1> zakim, who is on the phone?
15:10:27 <Zakim> On the phone I see tinkster, manu1, Shane, Ivan, Knud, markbirbeck, manu1.a
15:10:39 <manu1> zakim, manu1 is benjamin
15:10:39 <Zakim> +benjamin; got it
15:10:46 <manu1> zakim, who is on the phone?
15:10:46 <Zakim> On the phone I see tinkster, benjamin, Shane, Ivan, Knud, markbirbeck, manu1.a
15:12:34 <manu1> Topic: Update on incoming Last Call reviews
15:13:23 <Zakim> -Shane
15:13:37 <manu1> Manu: Lots of reviews coming in before end of year.
15:13:44 <Zakim> +Shane
15:14:04 <ShaneM> s/reviews/reviews of RDFa Core/
15:14:54 <ShaneM> ShaneM has left #rdfa
15:15:00 <ShaneM> ShaneM has joined #rdfa
15:15:21 <manu1> Shane: Aside - PFWG accepted our changes on role.
15:15:31 <ShaneM> ShaneM: PFWG accepted out comments on the Role Attribute spec.  They are integrated and will be in the last call release next week.
15:15:54 <ShaneM> manu1: does anyone object to extending the RDFa Core and XHTML+RDFa reviews to 5 January 2011?
15:16:03 <ShaneM> no objections.
15:16:26 <manu1> Topic: Response to Last Call Comments
15:16:31 <ShaneM> manu1: we should start responding to last call comments...  we don't really need to wait.
15:17:06 <ShaneM> ShaneM: Isn't our plate full with RDFa API?
15:17:58 <ShaneM> manu1: Yes... but you (shane) had offered to take the lead on responding.  So perhaps we can do it in parallel?  Create a draft response to each comment, sent to RDFa working group, if no objections after 5 days, then send on as an official response from the working group.
15:18:25 <ShaneM> ... the perfect people to work on these would be Shane and Ivan.
15:18:46 <ShaneM> ivan: procedurally this is fine.  But there might be issues we can't do on our own.
15:18:58 <ShaneM> manu1: sure - in that case they can be punted to the working group for discussion.
15:19:18 <ShaneM> ... I don't want us to have a huge collection on 5 January.
15:20:28 <manu1>
15:20:38 <manu1>
15:22:03 <ShaneM> ivan: some comments have actually multiple issues.
15:22:19 <ShaneM> ShaneM: Yes, but not very many...  
15:23:01 <ShaneM> manu1: The process can be - pick an issue to respond to, send a draft response to the working group marked DRAFT with a 3 to 7 day window to object, if no objections, forward as a formal response to the sender.
15:23:42 <ShaneM> ivan: some of these are issues we have already discussed in the working group.  Do we need a resolution?
15:23:48 <ShaneM> ShaneM: Only if there is a change to the text.
15:24:09 <ShaneM> manu1: Sure.  Then those would be punted to the working group for a formal resolution.
15:25:39 <manu1> Topic: Review RDF API Document
15:26:59 <ShaneM> manu1: We might recharter to take on the RDF API and RDFa API.
15:27:21 <ShaneM> ... Worked over the weekend to create two documents that are in good shape to act as basis for the rec-track documents.
15:27:33 <ShaneM> ... process - quick high level review of each document
15:29:05 <ShaneM> manu1: Unforutnately, Nathan isn't here right now.  I will summarize his work.
15:29:46 <manu1>
15:31:12 <manu1>
15:31:16 <ShaneM> manu1: RDF details are pushed into the RDF API.  RDFa developers can get at all the data they need, but they don't need to dive down to the graph / triples / nodes level for most things.  This would be 'advanced' programming.
15:31:43 <ShaneM> ... RDF API has triples and graphs (at the highest level).
15:32:31 <ShaneM> ... We had some feedback from TimBL that says we really want to view this as a pure graph. 
15:32:54 <ShaneM> ivan: This means it is possible to have a graph that is not serializable?
15:33:23 <ShaneM> manu1: That's correct.  We dealt with that by saying it is fine that you are doing  - it just may not serialize into a particular format
15:34:07 <ShaneM> ... this was the direction we think TimBL wanted us to go, and after heavy debate we agree with the direction.
15:34:24 <tinkster> Closer to the Notation3 model, but not quite as broad.
15:35:03 <ShaneM> ivan: This is probably not quite correct, but it is okay to leave it in the doucment for now.  It is a possible future issue though.  This generalized form is something that would allow literals for subjects, for example.  And that is not something that is currently permitted in RDF.
15:35:15 <ShaneM> manu1: Yes.  This is an attempt to future-proof the API, in case we do end up supporting literals as subjects/predicates or allow graph literals.
15:35:52 <manu1>
15:36:00 <ShaneM> ivan: Okay - but this should be very clear in the document (as an editorial note for now).
15:37:14 <ivan> q+
15:37:26 <manu1> ack ivan
15:37:49 <ShaneM> Manu summarizes the various methods and techniques...
15:38:54 <manu1> manu1: You could get to the prefixes and terms by doing something like: rdf.prefixes or rdf.terms. There is the notion of graph literals now, too.
15:39:34 <manu1>
15:40:50 <Zakim> +[IPcaller]
15:41:13 <Nathan> Zakim, I am IPcaller
15:41:13 <Zakim> ok, Nathan, I now associate you with [IPcaller]
15:43:04 <markbirbeck> q+
15:43:48 <Benjamin> q+ to ask something about the factory methods
15:44:11 <Zakim> -tinkster
15:44:12 <ShaneM> Nathan: re: Graph literals - goal to ensure that it is N3 compatible and future proof.  
15:44:45 <Zakim> +tinkster
15:44:56 <manu1> ack markbirbeck
15:45:09 <ShaneM> markbirbeck: is a graph literal a string?
15:45:27 <ShaneM> Nathan: no.  It can serialize to a string.  
15:45:42 <ShaneM> markbirbeck: Does it point to another graph in the system or does it contain a graph?
15:45:54 <ShaneM> Nathan: It contains a graph.
15:45:58 <tinkster> A graph literal is a string in the same sense that an xsd:integer is a string. An integer isn't a string, but it can be serialised to a string.
15:45:59 <manu1> q+ to point out that we're getting into implementation details
15:48:58 <Nathan> q+ to respond re store
15:49:25 <manu1> ack Benjamin
15:49:25 <Zakim> Benjamin, you wanted to ask something about the factory methods
15:49:37 <ShaneM> markbirbeck: we had discussions about datastore for ages.  My point is that the current draft has lost some functionality that we had with the store interface.  A store was a collection of many graphs potentially, and we could have queried across them.  We can't do that with the current document.
15:50:31 <ShaneM> Benjamin: My goal is to create a single RDF triple.  There would be lots of code needed to do this.  Can't we have a createTriple interface that takes strings instead of nodes?  
15:50:42 <ShaneM> manu1: We may add convenience methods in the future, right now this is bare bones.
15:51:11 <manu1> ack [IPCaller]
15:51:11 <Zakim> [IPcaller], you wanted to respond re store
15:51:16 <manu1> ack manu1.a
15:51:16 <Zakim> manu1.a, you wanted to point out that we're getting into implementation details
15:51:29 <manu1> zakim, manu1.a is manu1
15:51:29 <Zakim> +manu1; got it
15:52:00 <ShaneM> Nathan: the graph was put into the API before I decided to not include the datastore.  I went to do it last night, and couldn't make it work properly.  It can still go in, just that I didn't have the time.
15:53:27 <ShaneM> ... I agree there is no easy way to create a triple in this API at the moment.  The reasons are that we are trying to promote interoperability with libraries, and also that the interface would be very complex - needing 9 slots to deal with the various parameters associated with each triple component.
15:53:39 <manu1>
15:53:42 <manu1> manu1: The RDF environment could be used to generate triples with more convenience. Right now, it's the central access point for the RDF functionality.
15:55:46 <ivan> q+
15:56:19 <manu1> ack ivan
15:56:41 <manu1>
15:56:41 <manu1> manu1: The environment extends profile, so can always get access to the prefixes/terms, etc.
15:57:51 <tinkster> function createTriple(string) { var rv; ntriplesParser.parse(string, function(g){rv=g.toArray()[0];}); return rv; }
15:59:09 <manu1>
15:59:12 <manu1> manu1: We also provide interfaces if you want to serialize or parse RDF data.
15:59:52 <manu1> ... rdf.parseTurtle(xyz) is one way to extend the API
15:59:57 <manu1> ... or, we may want something like:
16:00:07 <manu1> ... rdf.parse("turtle", query...) 
16:00:22 <manu1>
16:00:22 <manu1> manu1: There is more detail in the data serializer interface.
16:01:43 <tinkster> hmmm... why does PrefixMap.resolve return a DOMString and not a NamedNode?
16:00:22 <manu1> manu1: So, that's basically the RDF API at a high level, what do folks think of this direction?
16:02:20 <Benjamin> it is great !
16:02:36 <markbirbeck> Great work, Nathan. :)
16:02:43 <manu1> yes, great work, Nathan! :)
16:03:06 <Nathan> ty, ty, ty, likewise all - and good q Toby, i wondered too
16:04:32 <Zakim> -tinkster
16:04:42 <Zakim> -benjamin
16:05:10 <manu1> Topic: Review RDFa API Document
16:05:12 <manu1>
16:05:12 <manu1> manu1: Since we shifted most of the RDF functionality into the RDF API, it has greatly simplified the RDFa API. We wanted this to be a very, very simple API. We would be successful if web developers never had to talk about RDF or work with RDF data directly. Most people can get some really interesting stuff done with just JavaScript objects - so we try to map to that, in a lossy way. If folks want to get to the triple data, they can use the RDF environment -
16:05:23 <Zakim> -markbirbeck
16:05:31 <Zakim> -Knud
16:06:07 <manu1>
16:06:09 <manu1> manu1: As you can see, the RDFa API boils down into around 9 methods that give back native JavaScript objects. There are two ways to build native language objects - like JavaScript objects.
16:06:27 <manu1>
16:06:37 <manu1> manu1: Property Groups are collections of everything known about a particular subject. 
16:06:43 <manu1>
16:06:45 <manu1> manu1: Projections are native JavaScript objects whose attributes are mapped to specific vocabulary terms. The mapping is up to the developer, so they can transform any RDF into a JavaScript object in order to work with it. For example:
16:07:23 <manu1> var pg = document.getItemBySubject("#ivan");
16:07:46 <manu1>"foaf", "");
16:07:59 <manu1> var name = pg.get("foaf:name");
16:08:07 <manu1> name === "Ivan Herman";
16:08:54 <manu1> var p ={"rdf:type": "foaf:Person"}, {"foaf:name": "name", "foaf:age": "age"});
16:09:00 <manu1> p.age
16:09:02 <manu1>
16:10:25 <ShaneM> q+ to ask about getElements* methods
16:10:35 <manu1>
16:10:35 <manu1> manu1: If they want to get to the RDF data, set mappings, etc, they can do the following:
16:10:43 <manu1>
16:12:11 <manu1>
16:13:26 <manu1> document.curie.setMapping()
16:14:56 <manu1> you can do this:
16:15:03 <manu1>
16:15:23 <manu1> ack shaneM
16:15:23 <Zakim> ShaneM, you wanted to ask about getElements* methods
16:17:59 <manu1>"foaf", "http://....");
16:18:13 <manu1> document.getElementsByType("foaf:Person");
16:18:22 <manu1>"xyz", "http://....");
16:18:27 <manu1> document.getElementsByType("xyz:Person");
16:18:34 <manu1> document.getElementsByType("http://...");
16:19:12 <manu1>
16:20:12 <manu1> pg.get("foaf:name");
16:20:32 <manu1> Document implements DataDocument;
16:20:33 <manu1> The top-level HTML Document implements DataDocument - which means that developers can access data in a document using the high-level methods. They can also get elements associated with properties, like so:
16:21:51 <manu1> var e = document.getElementsByProperty("foaf:name");
16:21:54 <manu1> var elems = document.getElementsByProperty("foaf:name");
16:22:12 <manu1> var elems = document.getElementsByProperty("foaf:name", "Ivan Herman");
16:23:58 <manu1> <span property="foaf:name">Ivan Herman</span>
16:24:10 <manu1> elems = document.getElementsByProperty("foaf:name", "Ivan Herman");
16:24:23 <manu1> elems[0] == <SPAN>
16:24:51 <manu1> elems = document.getElementsByProperty("foaf:age", "15");
16:25:02 <ivan> elems = document.getElementsByProperty("foaf:name", "member:Ivan");
16:25:19 <ivan> elems = document.getElementsByProperty("foaf:name", "Manu")
16:25:31 <tinkster> For getElementsByProperty("foaf:page"), which element is selected in <span rel="foaf:page"><a href=""></a></span>?
16:26:02 <manu1> manu1: tinkster - the <SPAN> is returned, not the <A> element. That is, the element that expressed the predicate is returned.
16:26:26 <manu1> zakim, who is on the call?
16:26:26 <Zakim> On the phone I see Ivan, manu1, Shane, [IPcaller]
16:26:44 <manu1> manu1: two directions we could have taken: return elements for subject, predicate, object, or return elements for just the predicate - we took the latter path.
16:26:55 <ivan> <span about="a" rel="b" resource="c"><span property="qq">asfasa</span></span>
16:27:14 <ivan> getElementsBySubject("c")
16:29:23 <manu1> manu1: If we went the "return a subject element, predicate element, and object element for every triple", it would be difficult for developers to work with the resulting items:
16:29:23 <manu1> [Node, Node, Node]
16:29:30 <manu1> [[Node, Node, Node], ...]
16:31:34 <manu1>
16:31:34 <manu1> manu1: Other issue is ensuring prefix and terms are shared across RDF/RDFa API
16:32:25 <Nathan> problem would be that you'd then have two environments, effectively
16:34:24 <ShaneM> shane: I would remove the rdf attribute from document and use the hasFeature method
16:36:13 <manu1> manu1: We want to make it so that if this is true: document.hasFeature("rdf-api")
16:36:28 <manu1> ... then you MUST use document.rdfa ?
16:38:32 <markbirbeck> BTW...should just flag up that I prefer the use of "?name"-style syntax in templates. Then you only need one parameter.
16:38:50 <manu1> the problem with that Mark, is that you can't pull out what you queried...
16:38:53 <markbirbeck> (That was my main -- maybe only -- disagreement with latest draft.)
16:38:56 <tinkster> <div about="#bob">Bob <span rel="rdf:type">is a <a href="">Person</a></span>.</div> versus document.getElementsByType("") ??
16:39:05 <manu1> that's why I chose the two-parameter approach.
16:39:20 <manu1> so, if I query for foaf:name, how do I also get that value out?
16:39:43 <manu1>{"foaf:age": 15}
16:40:20 <markbirbeck> The only time you can't get the values back is if you query for a fixed value.
16:40:44 <markbirbeck> var rs = {"foaf:age": "?age"} );
16:41:01 <markbirbeck> assert( rs[0].age === 15 );
16:41:34 <manu1> but I don't want to do that... lots of code for something that's pretty simple.
16:41:46 <markbirbeck> var rs = {"foaf:name": "Manu", "foaf:age": "?age"} );
16:42:01 <markbirbeck> I don't follow you...that's less code than two parameters, surely? :)
16:47:44 <ShaneM> q+ to talk about live DOM tie in
16:50:04 <Nathan>  -
16:50:17 <manu1> ack shanem
16:50:17 <Zakim> ShaneM, you wanted to talk about live DOM tie in
16:50:24 <Nathan> Nathan: The RDFa-API doesn't /need/ to refer to RDF-API - we could completely decouple them.
16:50:27 <manu1> q+ to agree w/ Nathan more
16:52:22 <Nathan> 1+ to respond
16:52:26 <Nathan> q+ to respond
16:52:40 <manu1> ack manu
16:52:40 <Zakim> manu, you wanted to agree w/ Nathan more
16:52:46 <manu1> ack [IPCaller]
16:52:46 <Zakim> [IPcaller], you wanted to respond
16:55:33 <manu1> q+
16:55:52 <Nathan> doc = xhr.get("http://some.rdfa/document")
16:56:03 <Nathan> doc.getItemsBy*
16:57:45 <Zakim> -Shane
16:57:55 <manu1> The question is, do we want to support parse, store and query methods on DocumentData?
16:58:31 <manu1>"http://...");
17:01:35 <manu1>"http://...");
17:01:53 <manu1>;
17:02:36 <Nathan> -1store(doca)
17:04:49 <Nathan> lib.load(uri-a); lib.load(uri-b);"sparql here")
17:07:10 <manu1>{"foaf:age": 15}, {"foaf:name": "name", "foaf:age": "age"});
17:07:50 <manu1> The query interface is designed to be very high-level in the RDFa API:
17:07:50 <manu1> var p ={"foaf:age": 15}, {"foaf:name": "name", "foaf:age": "age"});
17:07:52 <manu1> p[0].name
17:07:54 <manu1> p[0].age
17:08:00 <Nathan> p[1].age
17:08:08 <manu1> var p ={"foaf:age": 15}, {"foaf:name": "name", "foaf:age": "age"});
17:14:08 <markbirbeck> var p ={"foaf:name": "?name", "foaf:age": [ 15, "?age" ]});
17:14:35 <manu1> manu1: We could use microsyntaxes for queries - that could work, yes - but then people need to learn a microsyntax
17:15:18 <markbirbeck> var p ={"foaf:name": "?name", "foaf:age": function(val) { return val + 20;} });
17:15:20 <markbirbeck> :)
17:15:40 <markbirbeck> Oh yes, I forgot...learning an API is real easy, but somehow microsyntaxes are a bind! ;)
17:15:48 <ivan> zakim, drop me
17:15:48 <Zakim> Ivan is being disconnected
17:15:50 <Zakim> -Ivan
17:15:55 <manu1> cheeky, cheeky
17:16:17 <markbirbeck> I'm not for or against microsyntaxes in principle, but in this context we have a lot of existing microsyntaxes that we can leverage.
17:16:21 <markbirbeck> <uri>
17:16:46 <markbirbeck> ?name
17:16:52 <markbirbeck> They are familiar.
17:17:02 <markbirbeck> Manu@en
17:17:05 <markbirbeck> And so on.
17:22:59 <Zakim> -[IPcaller]
17:23:01 <Zakim> SW_RDFa()10:00AM has ended
17:23:02 <Zakim> Attendees were tinkster, Shane, Ivan, Benjamin, Knud, markbirbeck, [IPcaller], manu1
17:23:18 <manu1> reading back over your comments... I don't disagree with you entirely, Mark.
17:24:06 <manu1> but, I thought that we didn't want to expose RDF-y things to people in the RDFa API?
17:24:21 <manu1> Why should anyone know that something is a TypedLiteral via the RDFa API?
17:24:38 <manu1> That requires them to know RDF, which may not be ideal?
17:25:03 <manu1> "Mark@en" <--- asks the question: Do we want to expose web developers to that?
17:26:26 <manu1> I agree that we loose specificity by doing that... but is that an acceptable loss?
17:27:05 <manu1> Microsyntaxes are a bind because they're so many of them - (I note the irony of saying that being a participant in the JSON-LD work)
17:27:25 <manu1> So, unless we're going to commit to them full-tilt, we may want to stay away from them.
17:27:32 <markbirbeck> Sorry...I'm not saying that we expose web developers to them.
17:28:03 <markbirbeck> I'm just saying that there are many useful microsyntaxes already.
17:28:10 <manu1> true
17:28:18 <manu1> but only for those that know TURTLE, N3, etc.
17:28:29 <manu1> and I don't think we're trying to cater to that audience w/ the RDFa API
17:28:35 <markbirbeck> Yes, but I regard what we're doing as an 'on-ramp' to RDF.
17:28:54 <markbirbeck> I can use "?name" in a query without knowing RDF.
17:29:05 <manu1> true
17:29:21 <manu1> and for some reason I don't have much of a problem w/ that
17:29:29 <markbirbeck> But if I then start to learn SPARQL or N3 (or even SQL for that matter) what I've learned will transpose.
17:29:50 <markbirbeck> (SQL uses ?name and a *lot* of people will be familiar with that.)
17:30:02 <manu1> I do have a problem with combining a query and a mapping.
17:30:07 <manu1> It's natural to do in SPARQL.
17:30:15 <manu1> I don't know if it's natural to do for a JavaScript developer 
17:30:20 <manu1> it doesn't feel natural.
17:30:33 <manu1> It seems simpler to say: You do a query with two items - the query, and a mapping.
17:31:32 <manu1> rather than, you do a query with one item, which will include both the query and a mapping... if you want to query and map for the same property, use an array where the first item is the query and the second item is the map. If you just want to map, just put a string with a '?' in front of it.
17:33:53 <manu1> I don't have a problem w/ either approach, but I worry that beginning web developers might.
17:34:16 <manu1> also, don't forget that we need to define an escape character - '\'
17:34:21 <manu1> if we use "?"
17:35:06 <markbirbeck> I don't see it as a query *and* a mapping...I think that's overcomplicating it.
17:35:12 <markbirbeck> I see it as a *template*.
17:35:26 <markbirbeck> I think that would very easy for people to understand.
17:35:40 <markbirbeck> We're creating a template and then asking the engine to populate it.
17:36:10 <manu1> I think both are potentially easy for people to understand - the question is, which one is easier? Which one will work with a wider audience.
17:36:12 <markbirbeck> Wherever we have "?x" then the engine can insert values.
17:36:19 <manu1> (as I don't see technical issues w/ either approach)
17:36:20 <markbirbeck> Otherwise it just leaves them alone.
17:36:26 <manu1> ahh, I see.
17:36:36 <manu1> what you're saying... let me think if that changes my mind.
17:36:44 <markbirbeck> Actually...I've just changed my own mind!
17:36:49 <markbirbeck> Mmm...
17:37:04 <markbirbeck> Have to think a bit more.
17:37:22 <markbirbeck> I've just changed from having projections (which lose the predicates) to having templates!
17:37:38 <manu1> I think your template-engine suggestion is good - it does make sense - but isn't it just an implementation detail?
17:37:54 <manu1> so, you pass in the object that you want?
17:37:57 <manu1> attributes and all?
17:38:17 <markbirbeck> No that wasn't what I was after...sorry. :(
17:38:21 <manu1> you pass in a projection to:
17:38:30 <markbirbeck> That was my intention, yes.
17:38:33 <manu1> but it would nicely, wouldn't it?
17:38:44 <manu1> ok, now I really have to go, but will think more about all this.
17:38:51 <markbirbeck> Except you still need to map, if you want to do rs[0].age.
17:39:07 <markbirbeck> Unless you express "age" as the predicate in the query.
17:39:41 <markbirbeck> But what I liked about my projection approach is that you are encouraged to map the original predicates to something else.
17:39:49 <markbirbeck> I.e., something more meaningful.
17:41:07 <markbirbeck> var rs = document.query( { "foaf:name": "?person", "foaf:knows" : { "foaf:name": "?friend" } } );
17:41:56 <markbirbeck> alert(rs[0].name + " is friends with " + rs[0].friend);
17:44:05 <Nathan> Do RDFa Profiles not mean that an RDF-API implementation is /required/ ?
17:47:12 <markbirbeck> Hey, didn't someone raise that as a problem once?
17:47:14 <markbirbeck> ;)
17:50:46 <markbirbeck> Nathan: The Graph interface should derive from RDFNode, because (a) you can have a graph in any position in a triple, and (b) you want the referenced graph to be live.
17:57:14 <Nathan> (still not here) (a) it still derives from RDFNode so can be in any position (b) referenced graph would still be live, RDFNode.value = live value now, not lexical string, so is instance of Graph
18:00:16 <Nathan> (c) it allows graph literals to have an optional datatype, which they'll probably need
18:00:35 <Nathan> ps - re comment about profiles earlier, got a feelign a few key points you've mae have been missed thus far
18:00:45 <Nathan> s/mea/made
18:01:26 <Nathan> w/o profiles RDFa and it's API can run @ DOM level, with Profiles a full RDF Stack is required
19:28:35 <markbirbeck> Right. Except that with profiles defined using a simple syntax, along the lines of that used in @prefix you also don't need the full RDF stack.
19:29:13 <markbirbeck> (Not sure how those points "have been missed thus far" though...I've been a bit of a broken record on this one. :( )
19:30:17 <Zakim> Zakim has left #rdfa