RDF Data Access Working Group Face to Face Meeting, 2 - 3 March 2006

issue: nestedOptionals

• issue: nestedOptionals
  proposals:

  • Optional patterns can occur inside any pattern, including another optional pattern, forming a nested pattern. The outer optional block must match for any nested one to be matched.

    section 5.5 Nested Optional Blocks of the 17 Feb WD

  • leave nested optional blocks out of the syntax of SPARQL QL, e.g. by side condition on the grammar

We reviewed the editors' proposal for nested optionals. SteveH argued to leave them out of the language because the implementation cost is significant and the benefit to users is unclear. We looked at some examples and discussed the relationship between a query with nested optionals and an analagous "flattened" query:

OPTIONAL {
  ( ?x  vcard:N ?vc )
  ( ?vc vcard:Given ?gname )
  OPTIONAL ( ?vc  vcard:Family ?fname ) }

The flattening involves some repetition:

OPTIONAL { ( ?x vcard:N ?vc )
           ( ?vc vcard:Given ?gname ) }
OPTIONAL { ( ?x vcard:N ?vc )
           ( ?vc vcard:Given ?gname )
           ( ?vc vcard:Family ?fname ) }

Jos asked for clarification of the semantics of all optionals: A optional B might be interpreted in one of two ways:

1. A & (B v True)

   which creates unhelpful solutions

2. A & (B v ~B)

   where ~B means "B is not a subgraph of the the background graph" (denoted ... log:notIncludes B in the discussion, alluding to an N3 idiom).

Jos observed a closed-world assumption in the latter interpretation, and asked if it was by design. AndyS and EricP said that yes, it was. DanC said he thought the WG was aware of this in design discussions around optionals, but suggested noting it explicitly in the spec. ACTION AndyS: to clarify 5.4 w/r/t closed world assumption

Discussion returned to nested optionals; Yoshio expressed some reservations about the complexity of the constraints on the use of variable names.

Discussion reached a point where the advocates of nested optionals and those that argued to exclude them maintained their positions strongly but were unable to come up with new reasons to convince the other. DanC considered putting the question over the objection of one side or the other, but instead encouraged both sides to consider the matter outside the meeting. Discussion continued in a later item on nestedOptionals.

f2f6 proposals

• Asemantics S.r.l offers to host F2F meeting in Leiden 19-20 May, 2005.

  Reggiori 31 Jan

