RDF Working Group Teleconference -- 18 Jan 2012

<trackbot> Date: 18 January 2012

<zwu2> Scribe: zwu2

<LeeF> I have to leave after 60 minutes.

maybe we can finish in 40 minutes :)

<AndyS> Ok - I can scribe the last part

thanks Andy!

Admin

proposed: accept the minutes of the 11 Jan telecon http://www.w3.org/2011/rdf-wg/meeting/2012-01-11

Resolved: accept the minutes of the 11 Jan telecon http://www.w3.org/2011/rdf-wg/meeting/2012-01-11

Action item review

guus: RDF primer
... sandro, 3 actions for you
... action 100
... sandro has not reported back
... we will come back to it

action-117?

<trackbot> ACTION-117 -- Jeremy Carroll to check status of duration datatypes -- due 2011-11-16 -- OPEN

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

guus: suggest Jeremy to drop it
... if we don't expect much progress from it
... we can re-assign also

jeremy: the reason for this action is that duration datatypes were in a mess in RDF 1.0

I just did. sorry

guus: why don't we record an issue so we don't lose track of it.

cygri: you can re-assign it to me

jeremy: ok

cygri: set the time frame in a month

<cygri> this is related to ISSUE-66

action-118?

<trackbot> ACTION-118 -- Jeremy Carroll to summarize issues relating to XSD canonicalization -- due 2011-11-16 -- OPEN

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

jeremy: again, I don't have a realistic schedule at this moment

<cygri> ISSUE-13?

<trackbot> ISSUE-13 -- Review RDF XML Literals -- open

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

guus: we can generate an issue based on this action
... I will drop the action

action-129?

<trackbot> ACTION-129 -- Jeremy Carroll to review sandro's use cases -- due 2012-01-11 -- OPEN

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

jeremy: I haven't done much

<cygri> work in progress: http://www.w3.org/2011/rdf-wg/wiki/XML_Literals

cygri: have done some work in wiki

<JeremyCarroll> jeremy: I have looked at this and done what it is I will do, not much

cygri: not quite ready
... take me another week to complete the last bits

<gavinc> Charles

<gavinc> Charles Greer

RDFa LC

david: it is not clear what the meeting should focus on

<sandro> regrets for next three weeks due to WG F2F meetings

<gavinc> These are PRE last call comments

guus: david, can you summarize

david, it is action 128, did charles send his review?

scribe: since it is overdue, we should call it completed, I did send my comments to RDF WG
... http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0032.html
... my message focused on name of documents in RDFa
... how they related to graphs
... I did not have significant problem with RDFa core itself

guus: did you send it to RDFa?

david: yes. it's due on 16th
... ivan encouraged me to

guus: for the record, could you put a pointer in our archive
... send a message and put a link in the action item
... what do we do about Gavin's comments?

gavin: talking to Andy and Eric, wrote the problems we saw
... CURIE grammar
... most people intend to express with CURIE can be expressed using prefix name mechanisms
... talked to a few RDFa implementers (they don't use CURIE syntax)

<gavinc> don't use the EXACT CURIE syntax

guus: I suggested send Gavin's comments to RDFa WG

<davidwood> Closed and annotated action 128 with the link to my message to the RDFa WG: https://www.w3.org/2011/rdf-wg/track/actions/128

<MacTed> +1

guus: shall we record an action item?

ivan: RDFa WG schedule is the same time

action Gavin to send RDFa comments to RDFa WG

<trackbot> Created ACTION-131 - Send RDFa comments to RDFa WG [on Gavin Carothers - due 2012-01-25].

guus: did a review of the RDFa primer
... will send it to RDFa WG

ivan: this does not have to go through LC
... href is an HTML document

<JeremyCarroll> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0059.html concerning xsd canonicalization

<scribe> ACTION: guus to send Guus' comments to RDFa WG [recorded in http://www.w3.org/2012/01/18-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-132 - Send Guus' comments to RDFa WG [on Guus Schreiber - due 2012-01-25].

guus: I will do it today

RDF-ISSUE-82

guus: repeated graph iris

<gavinc> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Jan/0025.html sent top RDFa WG

issue-82?

<trackbot> ISSUE-82 -- How should repeated graph iri labels be handled in TriG -- raised

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

scribe: there appears to have strong consensus on option 2
... why don't we resolve it

gavin: I don't see any reason not to adopt it

<sandro> -1

gavin: happy to resolve it now

<LeeF> someone is beeping

<LeeF> :)

