<trackbot> Date: 22 February 2012

<danbri> (regrets from me, sorry!)

<cgreer> area code 949

<sandro> bummer, danbri, but thanks for the nice perspective email.

<Guus> Nick: will you be able to scribe?

11: 05:14 *** NickH has been idle 772 minutes

I fear it falls to me...

PROPOSED: accept minutes of 15-Feb, http://www.w3.org/2011/rdf-wg/meeting/2012-02-15

RESOLUTION: accept minutes of 15-Feb, http://www.w3.org/2011/rdf-wg/meeting/2012-02-15

<scribe> scribenick: MacTed

open action item review, http://www.w3.org/2011/rdf-wg/track/actions/open

<gavinc> ericP sent an email claiming victory

action-147?

<trackbot> ACTION-147 -- Eric Prud'hommeaux to propose by next week text that replaces section 4.3 -- due 2012-02-22 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/147

<davidwood> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#sec-escapes

<davidwood> EricP: I need to slightly correct the proposal: the example of %-escaping has a \'d "-" in an IRI. I'll strike that when I no longer need to sit in judgement of my fellow man (jury duty).

<gavinc> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#sec-strings vs http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#sec-escapes

<AZ> Pat sent regrets yes

<gavinc> PatH, Regrets. I have to go give some talks at a local school.

RDF-ISSUE-83 (HTML-rel-meta): RDF/XML: Incorrect reference for use of HTML rel="meta" [RDF General]

issue-83?

<trackbot> ISSUE-83 -- RDF/XML: Incorrect reference for use of HTML rel="meta" -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/83

http://lists.w3.org/Archives/Public/public-rdf-wg/2012Feb/0092.html

ivan: issue should be retargeted against Primer

<AlexHall> eric sent regrets

Named Graphs semantics

<gavinc> err, ericP has jury duty

starting from Pat Hayes' message and subsequent thread, http://lists.w3.org/Archives/Public/public-rdf-wg/2012Feb/0094.html

<gavinc> + vs . according to PatH "Suppose we allow the terminal dot of a triple to be written as a plus sign, to mean that this triple is being interpreted as depending on its graph context, ie it is really a quad with the graph name as its contextual parameter. Call this a contextual triple and say that the graph is then a context. Contexts are involved in the truth of the triples they contain, so they are quad-graphs in disguise. Then two graphs can be merged just when (

<gavinc> a) neither is a context (Ie they are normal RDF graphs) or (b) they are the same context (ie have the same graph label.)"

scribe: group effort to summarize Pat's proposal and confirm understanding thereof ...
... consensus seems to be that typical current usage of "." is what Pat has proposed for "+" ...
... goal seems to be getting a hint of the cost of merging differently contextualized graphs ...

guus proposes straw poll: who thinks it would be acceptable to add syntax for this, at this time?

sandro: syntax addition is needed, perhaps not the current proposal

AndyS: if community perceives need for change, they'll pick up on the syntax. doesn't seem that syntax change will drive change well.

<zwu2> +1 to AndyS

Guus: consensus is it's worth consideration.

<gavinc> +q

sandro: number of things that are truly immutable is so small as to be uninteresting
... need to know the context for virtually everything, it seems

<davidwood> Real world usage will continue to mix the '+' and '.' cases, so we need to be careful in defining the default case. I actually *prefer* to change the default case to being contextual.

gavinc: distinction is needed between "statements which are near universally safe to merge" and "statements which are likely to cause trouble if merged"

<zwu2> +1 to davidwood, I prefer to contexualize the default case

AndyS: Pat seems to be saying, "in the current theory, you can always merge statements." but does that respect common practice?
... the graph that holds it seems to be an important aspect of a triple

davidwood: Real world usage will continue to mix the '+' and '.' cases, so we need to be careful in defining the default case.
... I think I actually *prefer* to change the default case to being contextual.

sandro: the person making the statement often doesn't think it's contextual, but changed perspective can change that perception...

<davidwood> +1 to Sandro

<zwu2> +1

sandro: big change to RDF theory, but probably not big change to RDF practice ...

<AlexHall> +1 to the difference between theory and practice. people are already treating it as contextual.

<AndyS> It's entailment between graphs that relies on the universal context.

straw poll: "extant RDF should generally be considered to be contextual."

<AlexHall> even when the context is just "the current state of my SPARQL store"

<AndyS> ... could phase as "gather some graphs together, then do current RDF stuff"

<Guus> +1

<davidwood> +1

+1

<AndyS> +1

<zwu2> +1

<AlexHall> +1

<AndyS> caveat the "contextual" in a maybe-weak, non technical sense, maybe "scoped"

<gavinc> +1

<swh> +1 to AndyS

<ivan> +1

<swh> I think the question is way to vague / broad

<AZ> +1 but I think everything is contextual, HTML pages too

<davidwood> Yes, AndyS has a good point

scribe: consensus is "yes"

<gavinc> In other words at least from my head "Merging RDF graphs while easier then merging SQL statements, is still hard"

ivan: would like to understand where this leads us. 2 lines of discussion about named graphs, but where do they meet?

<AlexHall> merging graphs is easy. deciding whether it's ok to merge them is hard :-)

<gavinc> AlexHall, yes that +1

<zwu2> we can leave the decision when to merge graphs to end users :)

ivan: quad discussion around Pat's proposal, very interesting, came from Pat's action regarding time

<gavinc> zwu2, current semantics say it's always easy and safe

