08:51:01 RRSAgent has joined #dawg 08:51:18 i don't think so, re: news 08:51:23 Map to optional : issue is that variables would get bound 08:52:52 i'll point ericp to it when the disjunction discussion slows down 08:53:11 Some cases (many?) can be done by value disjunction 08:54:04 (example on screen) 08:54:46 JF: Very difficult for implementations 08:54:54 q? 08:54:59 (scribe agreeds - needs data flow analysis of query - not syntax) 08:55:36 trickier example would be get people who are either of type "doggowner" or own a pet whose type is a dog 08:55:41 q? 08:55:54 ack, kendallc 08:55:55 AlbertoR has joined #dawg 08:56:01 let me paste the examples 08:56:08 4. Want at least one of them with the constraint 08:56:08 ASK 08:56:08 OPTIONAL (?person rdf:type Engineer) 08:56:08 OPTIONAL (?person rdf:type Manager) 08:56:09 (?person ex:age ?age) 08:56:11 WHERE 08:56:13 kendall: how much of opt difficulty is just 08:56:13 ?age >20 08:56:15 JanneS has joined #dawg 08:56:17 Kendall: Hard to implement? 08:56:18 => YES 08:56:22 and 08:56:23 5. Re-expression of 4 using value disjunction 08:56:25 ASK 08:56:27 (?person ex:age ?age) 08:56:29 (?person rdf:type ?type) 08:56:31 WHERE 08:56:33 (?type = Engineer OR ?type = Manager) AND 08:56:35 ?age > 20 08:56:39 => 08:56:41 YES 08:57:32 how much of the optimization worries are due to SteveH's sql-based implementation strategy. That is, I'm wondering how general they are. 08:57:34 Steve: would simply expand all cases to one (large!) SQL query 08:57:45 JFBaget has joined #dawg 08:58:01 steve worried about optimising 08:59:12 eric: optimizations can hurt soundness and completeness\ 08:59:22 i.e. optimization can introduce bugs 08:59:23 Jos: its a requirement (3.13) 08:59:37 ack Yoshio 08:59:37 Yoshio, you wanted to ask what empty WHERE means 08:59:50 zakim, q- 08:59:50 I see no one on the speaker queue 08:59:50 ack kendallc 08:59:51 yoshio: what does empty where clause mean? 09:00:10 DaveB: was a typo 09:00:19 zakim, q+ 09:00:19 I see JFBaget on the speaker queue 09:00:26 yoshio: with optional at top and no other where terms.. 09:00:29 q+ to point to requirement 3.13 RDF Graph Pattern MatchingDisjunction 09:01:22 yoshio: select ?x where optional (?x, ?x ?x) 09:01:33 anday: return one row one column 09:01:53 andy: using construct instead of select in that query migght return an error 09:02:12 q? 09:02:15 steve: with construct, if x isn't bound result is empty doc 09:02:35 ack JFBaget 09:03:05 q+ ericP 09:03:15 jf: implementation will have two components graph matching and then constraints. 09:03:20 q- 09:03:38 q+ ericP to ask if optimization is a criteria for success 09:03:38 jf: will bbe much more efficieent to be able to put disjunction in first step 09:03:51 jf: we know algorithms tto do disjunction 09:04:07 steve: y system doesn't separate those two steps as explicitly 09:04:37 steve: simple constraints are used to prune graph matchin stage in my system 09:05:02 ack JosD 09:05:02 JosD, you wanted to point to requirement 3.13 RDF Graph Pattern MatchingDisjunction 09:05:27 (examples are being typed up ffor later review) 09:05:44 jos: 3.13 requires disjunction 09:06:00 steve: but optional might meet those needs 09:06:28 3.13 was proposed and accepted during a face-to-face\ 09:07:13 steve: process error that it was accepted that way 09:07:15 q? 09:09:03 eric: let's get example where optional isn't good enough 09:09:09 andy: and let's post it to the email list 09:11:08 action: rob to do stuff 09:11:21 steve to own disjunction issue 09:11:29 ack ericP 09:11:29 ericP, you wanted to ask if optimization is a criteria for success 09:12:22 eric: how do we balance expressiveness with implementation and optimization ease 09:12:48 kendall: it should be some kind of concern 09:13:02 q? 09:13:22 if the optimization worries are generalizable, then yes, it's a real concern. but i don't know that and no one has claimed it. 09:13:41 state of art is triple-based, not graph matchin based 09:14:59 janne: in SQL, some queries just perfform poorly 09:15:09 steve: in SQL you can tell which ones will perfform poorly 09:16:02 straw poll: who wants to drop disjunction 09:16:11 4 in favor (reluctat fifth 09:16:59 three or four against 09:17:21 DanC_lap has joined #dawg 09:17:40 DanC has joined th meeting and is taking over as chair 09:19:01 danc: let's update issues list at break 09:19:15 danc: f2f meeting schedule 09:19:57 danc: we ffinally know tech plenary date; let's meeet efore end of feb 09:20:13 dan: booked to end of year 09:20:27 steve: considered hosting ( inUK) 09:20:33 yoshio, should we drag everyone to japan? 09:20:39 kendall: possibly in DC 09:20:47 janne: finland, anyone? 09:20:47 in January? 09:21:25 If we plan to use Keio room, I think January is not a good month (entrance exam) 09:21:36 oo, good point 09:21:40 It's everyody's favorite game, the Scheduling Game! Hooray!!! 09:25:41 19-20 Jan looks liike a good tiime; kendall will consider DC 09:26:14 action: kendall to consider DC 09:26:31 action janne to consider hosting f2f\ 09:26:39 action: janne to considerhosting f2f 09:26:47 action: steve to consider hosting f2f 09:27:02 dan: moving on to telecon times 09:27:11 dan: same time boston time? 09:27:17 yoshio: NOOOOOOO! 09:27:49 Janne: how about a meeting in Tampere? :> 09:27:54 sounds insanely cool there 09:27:54 (this is partly over daylight saings time change) 09:33:03 Hmm, Tampere is 200kms (130miles) North from my home and office... could do, though, if you insist. 09:33:19 :> 09:34:04 danc: agreed to meet 1430 utc 09:34:30 kendall: dan is being mean to people not here 09:34:54 it's just a meaningless point to make, give yr input if yr not gonna be here. it wouldn't make a bit of difference to the decision. 09:34:57 resolved to meet 1430 utc, no abstaintions no objections 09:35:22 no meeting 21st 09:35:27 next meetingg 28th 09:35:50 scribe for 28th sept: janne 09:36:07 f2f proposals expected before that meeting 09:37:04 This concluded this exciting edition of the Scheule Game! thanks forplaying 09:37:10 break 09:37:17 scribe affter reak: ericp 09:58:24 [resume] 09:58:40 [BRQL grammar discussion] 09:59:16 DARQ grammar discussion.... 10:00:18 oh right, DARQ 10:01:57 for example, the parents and instances of a class or the class tree. 10:03:53 Andy: issues around nesting... 10:04:29 ... constraints can show up in lots of places 10:05:41 [Andy gives a tour of two syntax variants] 10:07:16 ... are there other choices? 10:07:28 SteveH: not allow in-line constraints 10:07:28 oops 10:10:05 example for Andy: 10:10:07 SELECT ?mbox ?name ?name2 10:10:07 FROM 10:10:07 WHERE 10:10:07 { ?x foaf:mbox ?mbox . 10:10:09 ?x foaf:number ?n . ?n < 30 . 10:10:12 OPTIONAL { ?x foaf:name ?name } . 10:10:14 OPTIONAL { ?x foaf:knows ?y . OPTIONAL { ?y foaf:name ?name2 } . } 10:10:17 } 10:12:19 SteveH asks for block-based OPTIONAL graphs 10:12:42 Andy: are you prepared to do data-flow analysis 10:12:51 SteveH: already do it for RDQL 10:14:53 q+ to talk about trivalue logic 10:19:04 [DaveB proposes 4 syntax alternatives] 10:19:25 DaveB: let's stay close to RDQL 'cause people are using it now. 10:22:42 Andy: what RDQL query would *not* fit in [DaveB's forth proposal] ? 11:04:39 [break] 11:05:09 [Andy presents syn-prop.txt] 11:07:19 Andy asks about conjunctive constraints 11:07:40 SteveH has a prob with constraints applied to a block 11:09:29 ... specifically, source applied to a multiple triples 11:10:04 prefix vs. using 11:10:24 Andy prefers prefix (before use) for single pass 11:10:36 DaveB +1 to PREFISX 11:10:37 SteveH feels that it clutters the query. 11:10:49 eric{ +1 to PREFISX 11:12:17 SteveH withdraws objection to prefix 11:13:17 DanC: i'd like andyS to be less democratic 11:13:35 DaveB opposes nested optionals 11:13:49 ... + SOURCE attached to triple 11:15:57 ... can't see block boundries with the ANDs in the graph 11:17:01 EricP: what is your [DabveB 11:17:11 ] objection to nested optionals 11:17:19 DaveB: doesn't seem required 11:17:29 Alberto: why not use quads 11:17:43 Andy: can make QL work but... 11:18:31 ... What do you return when the triple comes from two models? 11:18:51 Alberto and SteveH return two solutions 11:23:23 (s p o :prop value) -- colon doesn't work, but some other prefix might 11:23:33 steve: use of 'as' as keyword 11:23:37 (s p o prop=value) would, I guess 11:24:05 andy: this sounds like starting over; making triples data objects in themodel 11:24:32 dave: putting source riht next to the triple is the simplest solution 11:25:26 staw poll: is it worth 'reinventing the universe' to come up with a robust way to handle 'source'? 11:25:41 (consensus no, I think) 11:26:45 andy: makes sense to be able to put 'and' blocks anywhere 11:28:12 general agreement that ability to move any block anywhere in a where clause (becausee it's just a conjunction which is commutative) 11:28:17 ...is good 11:28:40 dan: is source on just one triple good enough? 11:29:04 steve: you can just tack the same thing onto multiple triples, and you can do the more general thing 11:29:50 andy: weird that optionals are square brackets and eveything else is keywords 11:30:25 kendall: consistency good 11:31:22 andy: nested optionals can always be "distributed" out to top level\ 11:31:44 eric: anyone other than steve object to nested optionals? 11:31:55 weakly object: jos dirk 11:32:07 strongly for nested optionals andy 11:32:14 weakly for: ericp, yoshio 11:33:08 andy: wwith just an optional keyword, you make nested optionals impossible 11:33:36 Steve: ah... "nested optionals in the future" is a convincing argument. 11:33:36 rob, yr scribing makes me sound like Semantic Caveman... "consistency good; rob bad!" :> 11:35:12 eric: any optional-supporters not content with planning for future nested optional syntax, but not including nested optionals as a feature? 11:36:02 (nobody shouts too loudly) 11:37:02 (expanding sample syntax to a query with multiple optional blocks) 11:37:35 eric: how about using variables in different optional blocks? 11:37:46 steve: the constraints are complex... 11:38:41 ericp: let's let the editor put this example together and email it 11:39:15 Rob expressed objection to this syntax 11:39:29 6 in favor of this syntax 11:39:46 two are ambivalent (orr abstainging or something) 11:40:24 note that this is just a straw poll 11:40:32 lunch time! 11:42:54 rob: languages that explicitly declare variables make variables in otpionaltype bocks simpler, because scopin is straightforward 11:45:03 break for lunch. 12:23:33 shellac has joined #dawg 12:35:08 Zakim has left #dawg 12:40:33 rob has joined #dawg 12:45:09 starting to boot up after lunch... 12:45:22 excused: JosD, JanneS 12:45:53 AndyS has joined #dawg 12:46:27 Yoshio has joined #dawg 12:49:01 http://www.nokia.com/nokia/0,,62356,00.html 12:49:03 I'm excused. 13:04:19 resuming 13:04:23 publication schedule 13:04:44 AndyS busy 20-24Sep 13:05:30 avail 27Sep-1Oct 13:05:53 DONM 28th Sep 13:06:41 SteveH and DaveB offered reviews 13:06:47 DanC will look for more later 13:07:16 poss publication 35th Sept 13:07:18 AlbertoR has joined #dawg 13:07:29 also known as Oct5th 13:08:15 DECISION to publish Oct5th based on reviews from 28thSep 13:08:29 i.e. folks should expect a decision; we didn't just make one 13:09:22 Editting finished by Oct 1 13:11:19 discussion of the issues list 13:11:31 ACTION DanC: talk with Kendall about issues list maintenance 13:12:14 ACTION DanC: add a pointer to the issues list to the DAWG home page (if it isn't there) 13:12:34 new name candidates 13:13:49 added to the issues list item 13:14:02 looking at http://www.w3.org/2001/sw/DataAccess/issues.html 13:14:28 protocol 13:17:29 http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0363.html 13:17:34 "source of a triple" thread 13:18:14 digression to xml format for results 13:20:16 DaveB - xml result format, would take it and make skeletal doc, add schema 13:20:20 maybe rename to match terms 13:20:26 EricP - prefer tesrseer 13:20:28 terser 13:20:53 SteveH - like tr and td and th idea 13:20:59 DaveB - will think about that 13:21:26 maybe put in a namespace 13:21:49 DanC - give it a or namespace else say why not 13:21:56 Alberto - +datatype & lang 13:22:16 EricP - argument for namespace - may want to later on add extra annotations such as proof. compositiblity 13:23:49 flat 13:24:03 DanC - protocol doc 13:24:17 what would I put to say to a competent programmer to do this protocol 13:25:03 DaveB - recipe style 13:25:35 Kendall - joseki with some (not many) changes 13:25:35 13:25:35 ?name?email 13:25:35 Bob 13:25:35 13:25:49 rdf:datatype="" 13:25:58 Kendall - identifying server query points and models 13:26:54 re: tr, th approach Mmm, I don't like it. those tags doesn't bear the meanings 13:26:54 RDF Net API: http://www.w3.org/Submission/2003/SUBM-rdf-netapi-20031002/ 13:26:59 and http://www.joseki.org/protocol.html 13:27:45 looking at QUERY: HTTP GET 13:28:07 the URI without the ?query_string gets the model in a syntax [rdf/xml?] 13:28:21 Kendall - confused about that; sending query to a graph, plus also haveing FROM in the QL 13:28:52 SteveH - similar thing to this, no model stuff 13:29:15 AndyS - FROM is really for the local case 13:29:45 Algae has from 13:30:41 EricP - annotaa does the getting the model when there is no Q like Joseki 13:30:49 AndyS - you can say you don't support that 13:31:23 ref to Atom Protocol work 13:31:31 take some of the good points from there 13:31:51 atompub ietf wg http://www.ietf.org/html.charters/atompub-charter.html 13:32:03 http://bitworking.org/projects/atom/ 13:32:59 DanC initution is that the no-querystring result should be documentation (html) 13:33:05 maybe machiner eadbale 13:33:49 no, not html. 13:33:55 a service description. 13:34:28 e.g. { <> a :Service; :expertIn :Biology, :Finance; :authoritativeOn :Kingdom, :Phylum, :stockPrice }. 13:34:45 http://www.xml.com/pub/a/ws/2004/02/03/atom8.html 13:37:03 http://bitworking.org/projects/atom/ 13:37:58 draft of autodiscovery for finding a feed from a w web page 13:38:21 Atom API Quick Reference 13:38:22 http://bitworking.org/news/AtomAPI_Quick_Reference 13:38:26 that's pretty good, actually 13:39:23 kendall was going to go write a protocool design doc 13:39:38 DanC - what's new is services ... 13:39:55 ... marketplace here - can you convince these services to conform to this 13:40:48 ACTION Kendall: write a protocol document draft 13:40:57 Annotea protocol --> http://www.w3.org/2002/12/AnnoteaProtocol-20021219 13:41:10 +1 Kendall 13:41:23 EricP - my code does this annotea protocol 13:41:35 I can help to review the doc 13:41:52 POST to make a doc, GET to get it (sic) 13:42:07 query the service about a doc 13:42:47 looking at http://www.w3.org/2002/12/AnnoteaProtocol-20021219#Algae 13:42:57 but doesn't show the url encoding of the algae query 13:43:32 DanC - not customised for info for us; re URLs 13:43:43 EricP - issues brouguht up - querying a document or querying a service? 13:43:52 ... seems to be we are prefering querying a service 13:43:55 ... ISSUE 13:44:15 NEW ISSUE: protocol URIs are for services or for document/graph/models? 13:45:01 Kendall - starting from Joseki, first thing I want to address is the above issue 13:45:10 ... "What are you sending your query to?" 13:45:25 TomAdams has joined #dawg 13:46:06 EricP - other issue ... if you are sending a query to the service not to the document.... 13:47:19 ... REST FAQ 13:47:42 ... CGI url-encoded the params 13:49:13 GET /service?rq23=SELECT * FROM <../doc1> WHERE (?s ?p ?o) 13:49:41 ACTION 7 = KendallC: draft a protocol document (est delivery in 1 month) 13:50:12 discussion of FROM in the QL 13:50:23 GET /service?from=../doc1&rq23=SELECT * WHERE (?s ?p ?o) 13:51:28 GET /doc1&rq23=SELECT * WHERE (?s ?p ?o) 13:52:19 comparing to GET index.tmpl?page=12345 13:53:21 and URIs like /index.tmpl/12345 13:53:33 (evolution of ?foo is not in URI-space, where as evolution of /doc1 and /service is) 13:54:18 EricP - if we send a queyr to the document rather than service, we loose some of the document compositibility possibilities 13:54:39 +1 13:54:45 however it's easy to see how to do this lke a ,rdf-query=.... suffix to a web page (W3C tech) 13:55:17 ACTION ericp: follow up on " if we send a queyr to the document rather than service, we loose some of the document compositibility possibilities" in email 13:55:25 querying an aggregation - give it a uri 13:55:54 new item 13:55:59 border of query language and protocol 13:56:24 "source of a triple" http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0363.html 13:57:20 DanC presents email above 13:57:21 dirkx has joined #dawg 14:00:36 danbri_dna has joined #dawg 14:01:02 data + rdfs rules & applying the query 14:02:13 let's not bind ?src to a.rdf, when it's not the graph you qyer 14:02:15 query 14:02:47 ... the graph queried is triples in a.rdf + more triples made by inferencing 14:03:07 AndyS - it's something else and important, so give it a different URI 14:03:23 I think it's an extremely bad idea to standardize anything which is expected to read a language definition as input and also process that language...Goedel said a few things about the generality of this approach... 14:03:37 SteveH - provenance issue also - was it said or implied 14:10:28 point is, to keep a.rdf and it's rdfs closure distinct 14:11:33 currently we have source that in FROM is the URI of documents 14:11:49 but SOURCE that is the graph (?) 14:13:23 ref to section 10 14:13:33 Hmm, as long as we don't have a name for a graph, what can we do? 14:13:43 ... to query pattern GP on G+mapping from URIs to graphs (or resources to grpah) 14:13:49 [need to think more, DanC] 14:15:45 Yoshio, my guess is we can get away withont a name for the graph 14:15:57 agenda review 14:16:43 kendallc ok, this sucks, but it's at least different: 14:16:43 kendallc It should be possible to query an RDF graph to find the parents, 14:16:43 kendallc children, and instances of a class, as well as the types and 14:16:43 kendallc properties of instances. Syntactic sugar for these kinds of query 14:17:15 kendallc shall be considered to satisfy this objective. 14:17:57 ground facts 14:18:35 Kendall - kind of schema queries that rdf schema editor tools 14:18:39 query such things to a RDF graph? whta objective? (I lost the context) 14:18:47 ... like all the jena methods (above) for querying models [for schema info] 14:18:48 q+ 14:19:38 EricP - might be a mechanism that looks like the extension mechanism for other features 14:19:43 isGroundFactOf() 14:20:01 AndyS - in Jena, two places comes up - in Ontology API 14:20:09 where you are actually looking at the Ontology 14:20:17 such as in an ontology editor 14:20:23 TomAdams has joined #dawg 14:20:26 other place is in the rules engine 14:20:43 when you want to write a rule that does direct subclass/not 14:20:53 and does this via magic properties 14:20:55 no reall other choice 14:21:01 if you only have triples 14:21:06 14:21:17 SteveH: could have a keyworrd GROUND 14:21:25 AndyS or FROM on a triple 14:21:35 like tucana does 14:22:37 I see serql has {X} serql:directSubClassOf {Y} 14:22:40 etc 14:24:00 kc on 4.6 http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0491.html 14:24:09 SeRQL and RQL both have this kind of support 14:25:51 go in as a use case? 14:26:23 some people want that 14:28:33 RobS could get the inferencer to add extra triples/properties to describe what is/isn't ground 14:31:19 discussion of 4.6 shows support for the ontology editor use-case, but not much support for any paticular objective 14:32:40 ACTION KendallC: provided updated UC&R as candidate for publication. [due in the next 2 to 3 weeks, in time to get the WG to decide on 5 Oct] 14:33:14 DONE: ACTION Kendall: Pester Aditya about scheme/metascheme query support re: SWOOP 14:33:24 http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0502.html 14:34:16 DONE: TomA: finding a use-case for distinguishing direct and indirect transitive predicates. http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0502.html 14:34:38 I've asked some of customers for input on this, no reply to date. 14:35:08 I wouldn't really call it a use case, just a statement of what we've implemented, and how it's exposed. 14:38:32 http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0327.html 14:38:40 that's good enough for us, TomA 14:39:00 from source mean different things? 14:39:35 service, document, graph 14:39:47 FROM is service|document but also graph? 14:39:55 SOURCE deals with a graph? 14:40:45 AndyS - FROM makes a graph from URIs given in the FROM 14:40:51 whereas SOURCE refers to that graph 14:40:58 Alberto - FROM is the graph 14:41:06 ... the protocol action 14:41:10 ... wherase SOURCE is about the graph 14:41:49 ... here some property dc:source could related a document and a graph 14:41:54 ... or dawg:source 14:41:58 DanC - like log:semantics 14:42:42 graphs seem to be in the data model 14:43:53 request to write a query that uses FROM that cannot be done with SOURCE 14:44:18 Alberto - virtual graphs such as in the foaf personal example from Alberto 14:45:09 ACTION Alberto/Steve: edit the examples in http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0327.html into test cases (either positive or negative tests) 14:45:34 tests 14:46:16 break for :15 15:25:04 well, 15ish 15:26:25 -- resume 15:26:38 we're back 15:27:10 4.2 & 4.5 pending 15:27:30 Kendall - consolidate 4.2 & 4.5 15:27:55 RobS - think we have accepted them as objectives 15:28:38 andy thinks they are diff 15:29:50 4.2 doesn't talk about the target of a query 15:29:57 or querying 15:30:01 4.2== SOURCE, 4.5 == FROM? 15:30:09 4.5 specifying more than one target, more about the input side of the query 15:30:26 AndyS ... 4.2 allows you to get the information out 15:31:07 Alberto see as FROM, where you get the data - merge 15:31:25 ... and 4.5 some way to connect to sources, but more about providing some constraints in how you merge them 15:31:34 ... 4.5 ismore general 15:33:29 4.2 bigger graphs merge, from 15:33:41 4.5 dealing with virtual graph exposing multiple sources 15:33:58 (some comments about the shortness of the objectives, inter alia http://lists.w3.org/Archives/Public/public-swbp-wg/2004Sep/0049.html ) 15:35:28 TomAdams has joined #dawg 15:38:20 suggestion torename 4.2 to "9 Querying the Origin of Statements" from rq23 15:39:28 kc: ammendment: s/Origin/Source/ 15:42:18 rdf repositories - data from multiple sources 15:43:35 proposal to swap 4.2/4.5 titles 15:43:45 Hmm, ambiguous 15:43:51 PROPOSED: "4.2 Querying Multiple Sources ... which of the available rdf graphs ..." 15:44:20 Querying Multiple Sources could be read as "Quering to Multiple Soruces", no? 15:45:41 PROPOSED: "4.2 Querying Multiple Sources ... which of the available rdf graphs ..." and "4.5 Querying the origin of triples ... can be used for data integration and aggregation ..." 15:46:41 Why do we need "Multiple" then? 15:46:48 in 4.2 15:47:00 multiple as opposed to one 15:47:13 but what we get is one source 15:47:26 from multiple sources 15:47:33 no, I read "which of the available rdf graphs" plural 15:47:34 (^_^;) 15:48:03 Hmm, English is difficult 15:49:32 4.2 Querying Multiple Sources 15:49:33 It should be possible for a query to specify which of the available RDF graphs it is to be executed against. If more than one RDF graph is specified, the result is as if the query had been executed against the merge of the specified RDF graphs. Query processors with a single available RDF graph trivially satisfy this objective. 15:49:58 4.5 Querying the origin of statements 15:49:59 RDF can be used for data integration and aggregation. RDF repositories are built by merging RDF triples from several other RDF repositories or from non-RDF sources converted to RDF. Such an aggregations can be real or virtual. 15:49:59 It must be possible for the query language and protocol to allow an RDF repository to expose the source from which a query server collected a triple or subgraph. 15:50:51 ----------- 15:52:06 4.2 Querying Multiple Sources 15:52:06 RDF can be used for data integration and aggregation. RDF repositories 15:52:06 are built by merging RDF triples from several other RDF repositories 15:52:06 or from non-RDF sources converted to RDF. Such an aggregations can be 15:52:06 real or virtual. 15:52:09 It must be possible for the query language and protocol to allow an 15:52:11 RDF repository to expose the source from which a query server 15:52:14 collected a triple or subgraph. 15:52:16 4.5 Querying the Origins of Statements 15:52:19 It should be possible for a query to specify which of the available 15:52:21 RDF graphs it is to be executed against. If more than one RDF graph is 15:52:24 specified, the result is as if the query had been executed against the 15:52:26 merge of the specified RDF graphs. Some services may allow queries 15:52:29 against only one graph; they are considered to trivially satisfy this 15:52:31 objective. 15:52:34 While a variety of use cases motivate this feature, one reason it 15:52:36 isn't a requirement is that it's not clear whether it can be 15:52:39 implemented in a generally scalable fashion. 15:52:43 ]] 15:54:30 It should be possibe for a query to specify against which triples it must be excecuted based on the source of that triple as defined in 4.2 15:57:18 4.2 Data Integration and Aggregation 15:57:19 ... 15:57:24 4.2.1 - Querying mutliple soruces 15:57:25 ... 15:57:30 4.2.2 Querying based on Source 15:57:31 ... 15:59:16 4.2 RDF Aggregation and Querying the Origins of Statements 15:59:16 RDF can be used for data integration and aggregation. RDF repositories 15:59:16 are built by merging RDF triples from several other RDF repositories 15:59:16 or from non-RDF sources converted to RDF. Such an aggregations can be 15:59:16 real or virtual. 15:59:18 It must be possible for the query language and protocol to allow an 15:59:21 RDF repository to expose the source from which a query server 15:59:23 collected a triple or subgraph. It must also be possible for a query 15:59:26 to specify which of the available RDF graphs it is to be executed 15:59:28 against. If more than one RDF graph is specified, the result is as if 15:59:31 the query had been executed against the merge of the specified RDF 15:59:33 graphs. Some services may allow queries against only one graph; they 15:59:36 are considered to trivially satisfy this objective. 15:59:48 ]] 16:00:42 4.2 data integration and aggregation 16:01:04 4.2 data integration and aggregation 16:01:11 4.2 data integration and aggregation 16:01:18 RDF can be used for data integration and aggregation. RDF repositories 16:03:00 If more than one RDF graph is specified, the query is executed against the merge of the specified RDF graphs. 16:03:41 replacing "If more than one RDF graph is specified, the result is as if the query had been executed against the merge of the specified RDF grpahs." 16:03:53 dirkx has joined #dawg 16:08:38 dirkx proposed wording http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0503.html 16:09:28 It must be possible for queries to ask for data from multiple 16:09:34 rdf sources. 16:09:37 dirkx has joined #dawg 16:09:45 It must be possible to query the origin of statements. 16:10:24 Dirk? what's the difference between 4.2.1 and 4.2.3? 16:10:49 a repository can have multiple sources; there can be multiple sources wih multiple repositories 16:11:01 (query Q1 on A) U (query Q1 on B) 16:11:11 query Q1 on (A U B) 16:11:16 Andy brings up a good point; the Origin Server problem versus the Server problem 16:11:55 And that is not clear if you do not already have the pre-conveived idea 16:13:24 AndyS - don't like 4.2.1 distributed query implication 16:14:52 Kendall would change "to expose the source from which that query server collected " to remove the specificity 16:20:26