• ACTION: SteveH to propose to host in Southampton right after XTech ( done
• Hayes/Florida

We considered the above offers to host, as well as an offer from AndyS to host in Bristol, and the interaction between a meeting of this group and events such as XTech, ESWC, and WWW2005 10-14 May. There was not a critical mass of support around any of them.

A one day meeting before (or after?) WWW05 got some interest. A poll about plans to attend WWW2005 showed -JD +AS ~KC +YF +HS +EP +SH -DC ~-PH.

We acknowledged the risk that if we don't decide today when and where to hold our next face-to-face meeting, our schedules may fill up, making it inconvenient to do so at a later date, but moved on to other items.

test suite maintenance

for ref: test materials, turtle

We reviewed a few action items:

ACTION SteveH: to to revise test manifest w.r.t. "background" and named graphs CONTINUES

ACTION JosD: Jos to propose an optional test based on ACTION op:dateTime triple CONTINUES.

ACTION SteveH: to to propose tests for str() and =~ CONTINUES.

DanC clarified that action by sketching a test:

SELECT ?PG WHERE
      ?PG dc:creator ?anybody AND ?PG =~ "http://www.w3.org/".

should NOT match { <http://www.w3.org/> dc:creator "anybody" }

ACTION DaveB: to to propose source test to approve CONTINUES

AndyS noted GRAPH tests untrusted-graph*.rq and source-named/manifest.n3 and we looked them over, along with the definition of RDF Dataset. DanC's action regarding definitions for SOURCE is WITHDRAWN.

DanC asked steve how the test suite page is generated from the manifests and such. SteveH explained that it involves 3store and some perl scripts which he has cheked in. He sent a transcript of running the makefile. ACTION EricP: to pair with SteveH on making the HTML test results page.

issue: valueTesting

• issue: valueTesting

ACTION JosD: to review value testing section CONTINUES. (partial progress)

AndyS and EricP presented their design for valueTesting in the form of some example from the tests/data/ExprEquals directory:

evaluated against

Ivan noted that rdflib reads "1" as 1, but KendallC pointed out that its handling of datatypes is known to have bugs.

We also looked at tests/data/ExprEquals/query-eq2-1.rq, which shows how the = syntax relates to functions and operators, obsoleting ==, eq, and ne. Yoshio pointed out that the editor's draft still shows == in some places; the editors acknolwedged this as a bug.

TimBL suggested re-using the investment in valueTesting test cases by copying them to graph test cases. e.g.

... (?x1 :p ?v1 )
    (?x2 :p ?v2 )
    AND ?v1 = ?v2

has an analog...

(?x1 :p ?v)
(?x2 :p ?v)

ACTION AndyS: to add the above graph test cases

We discussed not-equal tests, in particular the relationship between "known to be not equal" and "not known to be equal":

SELECT ... WHERE
    (?exp :results ?x) (?exp2 :results ?y) AND ?x != ?y

against { exp1 result "1/1"^^rational. exp2 result "2/2"^^rational).

EricP thought the editor's design would have the != test fail, which TimBL supported. But AndyS walked through the evaluation in more detail and found that the != would turn into fn:not(... = ...) and since the = test would fail, the fn:not(... = ...) test would succeed. EricP and others seemed confident this could be fixed.

PatH asked about the case of "abc"^^integer. DanC encouraged that to be captured as a test case. Other cases that seem worth testing include:

• "10"^^byte = "10"^^integer?
• "10"^^long = "10"^^integer
• "10"^^nonnegative = "10"^^integer?

ACTION EricP: to propose to close valueTesting (bonus points for test cases, to EricP or others)

Jacek pointed out the list of datatypes in a section of the RDF model theory spec and suggested they should all be supported by SPARQL. DanC encouraged Jacek to discuss such a proposed requirement in the break, and pointed to the XSCH document as reasons why not, which brought us to our next agendum

XSCH review

• XML Schema Datatypes in RDF and OWL Editors' Draft Date: 2005/01/27 20:06:45

PatH is done reviewing it. As a WG, we don't see any issues to raise at this time, though we may take another look after it's published as a WD. EricP's action to review it is WIDTHDRAWN.

issue: punctuationSyntax (turtle, N3, ...)

DanC invited TimBL to discuss SPARQL punctuationSyntax with the group, after consulting a few WG members in the break, as a way of addressing the risk around our decision in Helsinki to adopt (s p o) syntax over EricP's objection. Since this wasn't on the agenda well in advance and some of the advocates of the status quo weren't present, DanC said we would make no binding decisions here. Kendall advised adding this to the issues list, and DanC agreed:

• issue: punctuationSyntax

We reviewed the examples from Helsinki; after some discussion of what exactly EricP had been proposing then, DanC projected a number of examples and we went over them together:

SELECT *
WHERE { ?p ?s ?o }

# NO
# SELECT *
# WHERE { ?p ?s ?o }.


##

PREFIX foaf: <http://example/foaf#>

SELECT ?me ?you
WHERE { ?me foaf:knows ?you. ?you foaf:knows <fred> }

##

@@
WHERE { ?me rdf:type foaf:Person.} # trailing thingy in lexer
WHERE { ?me rdf:type foaf:Person .} # parses same as above


WHERE { GRAPH ?g  { ?g dc:source myPartOfUriSpace:foo.rdf } }  # sh, ar like this
  # tibml doesn't like it. cwm, jos, timbl note this implies an N3 change
  # SH notes not doing this involves a difference from turtle
  # closer to XML (but not quite, see above)
  # yes.


##
PREFIX foo: <http://www.w3.org/>
SELECT ?p ?o
WHERE { ?s ?p ?o . ?o ?p2 ?o2}

##
PREFIX foo: <http://www.w3.org/>
CONSTRUCT { ?s foo:bop ?o2 .
            ?o2 foo:bing ?o }
WHERE { ?s foo:bar ?o .
        ?o foo:baz ?o2 }


##
WHERE { :bob :brothers (:joe :sam) }

##
WHERE { ?doc dc:title ?txt; dc:author ?who }

##

WHERE { ?who :has ?car, ?boat. ?car rdf:type :Auto. ?boat rdf:type :AquaVehicle }
WHERE { ?who :has ?car, ?boat; foaf:knows ?f1, ?f2 }.
# commas in XML names?

##

WHERE { ?who a foaf:Person } # yes

WHERE { ?who = ?whoElse } # *not* short for owl:sameAs

#
SELECT ?who WHERE { ?who :brother [ in Army ], :mother [ in Navy] . }

SELECT ?who WHERE { ?who :borthers (:pete :sam). }

# AK notes AND can/could go as a result.

SELECT ?who WHERE { ?who :age ?n. FILTER ?n + 1 < 5 }
SELECT ?who WHERE { ?who :age ?n. SUCHTHAT ?n + 1 < 5 }
SELECT ?who { ?who :age ?n. WHERE ?n + 1 < 5 } # EP, SH, ? perfer. like SQL, in a way

# no SELECT ?who WHERE { ?who :age ?n . ?n + 1 < 5 } # AFS: list () interferes
#SELECT ?who WHERE { ?who :age ?n AND ?n + 1 < 5 } # KC, SH prefer
#SELECT ?who WHERE { ?who :age ?n. (?n + 1 < 5) } # ew

One summary was "turtle plus variables".

SteveH said his users are mostly folks dumping databases into RDF/XML; he supports turtle input and noone uses it.

There was some discussion of whether it's essential to choose just one syntax. The possibility of a number of presentation syntaxes, with an exchange syntax in XML, was discussed.

The details of qname syntax, especially where periods are allowed, was discussed at some length. IRC notes starting 21:52:42Z have some additional technical details.

DanC observed some support for "turtle plus variables" and the editors seemed interested to persue it. DanC asked if the WG would like to see a proposal edited into the editor's draft. Preference seemed to be for a separate email proposal. DanC was to send the examples we discussed to EricP who would send them to the WG. ACTION EricP: to propose results of N3 syntax discussion to DAWG

introductions

DanC introduces the WG members and some of the observers to each other. Elias, Lee, and Jordie from IBM described some of their work on a Semantic Web toolkit for life science research. At the W3C Workshop on Semantic Web for Life Sciences, the IBM position paper, Knowledge Integrated Modeling (KIM), an application for the Semantic Layered Research Platform (SLRP) discussed their work.

issue: nestedOptionals

continued from Monday's discussion...

• issue: nestedOptionals
  proposals:

  • Optional patterns can occur inside any pattern, including another optional pattern, forming a nested pattern. The outer optional block must match for any nested one to be matched.

    section 5.5 Nested Optional Blocks of the 17 Feb WD

  • leave nested optional blocks out of the syntax of SPARQL QL, e.g. by side condition on the grammar

After some review of the arguments for (design coherence) and against (implementation complexity) and some straw polls, we RESOLVED to close issue nestedOptionals as per http://www.w3.org/TR/2004/WD-rdf-sparql-query-20050217/, with JosD, KendallC, Bijan, SteveH abstaining

SPARQL abstract protocol, WSDL

We looked at SPARQL Protocol for RDF editor's draft Revision: 1.17 of 2005/02/26 21:51:28

ACTION KendallC: discuss warnings in the protocol spec continues.

DanC went over his input in the form of a protocol spec. Kendall noted this treatment of Warning might be too specific to HTTP caching. Bijan said this treatment of the protcol doesn't meet Fujitsu labs's needs because it doesn't have an abstract layer so that they can relate it to SOAP. He sent some notes on Fujitsu's implementation experience, with OWLBase.wsdl attached. Regarding "ACTION: EricP: to investigate WSDL/SOAP encodings of SPARQL protocol" EricP offered SPARQL-P.wsdl. We reviewed our Addressable Query Results design objective, and discussed WSDL's ability to describe GET as well as POST interactions.

DanC noted that the number of requests for a WSDL description seems to be reaching a critical mass, though we don't have a relevant requirement. He asked to discuss use cases.

Bijan said that Fujitsu does large-scale integration; their middleware uses RDF & OWL, they have a protocol that allows querying
... they want to interoperate with everything that uses Web services
... all the MS Office operations now support SOAP
... so they want to be able to call uniformly SPARQL or Word. Observers from IBM said their experience was similar. JMS was another example of a protocol besides HTTP where a SPARQL binding would be useful. A poll showed considerable support for adding this requirement, and we RESOLVED: A WSDL description shall be included in the protocol specification, AndyS, JosD abstaining. ACTION Bijan: to propose text (story? etc.) to support WSDL requirement ACTION EricP: to review WSDL text proposal

Bijan asked should the story mention or not mention specific companies? DanC expressed a small preference for specifics. Kendall said the other stories are "sanitized"; DanC said that mentioning one specific company brings some obligation to mention others, to be fair.

EricP introduced a protocol spec based on WSDL, aimed at readership that doesn't already know WSDL
... the URI encoding is like CGI parameters
... it has parameters and normative binding to HTTP

Then we did an excercise to (a) learn WSDL and (b) compare the abstract protocol from the editor's draft with the WSDL description EricP had drafted. DanC edited a WSDL description in realtime:

We skipped over much of the material on types and faults. The OperationPoint class seemed to match WSDL's notion of endpoint.

We discussed WITH/FROM QL syntax vs. putting it in the protocol, and what to do if it shows up in both places. We explored putting it in the protocol, and deferred whether to keep it in the QL. Bijan asked about putting it in an attribute, but Jacek pointed out that we need to use an element in order to match the WSDL URI operation style.

DanC paused before transcribing the getGraph abstract syntax, asking if it belonged. Andy argued that while it seems very useful, it doesn't seem specific to SPARQL. JacekK pointed out that WS-Transfer specifies a a GET operation. Kendall said that we still need to discuss how to get the whole graph. Steve and others offered CONSTRUCT * WHERE GRAPH <uri> (?x ?y ?z). That wasn't quite right, but discussion of the details was taken offline: ACTION AndyS: to explain how to get a whole graph with CONSTRUCT * and GRAPH. ACTION KendallC: to refer to "get the whole graph" explanation from protocol spec

Then we discussed getServiceDescription. EricP said it looks like the namespace document problem. JacekK pointed out that discovery is already handled in the protocols (HTTP OPTIONS, SOAP WS-MetadataExchange). AndyS said it seems orthogonal and not somethign we should require. DanC asked about including it in a separate interface, and that got quite a bit of support. It was PROPOSED: that the SPARQL WSDL description shall have 2 interfaces (SPARQLQuery and SPARQLDiscovery), each with one operation, but a poll showed insufficient support. ACTION KendallC: to add WSDL description of protocol to editor's draft, propose to WG.

issue: fromUnionQuery

DanC attempted to summarize the long history of this issue: if you say FROM URI1, URI2 is that the union, the merge or what? In our Helsinki discussion of fromUnionQuery, we had three groups of options
... the URIs were only hints in the first version
... then: drop FROM/WITH and leave it to the system
... later: specify what the keywords do

AndyS reported on the current editor's draft: the FROM accepts list but we don't say how. He noted that the test cases need to specify the dataset even if there's no QL syntax for it. He noted a proposal from Alberto based on comments: to s/WITH/FROM/ ; s/FROM/FROM NAMED/.

Andy re-iterated the local queries requirement: sometimes we don't have a protocol. SteveH argued that there's always some API...

We discussed possible intereactions, e.g. in case of mySvc?query=$query;from=http://ex/data.rdf where $query = SELECT ?x FROM http://exb/datab.rdf .

DanC pointed out the separate "RDF content URIs" field of the Redland Rasqal RDF Query Demonstration, and said that appealed to him. AndyS pointed out that sparqler does it the other way. DanC polled for support for taking FROM/WITH out of QL; 3-ish seemed in favor. DanC asked the editors what the impact would be; AndyS said it seems to involve taking out section 9

Andy clarified that no, this doesn't impact the GRAPH (nee SOURCE) keyword syntax. That brought up some concerns from SteveH about how RDF datasets work in the case of SELECT ?a WHERE GRAPH ?g ... vs SELECT ?a WHERE .... Andy noted a 28 Jan message with a number of example datasets. We looked at an example in section 8.4.

After quite a bit of discussion, much of which escaped the chair and the scribe, Contingent on agreement to a proposal to have DataSet in our WSDL description, we RESOLVED: to remove section 9 Combining WITH and FROM from QL; i.e. remove WITH/FROM syntax. abstaining: AnydS, Yoshio, HiroyukiS abstaining..

issue: protocolRootReferent

• issue: protocolRootReferent

RESOLVED: that doing WSDL addresses protocolRootReferent. abstaining: KC, SH.

Service Descriptions (SADDLE)

We returned to SPARQL Protocol for RDF editor's draft Revision: 1.17 of 2005/02/26 21:51:28, which discharges his actions: KendallC to to think about predicate to relate html-forms and svc descriptions, and how this goes into the spec; KendallC to Add section for service descriptions and put graph specifying in it to start it off; to wit: section 7. SPARQL Service Advertisement and Discovery Language (SADDLE). Kendall updated us on his progress: I did some changes to naming, added invocableOperations ...
... added saddle:operationTarget to tell me which graphs I can interact with
... added acceptSerializationFormat...
... nervous about acceptSerializationFormat, redundant to content negotiation
... another issue - how do you identify the various subsets of OWL
... invocableOps can contain IDs of the ops in our protocol
... can vary according to graphs, can choose not to support GetGraph on a huge graph

SteveH asked how to express support for extended functions (&ex:myFunc(?x)), and reiterated hopes forsomething where you wouldn't have to repeat the properties shared between services

DanC reiterated (from Helsinki) the observation that protocol description is an arbitrarily large design space and that service descriptions are open ended and can use arbitrary RDF vocabularies, so we should focus on our own experience: let's look for terms where two parties can demonstrate interop.

Yoshio asked if saddle:supportsDatatype was limited to XSD types; Kendall clarified: no, any datatype is fine. Questions about operations on datatypes led to no clear answers.

DanC asked how OperationPoint works. Kendall said that if something is an OperationPoint, you can GET a service description there. DanC said he thought servicing queries at uri X needn't imply offering a service description at X. Discussion of service description resumed after SPARQL abstract protocol, WSDL. DanC edited some service description material on-screen. The result was:

We discussed the impact of a dependency on WSDL 2.0. Bijan said he expects a second last call soon. EricP said he thinks the part we depend on is not likely to change. Bijan said that the WSDL/RDF mapping is likely to finish at the same time as WSDL 2.0, so depending on it doesn't lengthen our schedule. AndyS and DanC expressed some concerns. Bijan said it would be useful to have also WSDL 1.1 (perhaps non-normative).

DanC: do we need a superinterface to the two we already have? will we have to do transitive closure?

bijan: the RDF mapping will do that transitive closure itself

DanC: we need to redecide on the interfaces

We discussed the combination of the SPARQLQuery and SPARQLDiscovery interfaces. Bijan pointed out that interface inheritance will be done "before" mapping to RDF, so the combination interface won't show up in RDF. RESOLVED: that the SPARQL WSDL description shall have 3 interfaces (SPARQLQuery and SPARQLDiscovery and SPARQLQueryAndDiscovery), each with one operation, contingent on agreement to adopt a WSDL descriptiona WSDL description; AndyS, JosD abstaining

Discussion resumed briefly after lunch...

ACTION KendallC: to incorporate service description discussion notes in protocol spec

Discussion resumed after a break, when Bijan re-joined us. We fidgeted to get the whiteboard near the phone and such...

Bijan explained how in OWL, sometimes the "deductive closure" isn't well-defined, especially in cases involving disjunction. We discussed an example: :bob :loves [ a [ owl:unionOf (:Students :Faculty) ] ]

We discussed SteveH's "computer science lit" service... it's "close over RDFS" in some sense. we're considering: _:ukLitSvc saddle:closedOver rdfs:semantics. ACTION Bijan: to work on "closeOver" work-alike with SteveH

Chair is considering acknowledging ServiceDescription as an issue.

Plan for last call

DanC reviewed the WG schedule: LC was to be 17 March but things have changed. Kendall asked how long LC should last; DanC said it has to be at least 3 weeks, and it should be long enough to get responses regarding our dependencies, e.g. did we use XQuery functions and operators correctly? Speaking of which, PaulC wandered in and noted that XQuery plans to go to last call (really last call this time, he thinks) 4 Apr, and DanC agreed to get DAWG to review it during the 3 to 6 weeks that follow.

We discussed whether all our docs should go to last call together or separately. Issues that span documents argue for going to LC together, but not compellingly. Bijan estimated that he could get better review if the QL and protocol went separately. There was some support for doing LC 1st and protocol a few weeks alter. Test case development was likely to go that way too.

Bijan asked DanC to consider adding the XML Schema connection to VBR to the issues list. Yoshio asked about privacy/security. ACTION KendallC: to add "since we're using WSDL, you can use WS-Policy..." to protocol draft. ACTION DanC: to consider adding 'privacy/security' issue, even if we're most likely to just postpone it or mention it in passing in specs

Kendall noted 2 open issues for QL: fromUnionQuery and punctuationSyntax. DanC expresed a hope to close syntax issue in the March 8 telecon.

Our best guess for Maybe LC candidate (for review by WG members, leading to an LC decision) for the QL is March 31. Regarding schedule and availability, AndyS plans to take vacation April 1 - 8. For protocol, best guess is maybe 4 Apr for LC candidate.

Protocol testing

We briefly discussed protocol testing, with no actions nor decisions.

update/insert/manage

DanC added this item to the agenda to take advantage of input from observers. He noted that section 2.4 Graph Update Protocol of our charter is listed under "out of scope", though Kendall has pointed out that the text doesn't clearly rule it out of scope. DanC said some notice to the W3C membership seemed in order before beginning substantive work on update in any case, and an activity proposal seemed like the wise thing to do, to get explicit mandate; then a WG should start with story-telling/use-cases/requirements and so on. He invited each person at the table to tell their experience with update protocols and give input to the standardization discussion.

DanC

We have a research paper on diff/delta.

Bijan

There is considerable prior work on ontology evolution. We have done some work on a Diff format for RDF graphs and OWL ontologies using Annotea. If not updating the expressed/told graph, deleting is difficult. Biggest issue: if yr not updating the told graph only, then you have choices about deletion... Deleting an inferred triple might require truth maintenance. Like the view update problem, only worse.

Kendall

Being able to add/delete told triples would be of near term use to UMD clients

Lee/IBM

Only working w/ told graphs right now, but everything is collaborative, so they need to be able to ready *and* write.

V. interested in change history over graphs for auditability

interested in transactions for graph changes; and managing resource contention ... locking, update/merge before write ... do we use XML documentsfor atomicity of changes?

notification of graph changes by giving server a pattern -- via JMS... pub/sub... triggers

... with reification, we've be able to address [update/delete] individual statements

SteveH

Have been playing with SQL-style INSERT and UPDATE... but deployed code is just POST/PUT to replace or augment an exisitng graph

HiroyukiS

welcome DanC's proposal from a user's perspective

Yoshio

Is it necessary to delete/make others delete obsolute triples? just asserting them as obsolute is not enough? (leaving the others decide whom/what to believe) ... worried about user experience if there is inconsistency consequence of an update

just asserting statements is enough. leave for user to decide what it correct. ... inconsistency could be nature of RDF world

TimBL

subscription to a form of query is the dream... interested in applying a patch derived from graph to another

DanC for BrianT

DanC: BrianT's customers are gangbusters on update

Kendall

Working against told triples is worth standardizing

AndyS

groupware problems different from RSS diffs. solving all is like boiling the ocean ... can we pick a subspace for a charter?

JosD

JosD: we cope wiht changes on different levels ... clinical practice guidelines change slowly... additive behavior, taking snapshots

<kendall> JacekK: do we want to do any kind of graph update thing?

<patH> OK, Yoshio, I understand. BUt SPARQL is aimed as RDF-specific QL, right? And RDF itself has no inconsistency.

<ericP> TimBl: lots of different apps and different diff alogorithms, but the diff format was always the same

<kendall> we want something that seems a lot more primitive (?) than diffing and patching graphs and sending those around. But -shrug-

<Yoshio> patH: so my guess is the current issue is something to be treated elswhere than SPARQL deals...

<patH> Yes, i wuld hope so. We ahve anough trouble with ===.

<AndyS> It's an informing open discussion

<patH> OK, didnt mean to rain on parade.

<ericP> KendallC: want a method in the protocol to send triples to a graph. also want delete (results of a query)

<patH> While being open, though, I suggest worrrying too much about consistency isnt useful, eg dont thik we need paraconsistency to handle it in practice.

<ericP> timBl: sounds like what we are doing

<ericP> JoseD: can you delete rules?

<patH> Can anyone stop you deleting rules?

<patH> timBl, I'd like to know more about what you guys are doing. POint?

<ericP> i think it was quesiton of implementation

<ericP> JacekK: do we want direct change of the graph? or submit somehting to a processor that may or not result in a change.

<ericP> ?

<kendall> some people wld argue that much POST usage is mis-usage. :>

<ericP> ... more like POST.

<ericP> Jacek: when people use POST, they defer to the service.

<ericP> ... maybe SPARQL should stay at that level

<ericP> ... leave it up to higher level protocols

<patH> kendall, imagine trying to track changes in a dynamic graph resource, eg produced from a newsfeed.

<AndyS> Hmm - update/diff language vs/as well as update services

<kendall> hmm, i'll chew on that, path

<ericP> ack eric`

<Zakim> kendall, you wanted to ask what a separate way of representing a graph diff buys over using sparql queries.

<ericP> PatH, feel free to dial

<ericP> TimBl: updtae is like a query except UPDATE, DELETE or BECOMES instead ofn CONSTRUCT

<AndyS> +1 to update language appraoch

<ericP> KendallC: any truth maint?

<ericP> TimBl: no. need to get functional properties

<ericP> AndyS: seem to be in a rules world

<ericP> JacekK: we are mapping to HTTP GET and update mappings would probably get mapped to PUT, DELETE, POST

<Zakim> JacekK, you wanted to respond to "just doing a service that updates a graph" and "full deployment of PUT and DELETE" as opposed to availability

WSDL mapping input

Bijan showed two WSDL/RDF mappings and collected input on them. chair neglected to ask Bijan to share a copy for the record. Pros and cons of each were discussed, with no particular conclusion.