SV_MEETING_TITLE -- 17 Mar 2009

<LeeF> Scribenick: john-l

<iv_an_ru> LeeF, shouldn't we rename Feature:PathLength to Feature:PathDatatype? If so, shouldn't we assume that the datatype for patch is an XQuery sequence?

<AndyS> Why not something RDF?

<AndyS> This seems to get to a key point - the output form isn't just XML for the protocol.

<AndyS> The restriction to certain path lengths does not require the full new path data type thing.

<AndyS> A Q I have for Alex today is whther the use case is the important point or is it just an example of the more general mechanism.

<AndyS> (AlexPassant - advance notice on a Q I would like to ask today)

<ericP> AndyS, how went video?

<iv_an_ru> BTW will Skype work with that video?

<AndyS> EricP - didn't get a chance today - was late in.

<AndyS> No idea about Skype - it's an IP videoconf system. What does Skype provide? Can MIT do multiway?

<ericP> not even gonna speculate about multiway

<iv_an_ru> Skype is an IP-phone + IP-video, quite convenient I'd say.

<AndyS> But is it standard H.323?

<kjetil> I will be semi-present on IRC, may call in later

<scribe> Scribe: john-l

<LeeF> iv_an_ru, AlexPassant, will you be able to join us?

SSchenk1: I've done work on SPARQL federation, including recent work on the Billion Triple Challenge.
... Also see the recent introduction on the mailing list.

<iv_an_ru> Nice phone is dead, but Bristol is ok.

<LeeF> minutes from last week

LeeF: Note that the straw polls in the minutes are not binding in any way.

<ericP> +1

<ivan> +1

<LeeF> RESOLVED: accept http://www.w3.org/2009/sparql/meeting/2009-03-10

LeeF: Nothing from our liasons, correct?
... To review, we just want to get the basics of each feature out there, without too much discussion of syntax details in these meetings.
... Discussion should focus on triage.
... First up, Negation. Chime?

Negation

<chimezie> http://www.w3.org/2009/sparql/wiki/Feature:Negation

chimezie: This feature supports testing when a pattern does not match the active graph.
... We currently do this with OPTIONAL and a bound test.
... But we want to be able to test directly whether a pattern is not matched.

<ericP> +1 to intuitive

chimezie: It would be more intuitive as a first-class operator in the language.
... Examples of different syntax are in the Wiki.

<ericP> i implemented unsaid in algae2

chimezie: As to use cases, there are a lot of exclusion criteria in health care informatics queries.

<ericP> (had a different spelling, though, something like "notfound" iirc)

<Zakim> SteveH, you wanted to talk about !ASK

<iv_an_ru> UNSAID become a binary operator right?

<iv_an_ru> {A} UNSAID {B}

LeeF: Are there other implementations of Negation out there?

<Souri> Some simplifications on what as parameter for UNSAID: OPTIONAL not needed, UNION not needed, ...

<AndyS> iv_an_ru: It didn't work like that

ivan: Does anyone remember what was the main issue with this feature from the previous working group?

<chimezie> http://www.w3.org/2001/sw/DataAccess/issues#unsaid

<SteveH> IIRC it was not included because of negation as failure concerns

LeeF: There may have been an open world/closed world concern.

AndyS: We were discussing this before the algebra was introduced, when the issues surrounding failure were more complex.

<Zakim> LeeF, you wanted to note personal pros & cons

LeeF: Inevitably, when teaching SPARQL, someone asks for some form of negation.

<AndyS> Another use case: data validation

LeeF: Still, we want to keep the scope of our work small, if possible.

<LeeF> ericP, but (much?) easier than OPTIONAL+!bound

Orri: There are good social web use cases, such as asking about knowing or not knowing certain people.

<SteveH> ericP, that's a matter of opinion, I think

Orri: This has a good mapping to similar SQL concepts.

<ericP> SteveH, i think it's pretty defendable if you take the average joe on the street

<SteveH> ericP, the average joe SPARQL user?

<ericP> there is none

<Souri> One of us (Orri and Souri) should change our names!

Souri: I approve this feature. We should focus on keeping this simple, wherever possible.

LeeF: Time for a straw poll on negation!

<Souri> +1

<SteveH> +1 if a part of subSELECT, -1 otherwise

<kjetil> +0

<LukeWM> 0

<chimezie> +1

<ivan> +1

<AndyS> +1

<ericP> 0

<dnewman2> +1

<SimonS> +1

<iv_an_ru> 0 if a part of subSELECT, -1 otherwise

<ywang4> +1

<LeeF> Orri: +1

<LeeF> LeeF: 0

Property Paths

LeeF: Now it's Andy's turn to talk about Property Paths.

<AndyS> http://www.w3.org/2009/sparql/wiki/Feature:PropertyPaths#Implementation_Experience_in_ARQ

AndyS: A property path is a substitute for a property, and has a few additional operators.
... There are simple ones which are syntactic sugar, and more powerful cases.
... This does not introduce a new datatype.
... It provides a set of results.
... It indicates whether a path exists, not what that path is.