ivan: also typing discussion, from sandro et al

sandro: typing consideration was one of several proposed solutions

<zwu2> gavinc, I thought current semantics apply to graphs (of triples), not quads

sandro: has been concentrating on N3-style solution and [other]; Pat seems to be proposing a 6th solution

Guus: these discussions are different, but don't seem incompatible
... typing the graph container is something that couldn't (and shouldn't) show up in semantics doc
... one mechanism *may* be sufficient for use community

ivan: partially disagreeing with Sandro's "6th solution" characterization of Pat's message. concerned about new mechanism coming into picture several months into work...

sandro: named graphs has been a "lump in the carpet" since the early 90s. time dependence is also a big issue, which has now been raised with ties to named graphs.

ivan: where is line between scope of this WG and "future efforts"?

<Zakim> davidwood, you wanted to play Devil's advocate

sandro: may be time to review "other work" in Charter

davidwood: 2 chartered items that relate: named graphs and fixing semantics
... we seem to have made progress with these discussions. I'm inclined to let it continue a couple weeks longer.

Guus: further discussion requires Pat's presence...

sandro: maybe consensus feedback to Pat, "what's important about context?" may be helpful for progress

davidwood: objections have been made to "context" as an overused word...
... concern is that leaving separation of contextual/time-varying from non-contextual/time-invariant to publisher, is likely to be wrong

sandro: agreement... best practice may be to provide a "period of applicability" for a given data set, e.g., dc:temporal metadata

ivan: we may want to put aside the whole issue of time, for the time being...
... in practice, in practical usage, if I have a way to properly describe "named graphs," I can describe a bunch of triples and have a vocab to describe the time-related things... that may be enough, even if not terribly precise
... understood action on Pat to be "come up with vocabulary that would be enough for gathering sufficient time info for practical purposes"

sandro: practical question is whether we can satisfy multi-graph uses without addressing time question

ivan: ... without having a time ontology
... so first pursue use cases that don't require time dependence solution

<AndyS> Hmm - create islands where current pure semantics are true. Multiverse!

(...scribe joins discussion and fails to summarize...)

AndyS: perhaps we can do both: frame RDF semantics so there are "islands" of graphs where current "pure" semantics are true, free merging should work; then merging "islands" requires contextual info about those islands

<AlexHall> sounds like a research project to me :-)

sandro: "islands" seem to be larger graphs, which are collections of subgraphs

<AZ> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal

AZ: makes me think of the propsal about semantics of data sets
... (summarizes proposal, draws connections between it and "islands" terminology)

AndyS: asks for data set semantics to be mapped to a current use case

<sandro> +1 Andy: AZ, please illustrate your proposal by showing how to address (some of) the use cases with it.

AndyS:

AZ: these semantics do not directly address all use cases, but at least gives framework by which to do so...

action on AZ to illustrate how http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal maps to current use cases

<trackbot> Sorry, couldn't find user - on

<AlexHall> leave out the 'on'

action on zimmerma to illustrate how http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal maps to current use cases

<trackbot> Sorry, couldn't find user - on

<AndyS> ACTION: AndyS to Write email about the "islands" idea [recorded in http://www.w3.org/2012/02/22-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-148 - Write email about the "islands" idea [on Andy Seaborne - due 2012-02-29].

<AZ> azimmerm

action zimmerma to illustrate how http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal maps to current use cases

<trackbot> Sorry, couldn't find user - zimmerma

action azimmerm to illustrate how http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal maps to current use cases

<trackbot> Created ACTION-149 - Illustrate how http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal maps to current use cases [on Antoine Zimmermann - due 2012-02-29].

<gavinc> Azimmerm

Guus: seems we've made full progress there... ericP, can discuss action-147?

ericP: summarizes/restates content of email to list... linked from http://www.w3.org/2011/rdf-wg/track/actions/147
... change to be made, further discussion for next week ...

<gavinc> http://www.w3.org/2009/CommonScribe/manual.html

<gavinc> http://www.w3.org/2009/CommonScribe/panel/

<gavinc> Oooh, better URL https://www.w3.org/2009/CommonScribe/panel/?group=rdf-wg&go=Use+This+Group

https://www.w3.org/2011/rdf-wg/wiki/index.php?title=Chatlog_2012-02-22&redirect=no

<gavinc> yep, then the "Preview Nicely formated version"

http://www.w3.org/2011/rdf-wg/meeting/2012-02-22

<gavinc> and fix

<davidwood> Scribe page on wiki is now better: http://www.w3.org/2011/rdf-wg/wiki/Scribes

<gavinc> trackbot, end meeting

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/useful/acceptable/
Succeeded: s/save/safe/
Succeeded: s/tsunami merges all graphs/.../
Succeeded: s/form/from/
Found ScribeNick: MacTed
Inferring Scribes: MacTed
Default Present: Guus, Sandro, gavinc, Arnaud, +1.949.567.aaaa, +1.707.318.aabb, AndyS, MacTed, cgreer, David_Wood, FabGandon, swh, AlexHall, AZ, Ivan, zwu2, EricP
Present: Guus Sandro gavinc Arnaud +1.949.567.aaaa +1.707.318.aabb AndyS MacTed cgreer David_Wood FabGandon swh AlexHall AZ Ivan zwu2 EricP

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 22 Feb 2012
Guessing minutes URL: http://www.w3.org/2012/02/22-rdf-wg-minutes.html
People with action items: andys