<davidwood> I would be happier to make some progress, even if it is an interim step that might be overcome if we decide not to use TriG.

<sandro> sandro: I don't think we should be settling things about TriG until we knownwhether Trig addresses our use cases.

guus: suggest Gavin to write down refined text
... we should move forward

<sandro> fine.

<sandro> -0

david: I don't see much harm in resolving this issue

<sandro> it means I don't like it, but I wont stand in the way

gavin: it took us a year to reach the status of turtle, we only have a year left

<sandro> which solution is he going with?

<scribe> ACTION: gavin to proposal final wording for issue-82 [recorded in http://www.w3.org/2012/01/18-rdf-wg-minutes.html#action02]

<trackbot> Created ACTION-133 - Propose final wording for issue-82 [on Gavin Carothers - due 2012-01-25].

<sandro> (yeah, I dont think 2 is right for some use cases, but well see when we get there.)

Named Graphs

guus: we have Sandro's use cases
... today more examples came it
... last week we had a meta strawpoll

<NickH> Test cases++

guus: how do we move forward from here
... shall we use concrete examples as a way to move forward

<NickH> painful beeping

sandro, there are beeps

sandro, are you suggesting focus on the use cases?

<cygri> the use case i mentioned is just one of the many from the wiki: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC#.28B_priority.29_Tracing_inference_results

<sandro> yes, a new page would be good

<sandro> i've swamped, but really want to do it.

cygri: may I ask why

<sandro> the old page is too long

cygri: what will be the difference between the new page and this old wiki

<AndyS> I'm confused -- Is it copying over existing UCs or creating new ones?

cygri: I have spent quite some effort shaping that wiki page up

<sandro> maybe "flagship" use cases, or something like that.

david: the goal of the new page is to focus on a small number of use cases, then we can talk about designs
... we have to have a handle on designs that match some use cases
... simplify to move forward

<sandro> (I only did three, so far)

cygri: from use cases, we get requirements
... there may be a requirement arises from multiple use cases

guus: I think it will be very useful to rephrase use cases as requirements

<sandro> +1 guus

david: richard I don't think we should get rid of that wiki use case page

<scribe> ACTION: guus to create a new section on use case page [recorded in http://www.w3.org/2012/01/18-rdf-wg-minutes.html#action03]

<sandro> maybe "Simplified Use Cases" or "Flagship Use Cases"

<trackbot> Created ACTION-134 - Create a new section on use case page [on Guus Schreiber - due 2012-01-25].

UNKNOWN_SPEAKER: requirement based on use cases

<AndyS> scribe: AndyS

<scribe> scribenick: AndyS

jeremy: about NG, how about writing text and discuss that -- maybe agreement quite quickly.
... focus on text rather the philosophical viewpoints.

sandro: Two ways to read trig leading to different impls.
... (hard to hear) ... Trig for labels, and trig for locations.

David: Jeremy - what was your idea to avoid that?

<sandro> sandro: I think me three strawman designs show that code would be different on the clients and the servers, so it's not just unimporant disagreement.

cygri: Minimal proposal - tagging, not exact meaning, not tied to HTTP. BNode scope to be done.
... sandro, path say that's not enough.
... sandro wants to tie to HTTP
... progress is limited. Seems that schedule forces us towards the minimal route.
... tie to HTTP is going to be hard to make work because assumes dereference part of the process. Doesn't work - RDF is disconnected from the protocol currently.
... this seems to be useful.

David: can we agree on that couple/decouple point? protocol, NG

<Zakim> sandro, you wanted to address JJC and to

sandro: sounds reasonable, Tie to HTTP not most important me, but do need client-server tie. (?? hard to hear a complete sentence)
... make HTTP part separate.

<sandro> sandro: It's fine to have the HTTP part be separate -- that's part of Linked Data, not RDF. What's important is to show how to solve the use cases in a way that actually works, interoperably.

ivan: partial response to cygri: a bit of a repeat ... there are two viewpoints, hard to find consensus, but timing forcing is not the proper way.
... acknowledge that and have two syntaxes for the two relationships.
... sometimes no relationship, sometimes HTTP version, sometimes "named graph"

Guus: chair hat off
... of Sandros 3 solutions (Trig/REST first) capture current practice and gives a mechanism, semantics.

<Guus> { eg:sandro eg:endorses <g1>. <g1> a rdf:StaticGraphContainer. } <g1> { ... the triples I'm endorsing ... }

(there is always a container)

scribe: and its noted in one of the graphs about how the URI is used.

<sandro> +1 this is a reasonable, workable solution.

(key is the rdf:type statement not that its a container)

Guus: reasonable area for consenus?

ivan: More precise of what I said ... the "syntax" is the rdf:type triple.

Guus: rdf:type optional
... put chair hat on

David: I like that we are using RDF as the mechanism. Wide variety of UCs covered.

<Zakim> davidwood, you wanted to comment on rdf:type usage once Guus regains the chair

<sandro> then you want my third design, JJC

Jeremy: I worry about optional features and interoperability. better is to go simple.
... interoperability depends on the rdf:type e.g. non-monotonic interpretation.

<MacTed> best practice = self-description, self-documentation, introspection... container holds things; things might also be containers; recurse.

<MacTed> common practice = anything not stated is unknown, and there are many things which might not be stated for many reasons -- and there can't be much enforcement of defaults

guus: what about defining good practice or would you want "MUST" text

jeremy: general point - significant cost in optionals and choices.

cygri: 2 questions ...

<Zakim> cygri, you wanted to ask about merging datasets

cygri: 1 - <g1> a graph name, two different assertions as to kind of reference. Conflict on merge.

<sandro> yes -- one drawback of this design is we can get conflicts in the RDF that should be handled carefully.

?? These conflicts already exist.

<ivan> the relationship made explicit is the third option of sandro

<ivan> <a> pred { ? } is the _only_ acceptable syntax then...

cygri: relationship view typing, not a triple.
... relationship indirect via typing, not a triple.

david: what about callimachus? We type URIs to provide a hint for rendering.

scribe thinks RDFS domain/range converts property uses to types.

cygri: may confuse who said what
... depending on the collection of types offered by us leads to likely clashes (e.g. mutable AND immutable)

<sandro> Formally, I suppose we're just using the fact that <x,y,z> can be expressed as <x,y'(z)>

<gavinc> hashing helps ;)

cygri: endorse container or graph?

<sandro> (in TriG/REST)

<gavinc> Endorsement CAN NOT use only a name.

<JeremyCarroll> +1 to Richard

cygri: mechanism leads easily to problems.

<sandro> gavinc, right, with endorsement you need to provide some other triples, but this still works.

david: we should design for interop if they follow the rules.

<JeremyCarroll> Richard: we have a responsibility to have a design that doesn;t make problems inevitable

cygri: as I understand it, conflict happens inside the rules.

<sandro> I agree the conflict is a challenge, but it doesnt make it unworkable.

guus: smallest extension, worth seeing if we can make it workable.

cygri: is dataset merge required?

<Guus> i will ack sandro after this

<davidwood> Interesting point, AndyS

AndyS: Is dataset merge different or saame as graph merge? Have check untrusted graph to merge usefully.

<sandro> sandro: I think this dataset merging problem is comparable to the graph merging problem and can probably be solved that same way.

<ivan> In OWL terms what we are saying is that the different types are disjoint, so if a merged graph has a 'double' typing then there is an inconsistency

<sandro> agreed, Ivan.

guus: some progress - suggest next week to look at the solutions proposed.

<sandro> (sadly, I'll be in other WG F2F meetings both of the next two weeks.)

<cygri> (me too next week)

<sandro> Im kind of use case driven here.

<sandro> Propose a use case, and Ill try to show what types we might need.

ivan: sandro away - is it possible to dig into the typing approach by writing proposed 4-ish types for the different way to use the mechanmis.

<sandro> I did that.

<sandro> I

<sandro> I'm going to TRY to write up the solutions better on the wiki

(no direct naming?)

ADJOURNED

<AZ> bye

- DRAFT -

RDF Working Group Teleconference

18 Jan 2012

Attendees

Contents

Admin

Action item review

RDFa LC

RDF-ISSUE-82

Named Graphs

Summary of Action Items

Scribe.perl diagnostic output