<LeeF> has a bit more info

<chimezie> +q about how much of support for transitivity can be said to be covered by entailment

<chimezie> +q

Orri: We allow paths in any expression location, but this is primarily a syntactic difference.

<kasei> Zakim aacc is me

<kasei> Zakim mute me

SteveH: Can you say more about the cardinality of the result set?

AndyS: ... describes how the variable binding works.

<kasei> thanks Lee

<iv_an_ru> I'll vote for PropertyPath syntax for a simple reason: it's easier to implement it once in addition to exixting Virtuoso's transitive subqueries than to explain to beginners how to write that subqueries.

chimezie: What do implementers think about the relationship between property paths and entailment?

AndyS: The driving use case is when you want to apply path walking to data when you don't have an inference mechanism.
... It can also provide direct answers for certain inference questions.

dnewman2: What do you think about an extension to this for ordering the results in a transitive sequence?

<iv_an_ru> For me, any same-as, inference etc are invisible minor details of path traversal. Say, same-as nodes should not even appear in the resulting path.

dnewman2: The use case I have in mind is doing traceability analysis.
... (A, R, B), (B, R, C), (C, R, D), and I'd like to get back A, B, C, D.

AndyS: A reasoner would help you out there.

dnewman2: But I won't get the results in path order.

LeeF: Use the mailing list!

Orri: I've answered this on the mailing list.

LeeF: This is not about matching the path itself, but rather providing a feature for traversing a path when querying (that is, indicating whether such a path exists).

<Zakim> AlexPassant, you wanted to discuss path and owl:transitivity + ordering

AlexPassant: How can we maintain ordering when using inference?

LeeF: Use the mailing list!

<ivan> -1 I feel the proper specification for this feature would be too much for this charter...

<SteveH> -1

LeeF: Time for a straw poll about property paths.

<dnewman2> +1

-0

<kjetil> +1

<AlexPassant> +1

<kasei> +1

<chimezie> 0

<LukeWM> +1

<SimonS> +1

<AndyS> +1

<iv_an_ru> +1

<ericP> -1

<Souri> +1 but in simple form only

<LeeF> Orri: +1

<ywang4> +1

<ericP> what about ±0 ?

<LeeF> LeeF: 0

<Souri> What I mean by "simple" is no ordering etc.

LeeF: Next up, path lengths.

<SteveH> URI?

<LeeF> http://www.w3.org/2009/sparql/wiki/Feature:PathLength

<iv_an_ru> Souri, I guess that ordering is a separate issue, '*' is The issue :)

AlexPassant: Want to be able to specify how many properties separate two resources.
... Use cases include finding all people who are a certain number of relationships away from others.

<AlexPassant> http://www-sop.inria.fr/edelweiss/software/corese/v2_4_1/manual/next.php

AlexPassant: Implementation links should be on the Wiki.

LeeF: Any other implementations?

Orri: These features could be subsumed by transitive subquery.

<iv_an_ru> s/???/Orri

<LeeF> The way I see it from the wiki page, this is about binding paths to the variables, followed by calculating the length of that matched path

<iv_an_ru> I don't like an extra datatype that can not be even serialized for debugging

<AlexPassant> fyi, syntax used in the related wiki page is the Corese one, but I don't have a strong opinion on which syntax must be used for that feature

Souri: There could be multiple paths between nodes, and the issue is complicated by inference, which adds triples.

<chimezie> We need to be careful about the fine line between incremental path-based traversal and more general (and more complex) graph-theoretic operators, such as path lenths, shortest paths, transitive closures, etc..

<SteveH> it introduces binding ?vars

<SteveH> in FILTERs

<ericP> i think it's expensive, but that it be well-defined over anything with a (virtual) graph representation

<AndyS> SteveH - where abouts?

<SteveH> AndyS, ah, no, I misread

LeeF: Time for a straw poll!

<SteveH> -1

<chimezie> -1

<ericP> -1 (sorry, just want a small and reallistic scope)

<ivan> -1

<LukeWM> -1

<Souri> -1

-0

<kasei> -1

<AndyS> -1 to introducing a new datatype

<AlexPassant> +1

<dnewman2> ericP: 0

<iv_an_ru> -1

<kjetil> 0 if propertypaths is done, +1 otherwise

<SimonS> 0

<LeeF> -1

<LeeF> Orri: 0 (very useful but may be difficult to get consensus)

<ywang4> 0

<ywang4> sorry the line was not clear enough..

Aggregates

<LeeF> http://www.w3.org/2009/sparql/wiki/Feature:AggregateFunctions

LeeF: Next up: aggregates.
... Take a whole bunch of bindings and group them together. This is common in SQL.
... Either one big group or subgroups.

<Souri> +1 :-) I had proposed COUNT in SPARQL 1

LeeF: This is a very common request when explaining SPARQL.
... Several implementations listed on the Wiki.

<scribe> ... Postponed by SPARQL 2008 due to lack of implementation experience.

