00:00:10 consensus that we need a formal model (an algebra probably) for what all of the update operations mean, probably including what a dataset is/means 00:00:20 ...or a graph store 00:00:24 ...and/or a graph store 00:00:55 dajobe has joined #sparql 00:02:17 scibe: Axel Polleres 00:02:26 scribe: Axel Polleres 00:02:51 LeeF: what did we miss in the Agenda? 00:03:21 Dave: How will you do propertypaths? 00:03:46 ... seems that HCLS will need it 00:04:11 ... will be substantial work for implementers 00:04:47 other time allowed features: 00:05:28 entailment, basic federated queries, function library 00:06:19 BETWEEN would be sugar, IN probably not 00:06:28 steve: I'd like IN 00:07:17 axel: what about list accessors... we had them in property paths? 00:07:37 LeeF: we probably should adjourn 00:08:24 Dave: scope of function library? 00:09:03 +bglimm 00:09:15 LeeF: mainly xpath string and math functions 00:09:31 ... IF THEN, COALESCE, maybe 00:09:45 SteveH: group-concat 00:10:19 LeeF: Birte? anything on entailment? 00:11:12 Birte: Entailment-telecon on Friday 00:11:29 ... we could quickly discuss entailment URIs 00:13:16 Birte: RIF, OWL RL, RDFS don't have owl:imports 00:14:12 Sandro: Axel and I will go back to RIF and will probably suggest them to add something like rif:imports 00:14:32 ... alternative would be a RIF->RDF serialisation, prbably more difficult 00:14:51 Birte: there is RDF/XML for SWRL rules 00:15:56 Sandro: needed talking to some people (Pat, Peter...) 00:17:01 Sandro: Does the client have an option to define the entailment? 00:18:37 Axel: So far, we have only said that Entailment doc will define what X-Entailment means, but not how to request/advertise it. 00:19:19 So far the client cannot choose or define its own entailment 00:19:21 ... Service Description has so far minimal means for it, but we had discussions of different use cases (Andy brought up that there might be a need for different entailments on different graphs) 00:19:39 ... so far, nothing in protocol 00:20:37 Gregory: doesn't that mean that you'd need to do all possible entailments (in case you have fwd-chaining) 00:23:00 Birte: sandro said at the moment you can't say you are an incomplete OWL/RDFS implementation. 00:23:20 ... not sure whether we want to go that way. 00:23:32 ... at the moment we can't describe that. 00:25:22 ... e.g. OWL2RL supporting inference engine can still do reasoning, but incomplete on OWL DL 00:26:31 Sandro: OWL2RL doesn't do all it can (example by Paul) 00:27:18 Birte: OWL2RL is not really an entailment regime. 00:29:36 Axel: that was the whole idea of RIF-based entailment regime from my side. 00:31:28 Sandro: Don't see much sense in advertising entailment regime 00:31:49 Axel: It makes sense to know which work is "already done" inside the query engine. 00:33:09 ... but that's not trivial. 00:35:31 Axel: I would personally like a way to request entailment, but that's personal opinion and at this point, I don't see it happen in the standard (more important things). 00:36:25 Sandro: is SPARQL extensible in the way that you can add such a request for entailment? 00:36:26 I figured that I could shoehorn this approach into anything the working group comes up with :-) 00:36:47 Some people do that, materialise inferences 00:37:06 LeeF: in the language it would be a syntax error, in the protocol it would be ignored. 00:38:02 Steve: I have reservations on putting it in the language. 00:38:33 I've been considering creating graphs based on original data that contains only entailments. So for a graph named foo:bar, then entailed data might exist in foo:bar_entailed. By default, queries will be applied to their union. 00:38:42 I figured that I could shoehorn this approach into anything the working group comes up with 00:39:20 sandro: that would indicate the need for something like pragmas 00:39:35 bglimm, yes, this id for materializing inferences. This appears to be the best approach for rules. Though the entailed graph can be in RAM 00:39:45 s/id/is/ 00:39:59 Zakim, who is on the phone? 00:39:59 On the phone I see Suite_a, bglimm 00:40:01 Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres 00:40:01 zakim, who is on the call? 00:40:02 On the phone I see Suite_a, bglimm 00:40:03 Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres 00:40:17 pgearon, are you available to call in, if we want to talk about something interesing? 00:40:35 yes, though LeeF told me out of band that you were wrapping up 00:41:07 so I stayed out 00:41:35 +pgearon 00:42:27 probably defining entailment-request as part of the protocol too much of a burden in this stage, even if a simple proposal was made. 00:42:34 Hector Perez-Urbina had a very interesting paper at ISWC 00:42:39 sandro: I think it's okay to leave out client-server negotiation about entailment regimes from SPARQL 1.1 Folks can easily experiment for now now, and add it later. 00:42:57 defninitly, not normative. 00:43:19 paul: was looking at rules for entailment, cover most of what people wanna do. 00:44:00 http://axel.deri.ie/~axepol/presentations/20091029iann-etal-ISWC2009_GiaBATA.pptx 00:44:33 sandro: is this part of service description? 00:45:09 paul: we can put it there, but not per graph, probably, that's difficult with many graphs. 00:45:20 ... not standard, at least 00:45:55 kasei: pointing to the non-mandatory parts of service-descriptions discussed earlier. 00:46:44 so a graph/resource has a description that also says which entailments have been/will be applied to that graph? 00:47:38 Axel: by the rdfs:domain of sd:supportedEntailment we prohibit that the same property is used for describing graphs 00:48:26 discussion whether we need description whether one graph entails the other in SD. 00:48:43 but that is not what Andy wanted 00:49:56 bglimm, I'm describing a system where graph resources (ie. the name for a graph) has a description which says where entailments for it have been generated 00:49:59 sandro: <..../entailment/RDFS> 00:50:19 axel: uuuuh, sounds scary to reuse entailment URIs as predicates. 00:50:23 ah, ok, sound quality is quite bad, so I can not understand everything 00:51:22 sorry, Birte, we're all tentative, so we're speaking more softly. 00:51:27 discussion whether this should be in mandatory part of SD... probably not. 00:51:58 Birte: use case of Andy, was querying for subclasses and/or direct-subclasses. 00:52:24 ... andy models this by having two graphs, one with simple only, one with RDFS closure 00:55:21 Axel: Question is: Do we want SD to cover that? Do we want existing properties such as sd:supportedEntailment to be usable that way (i.e. describing Graphs in the dataset, insead of services) ... I personally think we may want to start small. 00:55:35 ... in terms of what we put in the core part of SD. 00:56:03 Axel: propose to adjourn 00:56:29 Thanks everybody! 00:56:43 rrsagent, make record public 00:57:32 -bglimm 00:59:19 bglimm has joined #sparql 01:02:23 I was refering to http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt 01:02:40 e.g. Link: ; rel="previous"; 01:02:40 title="previous chapter" 01:12:35 Zakim, who is on the phone? 01:12:35 On the phone I see Suite_a, pgearon 01:12:36 Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres 01:12:49 -pgearon 01:12:56 -Suite_a 01:12:58 SW_SPARQL(TPAC)11:30AM has ended 01:12:59 Attendees were kasei, AxelPolleres, AndyS, bglimm, LukeWM, +1.919.543.aaaa, dcharbon2, Prateek, kjetil_, sandro, LeeF, SteveH, dajobe, pgearon