RDF Working Group Teleconference -- 25 Apr 2012

<sandro> trackbot, start meeting

<trackbot> Date: 25 April 2012

<danbri> (regrets, i'm preparing to give a webinar shortly)

<Arnaud> sending 40+ messages between 4am and 8am my time isn't fair!..

<scribe> scribe: alexhall

<scribe> scribenick: alexhall

Admin

PROPOSED: to accept the minutes of April 18 telecon

RESOLUTION: to accept the minutes of April 18 telecon

guus: Action item review
... any progress on open action items?

<scribe> ... no progress, move to next week

Work priorities

guus: Our discussion on NG puts us at risk for the timetable in the charter
... it's a difficult issue but we have to face that fact, worth a discussion of priorities
... anything we can easily do quickly while keeping named graphs open?
... open floor for 5-10 minute discussion on this

eric: what is our todo list? (i guess it's in the charter, should look at that)

sandro: should be in the open issues list, might be more accurate

david: we do have an email thread started by Sandro this morning for graph strawpoll

guus: will get to that later, for now concentrate on issues outside of NGs
... right now have 29 open issues, should at least make sure we do the other ones that aren't graphs
... do we revive the RDF-JSON work?

eric: had the impression we were waiting to see how JSON-LD shaped up to see if we need to do anything other than adopt it

ted: LD is about making JSON linked, not making an RDF serialization in JSON

<pchampin> I don't agree either :)

[disagreement from guus, david]

<AndyS> +1 to MacTed. That is my understanding of the primary use case.

guus: can serialize any graph into JSON-LD

<AndyS> Sorry.

can you scribe yourself, andy?

<AndyS> RDFa can encode any graph but UC is RDF in HTML doc.

ivan: JSON-LD has gotten lots of traction in several places, this is a good thing

guus: will it be ready to do anything with it by this summer?

ivan: no, i don't think so

guus: ok, doesn't need to be a work priority for us

ivan: don't know whether we got XMLLiterals completely closed

<AndyS> so even though JSON-LD can encode a graph, is it the right solution for RDF exchange? outside of adding semantics to JSON( which is a good thing to do).

ivan: also think there was another issue coming in about HTML5 literals, might need to decide on that

cygri: based on information from poll, think there's enough information to make a proposal acceptable to wg
... aside from graph stuff, think ??? and HTML5 literals are the major open issues remaining
... wrt HTML5 literals, is that even an issue for this wg to consider?

ivan: don't see any other wg that can pick it up

<cygri> ISSUE-63?

<trackbot> ISSUE-63 -- Introduce an HTML5 datatype -- open

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

guus: ivan, can you do this since you raised an issue for it?

<AndyS> Issue-63 needed for LDP-WG.

guus: one other work item is to put out an update primer, that's on my plate
... don't think i'll be able to do anything on that until june

<gavinc> btw, ISSUE-63 is related to ISSUE-81

<gavinc> ISSUE-81?

<trackbot> ISSUE-81 -- How to represent HTML formated text in an RDF Literals -- raised

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

ivan: one thing that came up early was discussion to change title of RDF Semantics document, reorganize to make the rules normative and deemphasize the model-theoretic semantics
... think it's a good thing to do but huge amount of editorial work

cygri: is there an editors draft of RDF Semantics yet?

[no]

cygri: given that there are larger changes to the doc, would feel better if there were an editors draft by now.

guus: suggest we should put it on the agenda for next week
... any more priorities?

david: should ping peter and pat via email before next week

Turtle LC

guus: thought we agreed to a different schedule last week than what's on the agenda

gavin: yes, we agreed to have a draft ready by next week?

<AndyS> I emailed Eric and Gavin re ":" SPARQL change in local part of prefix names

guus: is that still a realistic goal?

gavin: yes

<gavinc> AndyS, yep, and updated the Turtle grammar to contain the same thing

guus: will put it on the agenda for next week

<ivan> +1 to Richard

cygri: there has been significant editorial work done in RDF Concepts since last published working draft
... since there are small number of open issues, think we should do another public working draft soon to get feedback

guus: do you plan to incorporate the XMLLiteral and HTML5 literal into the draft

cygri: i think there are enough changes in there to publish without XML/HTML5 literals

guus: leave the decision to you. i'm happy to come up with proposed working draft and do an internal review. turn-around time is ~3 weeks

ivan: would be good to have it done before SemTech

cygri: that seems doable and something good to aim for

<davidwood> Pat and Peter pinged re RDF Semantics editors draft.

<ivan> (SemTech starts on the 4th of June, FYI)

guus: do you want to commit to a date to put it on the agenda, or wait to see how it goes? target may 9?

<davidwood> I don't know how much effort I can put into RDF Concepts between now and 9 May, but can try.

cygri: would prefer to review XMLLiterals first before committing

guus: think it's worth taking a week longer to include XMLLiteral changes. think we came pretty close to consensus and it was just a matter of phrasing.

cygri: will put together a proposal for XMLLiterals in the next week, let's put it on the agenda for next week.

guus: good, 3 non-graph items on agenda for next week (Turtle LC, RDF Semantics draft, XMLLiteral)

Named Graphs

guus: suggestion is to start with sandro's strawpoll
... sandro, would you mind explaining this?

<sandro> 1. The default graph is asserted

<sandro> "{<a> <c>}" entails turtle("<a> <c>")

sandro: taking them in order, tried to go from simplest to most complicated
... consensus seemed to be that this is OK, though antoine pointed out that entailment might not be the right word.

<sandro> +1

<Guus_> +1

<ivan> +1

<cygri> +1

<yvesr> +1

<davidwood> +1

<Souri> +1

<AZ> +1

<FabGandon1> +1

<AZ> (although the terminology should be fixed)

<sandro> (agreed)

<sandro> 2. Named graphs are not asserted

<sandro> " {<a> <c>}" does not entail turtle("<a> <c>")

<ivan> +1

<AZ> +1

<cygri> +1

<davidwood> +1

<sandro> +1

<tbaker> +1

<Souri> +1

<Guus_> +1

sandro: think most people agreed that named graphs are not asserted, but there were a couple of disagreements

<AndyS> +1

<gavinc> +0

sandro: could those people speak up?

<yvesr> +0

<MacTed> I'm not current on this thread ... and not sure I understand the proposition.

gavin, can you please scribe your comment (didn't quite follow)?

sandro: the point here is that there needs to be a way to talk about some triples without asserting them as true

<gavinc> gavinc: Not clear to me what the diffrence between " {<a> <c>}" and GET "<a> <c>" is

sandro: who is saying the second one? in what language?

david: can you even say that? don't you just say "Get "?

gavin: as a data publisher, what is the difference between publishing a single trig doc vs. publishing lots of turtle docs

sandro: the trig doc doesn't assert the contents of the graphs, publishing as turtle docs does

<Zakim> davidwood, you wanted to ask whether they shouldn't just be two difference publication styles.

gavin: don't really understand why that is the case

<sandro> gavin: It's just not clear to me why putting all my turtle documents in one big trig document would change the meaning.

david: think this is a matter of style. it's a difference between quoting the contents of the graphs vs publishing them individually
... if i'm a publisher, the contents of both of those docs should be the same

<cygri> publishing something doesn't assert it.

sandro: not sure about the semantics of publishing on the web here. don't necessarily see publishing on the web as being equivalent to asserting

<sandro> sandro: I think it may be possible to publish RDF on the Web without asserting it. I'm not sure about that.

<gavinc> cygri, sure but the statement was " {<a> <c>}" does not entail turtle("<a> <c>")

<ericP> ivan is saying " a :ResolvableRDFResouce ." ?

ivan: convention is that graph iri's are just labels, but maybe there is an extension where we can say that the labeled graphs are the same as what is published on those IRIs

<ivan> eric, yes, although we had about 50 different names for that class already:-)

<sandro> 3. Named graphs are opaque

<sandro> " {<a> <c>}" does not entail " {<a> _:x}"

<ivan> +1

<AZ> -1

<cygri> -1, i think

<AndyS> -1 -- it should entail (within the graph). A graph is a graph everywhere.

<yvesr> -1, i think

<davidwood> +0.5 (I think)

<ericP> +1

sandro: the reason i think this is the right thing to do is, you want to keep things from changing out from under you all the time

<AndyS> (err - SPARQL entailment would have that entailment)

sandro: the graph is not the same as its entailments
... this is another way of saying that entailment has to be explicit.

<FabGandon1> -1, because I don't see why.

<ericP> i think we need to support the graph structure upon which SPARQL (and most of the world) relies

cygri: two reasons i disagree. first, we are defining a semantics, so we shouldn't say we do something because this is how sparql works. sparql is defined in terms of graphs, but we're concerned about the logical assertions within those graphs

<AZ> SPARQL with entailment regime really gives you the implicit statements

<sandro> cygri: Entailment goes nicely with the partial graph semantics.

cygri: second, i like the partial semantics approach
... it works well with entailments

sandro: think this might be something we can't decide without more experience.

ivan: when i have named graphs, what is in the named graphs is quoted. i'm not talking about entailment when i'm quoting.
... the entailment in the example is true if i'm explicitly doing entailment, but not otherwise

pchampin: i agree with ivan

<cygri> +1 to that

pchampin: either we have to accept all kinds of inference in the curly brackets, or none

<sandro> +1 we acept all kinds of inference, or none, within curlies

<davidwood> +1 to no inferences or none

<AndyS> 0

<yvesr> +1

<pchampin> pchampin: either all inferences should be allowed inside the curly brackets, or none

<ericP> can we make a guess at a descriminating use case?

<ericP> i propose capturing that graph { :Fido a :Dog . :Dog rdfs:subClassOf :Mammal } has an RDFS entialment which includes { :Fido a :Mammal }

<Souri> +1 to no inference

<sandro> 4. Graph labels denote just like in RDF

<sandro> "{<u1> owl:sameAs <u2>} <u1> {<a> <c>}"

<sandro> owl-entails

<sandro> "<u2> {<a> <c>}"

<ivan> +1

<AZ> -1 as the default but have a mechanism to switch to this case when needed

sandro: point of this item is that you can use graph IRIs in RDF and have those IRIs talk about the actual graphs
... this is refuting the people who claim that the label doesn't denote the graph

<davidwood> -1 (I see no reason to *interpret* the semantics of owl:sameAs within RDF, but that would be fine within OWL)

<ericP> +1

<cygri> ±0. the question needs to be made clearer

sandro: using owl:sameAs as an example, not suggesting we incorporate OWL into RDF

<sandro> { dc:creator "David Wood" } { <a> <c> }

sandro: you can only get at this feature by incorporating some higher semantics where different IRIs can mean the same thing

<AndyS> different issue because of label -> thing -> graph indirection

<sandro> sandro: are the terms "u" in the same general namespace, the I( .... )

<cygri> AndyS++

<davidwood> +0 (changed from previous after Sandro's explanation - I will need to think about it)

sandro: or, in this dc:creator example, is the thing created by David Wood the graph within the braces?

<Guus_> my phone just broke down, it seems the battery is corrupt :-(

<Guus_> david, can you chair the last 15 min?

<Guus_> it would be great if we get through all 7

<sandro> +1 AZ there is a use case against this (I just don't think it's worth it.)

<Guus_> thanks ivan

az: you can imagine that you have two IRIs used as a graph label for two different graphs, both denoting some resource that is the primary subject of those graphs

<ericP> <g1> { <bobama> a :American } , <g2> { <bobama> a :African }

<davidwood> gavinc: They use DNS as the basis to make their names, just like now

<sandro> no ericP not that.

az: you can't declare the names to be same without also declaring the graphs to be the same in this example

<ericP> why would i say <g1> = <g2> ?

<davidwood> gavinc: Oops, sorry. I thought that was you.

pchampin: afraid that this kind of inference would have lots of sparql implementers yelling at us

<AndyS> Two different datasets may have same for different things (e..g <URL> viewed at 15:00, <URL> viewed at 16:00). Good decision? globally no, but without agreement, it will happen.

pchampin: other than that this looks sensible, but afraid it might break things for implementers

<AZ> +1 pchampin

sandro: could this be handled by a sparql entailment regime?

<pchampin> SELECT * WHERE { { ?s ?p ?o } }

<AZ> The entailment regime do not do anything with the graph labels

pchampin: maybe, but only if the entailment regime also applies to graph labels

<sandro> +1 pchampin Good Question.

<AndyS> pchampin -- good point - enatilment only applies to BGP matching, not the named part

<AZ> (I reviewed SPARQL 1.1 Entailment Regimes)

entailment regime only applies to pattern matching within the context of a graph

<AZ> +1 cygri

<ivan> +1 to cygri

cygri: the entailment regimes is something to keep in mind. one thing entailing something else doesn't necessarily mean the entailed thing goes back into the data structure.

<cygri> { dc:creator "David Wood" } { <a> <c> }

cygri: your tools uses those entailments sometimes when you tell it to

<sandro> cygri: I think I can say YES, but my sparql store doesn't have to compute these

<sandro> cygri: In this example, the two 's are the same thing.

cygri: regarding the dc:creator, i think the question of what the 's denote is different from what relation that thing stands to the stuff in the graph.

guus: think we should speed this up to get to rest of questions on this telecon

<Souri> -1 for now b/c entailment today does not apply to graph labels -- the implications of this new extension is unclear to me

pchampin: question to richard, when you say it doesn't mean the triples won't be automatically in your triple-store, do you mean just that they won't be materialized or that they won't be returned as query results to that graph?

<sandro> STRAWPOLL: (4) In a trig document like { .... } ... { .... ... } the three "" terms mean the same thing.

<sandro> +1

<ivan> +1

<ericP> +1

<cygri> +1

<yvesr> +1

<pchampin> +1

<AndyS> +1 (I think) but the labelling has the indirection so it is a bit complicated

<AZ> What do you mean by "mean the same thing"?

<AndyS> (caveat PatH's work)

<davidwood> +1

<MacTed> so ... is scoped to Trig doc

<sandro> 5. Blank nodes labels have file scope

<ivan> -0.5

<cygri> ±1

<AndyS> MacTed - nice way of putting it. +1

<sandro> http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1#Blank_Nodes

<pchampin> @AndyS agreed, labelling adds an indirection

<Guus_> +1

<Guus_> makes pragmatic sense

<AZ> -0.3

<gavinc> +1

<davidwood> ±0

<Guus_> i thiunk that is what users would expect

sandro: use case here is that blank nodes need to be shared between graphs, e.g. when inference results from one graph are stored in another and the bnode labels need to denote the same thing in both places

<tbaker> 0

<AndyS> It is cheaper and easier at scale to have file scope. Problem exists even in RDF/XML in the bnodes id tracking.

ivan: but RDF graphs today cannot share blank nodes

i'm pretty sure RDF Semantics says nothing about bnode scope

<Guus_> I don't see the reason against

<ericP> +1

<gavinc> AlexHall, RDF semantics doesn't talk about more than one graph ;)

<AndyS> Surely RDF says exactly nothing one way or the other about anything across graphs

<MacTed> Bnodes (and their labels) are scoped to Gbox/Gsnap/Gtext.... yes?

ivan: don't see how we can do this without skolemizing bnodes

<MacTed> Bnodes are to be discouraged ... for MANY reasons. and this is one of those reasons.

sandro: disadvantage is simplicity and performance in terms of tracking bnode labels across a large document

<ericP> +1

<Guus_> +1

<ivan> 0

<sandro> 5. Blank nodes labels have file scope

<tbaker> 0

<sandro> +1

<cygri> ±1

<pchampin> 0

<Souri> -0.5

<davidwood> ±0

<MacTed> I *think* +1

<AndyS> +1 file scope

<gavinc> +1, and avoid blank nodes wherever possible ;)

<AZ> -0.3

<yvesr> +1

<sandro> 6. In trig, @union can be used in place of the default graph

ericP: right now nothing says triple store implemeners have to allow for bnode sharing, doing so might prevent optimizations

<AZ> +1

<pchampin> out of curiosity, did you try your test on majors SPARQL implementations?

<pchampin> (regarding bnodes?)

<AZ> (or another kind of syntactic indicator)

<ivan> -1 in this format, not INSTEAD OF, but ADDITIONALLY to the default graph

<yvesr> it does seem a bit at odds with 2.

sandro: this is basically a way of using trig to annotate sections of a graph

<sandro> purely syntactic sugar for repeating all the triples in all the named graphs.

<cygri> +0.5

<ericP> +.4

<Guus_> +0

<gavinc> +0.1

<AndyS> Better *may* be RDF triples to say this - may be lots of different things to say. Has some ordering problems/issues but a good idea.

<AndyS> +0.75

<Souri> +0.5

<davidwood> +0.5

<sandro> STRAWPOLL: In trig, @union is syntacitc sugar for inlcuding all the named graph contents in the default graph

<ivan> +1

<sandro> +0.75

<ericP> +0.5

<AndyS> ivan's proposal would make processing easier (e..g see it at end of parse run)

<tbaker> 0

<cygri> +0.5

<gavinc> (Syntax: Likely means that all declerations should come BEFORE the first graph statement)

<sandro> (we could change the word later,of course.)

<pchampin> +1

<MacTed> +0

<Guus_> +0 because not sure the cost of extra syntax is worth it

<Souri> +0.5

<FabGandon1> +0

<sandro> 7. Datasets only say which triples are known to be in a named graph,

<sandro> not which triples are *not* in that named graph.

<gavinc> +1

sandro: this last one is the partial vs. complete semantics

<davidwood> +1

<sandro> The merge of " {<a> <c>}" and " {<a> <d>}" is

<sandro> " {<a> <c>,<d>}".

<sandro> Also " {<a> <c>,<d>}" entails " {<a> <c>}".

sandro: this implies an entailment test.

<AZ> if graphs are opaque, then no it does not hold

<pchampin> definitely looks like subgraph entailment to me!

<AndyS> I prefer "*if* you wish to merge the two datasets then that is what the merge is"

ivan: this is inconsistent with our earlier statement that we have to either do all entailment or no entailment

<Souri> +1 (without the word "entailment")

<ivan> +1

sandro: it's entailment, but it's trig-entailment not rdf-entailment

<pchampin> I'm lost, then

<davidwood> So, what does "implies" *mean*?

eric: is this a referendum on whether we allow partial graphs, or on the semantics of those partial graphs?

<cygri> +0.8

<AndyS> +1 to first part, not sure what the consequence of second part is.

<pchampin> pchampin: rephrase my previous proposal: either trig-entailment should completely match rdf-entailment for labelled graphs, or it should do no rdf-entailmenet for labelled graphs at all

<sandro> strawpoll: Partial, Complete, or Both --- (or Huh???) :-)

<ericP> tbaker, you can write "partial, "complete" or "both" before you leave

<MacTed> partial must be default interpretation; want way to say "this graph is complete (or not)"; think we need both...

<sandro> The merge of " {<a> <c>}" and " {<a> <d>}" is

<sandro> " {<a> <c>,<d>}".

<Souri> +1 to partial

<Guus_> agree with partial being the default

<ericP> complete

<ivan> +1 to partial

<cygri> probably prefer partial

<davidwood> both

<Guus_> +1

<sandro> okay with either partial or complete, not sure about both at once

<davidwood> (at least partial)

sandro: the point is that complete semantics says this example is inconsistent, partial at least allows it

<pchampin> +0 (have to think over)

<AndyS> "huh???" and partial (may be app choice)

partial

<AZ> +1 have both with an indicator to say which

<ericP> complete for datasets, partial for trig syntax, which is complete at the end of the document

<Guus_> thx ivan, to take over

guus: adjourned

<ericP> <bobama1> { <bobama1> a :American } , <bobama2> { <bobama2> a :African }

- DRAFT -

RDF Working Group Teleconference

25 Apr 2012

Attendees

Contents

Admin

Work priorities

Turtle LC

Named Graphs

Summary of Action Items

Scribe.perl diagnostic output