SteveH: Answering aggregate questions is hard for a couple other reasons, such as dealing with OWL and *what* is being counted.

<ericP> emphatically, we are a graph language

LeeF: Do we collapse counts for owl:sameAs?

<iv_an_ru> IMHO, aggregates are unavoidable, the only question is how the end-point should describe user-defined aggregates in its capabilities ;)

<Souri> +q

Orri: Aggregates are a must-have.

<kasei> +q to ask about numeric types and agregates

Orri: We have a partial implementation that deals with owl:sameAs.

<chimezie> +q to ask if aggregate champions envision extending SELECT expressions only with aggregate functions or more general expressions

<iv_an_ru> There's need in handwritten group by in some cases, but not so often.

<Zakim> kasei, you wanted to ask about numeric types and agregates

<Souri> How about HAVING to go with GROUP BY?

kasei: How do you deal with datatype mismatch?

<Zakim> AndyS, you wanted to reply to Greg

Several implementators indicate that they skip non-numbers.

<Zakim> chimezie, you wanted to ask if aggregate champions envision extending SELECT expressions only with aggregate functions or more general expressions

<iv_an_ru> more general

<SteveH> max(xsd:decimal(?x)) is possible

LeeF: Aggregate expressions should go with more general scalar expressions.
... Any substantial concerns about aggregates?

<SteveH> it has a strong relation to subSELECTs in the SQL world

chimezie: We just need to walk carefully around the open world basis.

<SteveH> and things like CONCAT() coupld be complex in SPARQL

<kasei> +1

<chimezie> +1

<ericP> 0

<LukeWM> +1

<SteveH> +1

<AndyS> +1

LeeF: Straw poll time!

<ywang4> +1

<iv_an_ru> +1

<ivan> +1 with the mild worry about the owl related issues

<kjetil> +1

<dnewman2> +1

<SimonS> +1 think this is essential

<LeeF> +1

<Souri> +1

<AlexPassant> +1

<LeeF> Orri: +1

<iv_an_ru> I'd cheat and place one more +1

LeeF: Talk about UPDATE?

<iv_an_ru> +1 for update

<ywang4> +1

<ericP> what's wrong with yesterda?

<ericP> y

SteveH: We want this... tomorrow.

<ywang4> update is essential anyway

<SteveH> but, I do /not/ want UPDATE in SPARQL, in some other langauge (forgot to say that)

LeeF: A separate SPARQL update language is implemented in a number of implementations.

<AndyS> +1 to separate

LeeF: There exists a draft specification for this.

<SteveH> we have UPDATE feature, with a syntax that I wont defend

<AndyS> http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/

LeeF: This can exist in a separate recommendation.

ivan: Would this be a separate recommendation?

SteveH: I want to see it as a separate *language*.

<iv_an_ru> It may be enough to warn that some keywords are "reserved" from update language.

SteveH: We need to consider security and other issues which really indicate that it should be a separate language.

<chimezie> +q

<AndyS> (that was Andy - sorry)

<Zakim> SteveH, you wanted to answer

SteveH: If you only support query, then you should be said to support SPARQL.

<Souri> I'd prefer SPARUL to be a separate spec.

<ericP> motivated by andy's argument for sparql-compliance if you only do query

kjetil: I support separating out the two components.

<ericP> i'm not sure how the grammar will work

<iv_an_ru> ericP, read-only sparql endpoint will just report "unauthorised" to all update requests :)

<ericP> LeeF, i have to go. put me down for +1 on update

chimezie: Updates could go to the protocol level.
... The protocol has some hooks that could allow modification.

<SteveH> +1 to whoever just spoke, we do that

<ywang4> +1 again

<ywang4> and gotta to leave, thanks guys

<AndyS> EricP - could still have one grammar, two entry points (easier impl for me at least)l

<SimonS> I have to leave. My oppinion is:

<kasei> service descriptions might help sort out endpoints that support update if they end up as two different different components

<SimonS> -1 I think this important, but security is essential. That is quite involved, so better separate it.

<chimezie> i.e., the HTTP verbs cover some of the capabilities that are being proposed as part of the current update language

<LukeWM> +1

LeeF: Final straw poll!

<AndyS> Security matters a lot here IMHO

<SteveH> +1

<ivan> +1 as a separate doc and with a large amount of scare

<kasei> +1

<kjetil> +1 (but separate Rec, this group should do it)

<Souri> -1, if separated +1

<chimezie> -1 (in its current form)

<SteveH> +1 (IFF it's a seperate language) [correction]

<LeeF> Orri: +1 (security might be implementation-specific)

<AlexPassant> +1 to get an update mechanism, no strong opinion re. included in SPARQL or related doc

<dnewman2> +1

<LeeF> 0

<AndyS> +1 and pref seperate spec

<LeeF> Thanks very much to john-l for scribing!

- DRAFT -

SV_MEETING_TITLE

17 Mar 2009

Attendees

Contents

Negation

Property Paths

Aggregates

Summary of Action Items

Scribe.perl diagnostic output