See also: IRC log
<trackbot> Date: 04 May 2011
<davidwood> Scribe: Thomas Steiner
<sandro> mischat, yes, the MIT facility does that, but might not fit all the people who want to be local at MIT.
<mischat> well at least it is an option, i wonder how many people would be at the east coast event if there was a european place to sit as well ...
<sandro> Yeah, mischat, Guus was going to make a poll to find the answer to that question.
<davidwood> ScribeNick: tomayac
Proposal to accept the minutes
AI 34 overdue
<scribe> Done, whole heap of issues raised, see action
going thru issues today
some easy, some hard
proposed to close ACTION-34
next topic: ACTION-22
but cygri sent regrets
<cmatheus> zakim. ??P32 is cmatheus
will be clearified
sandro: ACTION-39 closed
unrecorded ACTION: look at respec text vs. wiki text
gavin: action was unrecorded
gavin, wlliam, pierre-antoine on the unrecorded action
next topic: ACTION-41
<sandro> ACTION: gavin to compare/contrast respec vs mediawiki for spec authoring [recorded in http://www.w3.org/2011/05/04-rdf-wg-minutes.html#action01]
<trackbot> Created ACTION-43 - Compare/contrast respec vs mediawiki for spec authoring [on Gavin Carothers - due 2011-05-11].
poll for face2face, on antoine
<sandro> ACTION: william to compare/contrast respec vs mediawiki for spec authoring [recorded in http://www.w3.org/2011/05/04-rdf-wg-minutes.html#action02]
<trackbot> Created ACTION-44 - Compare/contrast respec vs mediawiki for spec authoring [on William Waites - due 2011-05-11].
<AZ> can you hear me?
<mischat> i found out about the video conferencing facilities at southampton uni fwiw
<sandro> action piere-antoine: to compare/contrast respec vs mediawiki for spec authoring
<trackbot> Sorry, couldn't find user - piere-antoine
<AZ> it seems I have a problem with my mic
<sandro> action Pierre-Antoine: to compare/contrast respec vs mediawiki for spec authoring
<trackbot> Created ACTION-45 - Compare/contrast respec vs mediawiki for spec authoring [on Pierre-Antoine Champin - due 2011-05-11].
<AZ> I have a text to propose
<trackbot> ACTION-42 Propose text for resolution on archaic xsd:strings notes added
text in email. link anyone?
<AZ> "PROPOSED: Recommend that data publishers use plain literals instead of xs:string typed literals and tell systems to silently convert xs:string literals to plain literals without language tag."
<gavinc> "PROPOSED: Recommend that data publishers use plain literals instead of xs:string typed literals and tell systems to silently convert xs:string literals to plain literals without language tag."
<AZ> it's the same as in my email
same as in email
ACTION-42 herewith closed
next topic: sparql-turtle alignemnt
issues, agreements, disagreements
andy discussion lead
andy: agreement: on all issues
except for one
<ivan> Andy's email
eric wishes to add a feature into turtle to allow prefixing of names
eric: getting past encoding limitations in pnames
<mischat> go on ...
<ericP> _:Eve foaf:name "Eve\u0022 .
<ericP> _:Eve :says "Éric says \u0022Hi\u0022" .
eric: escaping not part of the grammar
eric: productions of local names to include escape productions
ivan: why this difference?
andy: at the moment as turtle is defined, commas disallowed in prefix names
andy: that would be a change to
... current form does not allow \u escapings
gavin: thinks that ntriples has local names
andy: label for a bnode has to be
decided on a per-output basis
... asks eric: are you happy w/ the outher proosals
andy: any other issues?
-- silence --
no other issues
andy: on what basis do we take the decision?
eric: on the prefix nodes issues: sorry it cant be done
<LeeF> I think it's a "nice feature to have", but I'm (of course) wary of changing SPARQL right now because of the impact on implementors
<SteveH> +1 to LeeF
<PatH> There is a dragon on the call breathing fire.
eric: no new prefix for each row
in the db
... just use the same prefix
<PatH> sounds like LeeF is right, this is neat feature but not really essential. I suggest not worth changing sparql for.
andy: need a decision mechanism
ivan: question is: what is the most, what is the least destructive answer?
ivan seems gone
lee: understands the use
... probably not a good thing to include during SPARQL last call
<MacTed> (AZ muted, and ivan went quiet ... ivan isn't in the names list ... I'm guessing AZ took ivan's line)
ivan is back
<LeeF> Also mildly disruptive with existing turtle and sparql implementations
ivan: not only last call, but also deployed sparql versions
<LeeF> Both things -- disruptive to SPARQL schedule, and somewhat disruptive to implementations
<PatH> Maybe should ask, if we DONT do this, how bad would that be?
eric: not convinced that it's true
<MacTed> 1.1 (or later) have been known to break (or at least, go beyond) 1.0 ...
<PatH> Everyone sees to agree this would be kind of neat, but... So what is the but... for NOT doing it.
<MacTed> BASIC 2.0 commands broke in BASIC 1.0 interpreters... :-)
andy: argument for not doing it: its not currently in turtle and in sparql. how much need is out there?
<PatH> OK, thanks.
andy: whats the cost. would it cause a new last call?
davidwood: we have a
... if we were to include it in turtle, we'd break the sparql turtle alignment
... do we want to break sparql-turtle alignment?
<PatH> OK, seems to me that sparql/turtle alignment is worth quite a lot of loss of neat-o features.
ivan: having a problem w/ sparql
turtle alignment would be a mistake
... sandro very diplomatic proposal:
... if sparql goes to last call => sparql can make it a pending feature
<AndyS> if programmatic constructed, then the system writer gets it right anyway
ivan: if feedback on last call very negative => can be taken out
<PatH> Ivan, you should be in the State Department.
<PatH> +1 Ivan
ivan: make it clear that its an issue in pimplementations, and see what the feedback is
davidwood: happy with it
lee: implementers are here.
... happy, with the sparql hat on
<PatH> sparqly pimplementors unite!
<ericP> <PN_CHARS_BASE> |= UCHAR
<LeeF> LeeF: I'm ok with it, because I'm ok with not being 100% conformant, but I wouldn't run off to make this change in my code
ivan: to be fair, other changes for turtle would require turtle parsers to go thru an update circle
<SteveH> I think this is less invasive than the \u escape ordering thing
<SteveH> but I'm not a parser guy
andy: required update is for
strings and iris
... believed not to affect many people
<ericP> _:Eve foaf:name "Eve\u0022 .
eric: in the sense of doesnt happen often enough?
andy: yep, in this sense
david: you think we make any progress on this, andy? or should we move on?
andy: think we should move on
<gavinc> as turtle implentor, I'm with Eric. Easy change to make.
ivan: can we agree on other issues to be solved?
andy: yes, i can draft a resolution
eric: one of the points in erics mail was: escaping should not be in the grammar, eric says: it should be in the grammar
andy: i took whatever was in the current doc
<AndyS> PROPOSED: http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0011.html Point 2-7 are agreed leaving \u processing (point 8)
objections to andy's proposal?
no objections. propsal accepted
<ivan> RESOLVED: http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0011.html Point 2-7 are agreed leaving \u processing
thanks for the productive discussion
revisiting of post-poned issues
let's try to resolve whatever is possible via phone
let's skip others
clean up easy ones
<davidwood> ISSUE-42: Revisit "Something should be done about aboutEachPrefix construct"
<trackbot> ISSUE-42 Revisit "Something should be done about aboutEachPrefix construct" notes added
looking at issue 42
<trackbot> ISSUE-42 -- Revisit "Something should be done about aboutEachPrefix construct" -- raised
davidwood: please check the issue and edit it if need be
davidwood: objections to closing ISSUE-42?
<gavinc> +0 (no idea what the issue was)
davidwood: it's in the charter to clean left-overs
davidwood: closing ISSUE-42
<trackbot> ISSUE-43 -- Revisit "Suggestion that Qnames should be allowed as values for attributes such as rdf:about" -- raised
<webr3> +1 to resolve/close
<gavinc> +1 to close
theere was agreement on email to close this ISSUE-43
davidwood: closing ISSUE-43
<trackbot> ISSUE-44 -- Revisit "The RDF XML syntax cannot represent all possible Property URI's" -- raised
<webr3> +1 to close, can't see any reason to continue soemthing that won't change
<SteveH> +1 to close
<AZ> +1 to close
davidwood: seems agreement to close it, as rdf/xml wont never ever change
<AndyS> +1 to close with no change
<gavinc> +1 close
davidwood: correction: minor changes to rdf/xml might happen. sorry
<trackbot> ISSUE-45 -- Revisit "The syntax needs a more convenient way to express the reification of a statement" -- raised
<webr3> +1 close as a duplicate (on issue-25)
davidwood: ISSUE-44 closed
davidwod: next ISSUE-45
<SteveH> +1, close a dup
<gavinc> +1 close as duplicate
davidwood: ISSUE-45 is duplicate of ISSUE-25 => close it
<AZ> +1 close as duplicate
davidwood: ISSUE-45 closed
<trackbot> ISSUE-46 -- Revisit "Should RDF have a mechanism for declaring two uri's to be equivalent?" -- raised
<webr3> -1 leave open for discussion later
<PatH> Sugfgest we keep this one open for now.
<gavinc> -0 leave open
davidwood: leave it open for next workshop
<SteveH> close, we have owl:sameAs
<zwu2> close, we have owl:sameAs
<cmatheus> +1 leave open
davidwood: enough DISagreement to leave this open
<mbrunati> 0 leave open
<trackbot> ISSUE-47 -- Revisit "RDF embedded in XHTML and other XML documents is hard to validate" -- raised
<webr3> +1/0 don't care
<SteveH> don't care
<ivan> +1 to close
<FabGandon> out of scope
<zwu2> +1 close
<AZ> +1 to close
<sandro> close, but with a better comment.
davidwood: no objections to close it
<mbrunati> +1 close
<pchampin> out of scope
<PatH> does i tmean the RDF is hard to validate or the XML is?
davidwood: ISSUE-47 clsoed
<cmatheus> +1 close
<PatH> +1 close out of scope
davidwood: validation is out of scope of this wg
<gavinc> +1 close with validation out of scope
<sandro> +1 "Close -- validation is out of scope for this WG"
<mischat> +1 to close
<PatH> listen to the worms...
<trackbot> ISSUE-48 -- Revisit "The design of the RDF Model collection classes exhibit various awkward features. Might these be augmented with a 'better' design?" -- raised
davidwood: danbri marked this one
as a duplicate
... proposal to close it as duplicate to ISSUE-24
<gavinc> +0 close as duplicate of Issue-24?
<SteveH> not a dup of 24
andy: not a duplicate of
... its about containers
ISSUE-48 is about collections
patH: couldnt follow, sorry
<SteveH> "The use of special property names (_1, _2, etc.) can really be quite awkward for expressing ordering. It means that it can be very difficult to add new members to a collection after the event"
path: seems to be a suggestion to
put linked lists into rdf. done by the prev. wg
... seems an archaic left-over
<mischat> SteveH: is speaking now
steveh: not true
davidwood: want to continue this discussion on the list?
steveharris: lists of things done the wrong way twice
<gavinc> Anyone have ideas on making better lists?
path: close it and throw it away
<webr3> +1 to path
<ericP> +1 to PatH's dicideratum
davidwood: proposal to close ISSUE-48 as overcome by events. objections?
<AndyS> Add them as a first class data object, not encode in triples. Its the encoding (and possible mis-encoding) that cause some of the pain.
<trackbot> ISSUE-49 -- Revisit "Should the subjects of RDF statements be allowed to be literals" -- raised
davidwood: ISSUE-48 closed
<SteveH> +1 to AndyS
<zwu2> would be nice to have it :)
ISSUE-49: literals as subjects cant be closed
<trackbot> ISSUE-49 Revisit "Should the subjects of RDF statements be allowed to be literals" notes added
<webr3> q: could I create an RDF serialization with literal subjects and defer to the rdf semantics?
<PatH> Andy: I agree, buit that goes way beyond issue-48.
davidwood: cant be considered closed
<PatH> Yes, the semantics is fine iwth lieteral subjects.
<PatH> with literal
andy: happy to postpone
<webr3> so it's in "rdf" but not in the official serializations
andy: rdf api allows literals as subjects
ivan: status of rdf api? first public working draft hopefully next week
<PatH> There was a chorus of disapproval for literal subjects at the initial workshop, mostly from developers who didnt want to alter lagacy code.
davidwood: for the moment we cant do anything about it
<webr3> it's now "rdf-interfaces" which contains it - rdf-api is a diff spec
<webr3> +1 to continue
<AndyS> +1 to PatH - legacy is now a real issue (and that's good)
tomayac: rdf api is now rdf interfaces
<mischat> literal as subjects doesn't seem very webbie to me, but anyways ...
<trackbot> ISSUE-50 -- Revisit "Request to allow b-nodes as property labels" -- raised
... out of charter
<PatH> Sorry to go back, but I just noticed something about issue-42 that might be slightly important. The POWDER mechanism uses rdf:bag, which me therefor have to be careful not to deprecate.
<webr3> rdf-interfaces again allows bnode predicates
davidwood: should we leave it open? or postpone?
<PatH> FWIW< again the semantics is OK with bnode property labels, but some of the entailments might raise eyebrows.
<webr3> are we goign to discuss further? if nto postpone
davidwood: ISSUE-50 postponed
<FabGandon> +1 postpone
<mischat> postpone please ....
<pchampin> +1 postpone
<SteveH> +1 to postpone
<Souri> +1 to postpone
<zwu2> +1 to postpone
<gavinc> +1 postpone
<webr3> PatH, ty for confirmation, I don't mind raised eyebrows :)
<mbrunati> +1 to postpone
<ericP> +1 to cowering in fear
<gavinc> RDF Interfaces :\
<mischat> as in rdf-interfaces has bnode properties and literal subjects
ivan: this issue is different than the previous one
<webr3> RDF interface implementations will support it.. rdf semantics do to, serializations don't - doesn't matter, this is behind the "public interface"
ivan: you might have bnodes as predicates
<webr3> +1 to what ivan is saying
<PatH> +1 to Ivan
<zwu2> +1 to Ivan
ivan: there was a huge discussion in the rdf applications wg
<PatH> This is a general issue, BTW, it also bears on literal subjects.
ivan: bnodes as predicates is good in APIs, because if not, implementations might have problems
<webr3> the needs for serializing RDF are different to the needs for workign with RDF - we need to accept that generally
<AndyS> Is there a serialization API?
ivan: if it's for me, we can close this issue
<PatH> It will damage the DL/Full boundary in OWL, for sure.
ivan: dont want to go down that route
<webr3> AndyS, roughly the RDF API (end user focussed) will be more restricted to the convensional (matching serializations)
david: if we postpone it goes to a later wg
<AndyS> webr3, pointer?
<webr3> AndyS, http://www.w3.org/2010/02/rdfa/sources/rdf-api/Overview.html
davidwood: we're postponing already, leaving leftovers, just like the previous wg did
<webr3> can we address it properly, to say semantics allows X serializations are advised to allow Y (Reasons) then CLOSE ?
davidwood: if we close, we need to say why
<AndyS> webr3, pointer to serilization? I only see about parser using serialize
davidwood: saying it is out of scope is way different than closing
ivan: every wg may reopen closed issues
<webr3> AndyS, you've confused me - you're looking for?
<PatH> Ivan, you read my mind...
<PatH> Separate the issues!
zwu: how many people would truly object to have literals as subjects and bnodes as predicates
<SteveH> Garlik would object to both / either
<AndyS> A pointer to "roughly the RDF API (end user focussed) will be more restricted to the convensional (matching serializations)"
<sandro> STRAWPOLL: Who would object to Liuteral Subjects
<LeeF> Quite possibly.
<PatH> Im happy with literal subjects.
zwu: straw poll, please
<webr3> v happy with +1
<davidwood> I would possibly object to literal subjects - I have before
<sandro> STRAWPOLL: Allow Literal Subjects
<LeeF> ivan + me == 1 full objection! :-)
<AndyS> Need to think more but quite possibility -1 (because the deployed system impact)
zwu asked also for a straw poll on bnodes as predicates
<sandro> STRAWPOLL; Allow bnodes as predicates
<PatH> This is assuming that we have bnodes at all, of course.
zwu: one for the reasons are: if we are implementing an inference engine, it's way easier to allow, than disallow them
<gavinc> +1 to PatH
<MacTed> bnodes are useful in-process. they are nothing but trouble once you leave process.
<davidwood> We have bnodes, Pat :)
ivan: -1 because it would invalidate many things in owl
<PatH> It depends what kind of inference engine uyou are tryuing to implement.
<PatH> OWL-DL would prohibit it rigorously, so it would add a layer of checking to thier engines.
<FabGandon> +1 to AndyS
<mischat> +1 AndyS
<PatH> +1 to andy
davidwood: back to ISSUE-50
<gavinc> +0.5 to AndyS ... sometimes it leaks
davidwood: open => discuss, close => out of scope, postponed: let others deal with it
<webr3> if it's not an RDF WG level problem, who would it be a problem for?
<AndyS> gavinc, where??? and I'll stop that!!!!!!
<mischat> it is not webby to serialise statements suchs as ` "42" _:bnode1 _bnode2 . `
<webr3> +1 leave raised
davidwood: significant disagreement
<zwu2> +1 postpone it
ivan: either close or postpone
<LeeF> suggest close
<cmatheus> +1 leave raised
<PatH> Its not in our charter, its a huge can of worms, it owuld screw up OWL (and probably RIF) relatkionships. Lets walk away from it.
<pchampin> +1 postpone
<FabGandon> out of scope
<Souri> +1 to postpone it
<mbrunati> sorry guys i have to leave
<PatH> SO, leave it open and ignore it.
davidwood: reads what people say on irc
<webr3> (I'm saying to leave open/raised until there's good text to close it with or to clarify around the issue)
<LeeF> I don't think postponing is good. What's the point? If people find this useful and implement it, then we can standardize it in the future. But what's the point in continuing to say "meh"?
<SteveH> just close it, a future group can open a new issue if it becomes desirable
davidwood: enough agreement to postpone
<LeeF> +1 SteveH
davidwood: correction: not enough agreement
<ivan> +1 SteveH
<LeeF> I'm ok with opening it and then closing it, as well.
<LeeF> -1 to postponing it
<sandro> STRAWPOLL: postpone issue 50
<PatH> is an open issue like an open sore?
<LeeF> PatH, very very much so
davidwood: makes a chair decision to leave it raised. talk about it later
davidwood: pat raised a question on issue 42
path: rdf bag not much use
... proposed to deprecate rdf bag
davidwood: thinks we still could deprecate
<pchampin> I thought we already excluded the deprecation of rdf:Bag as it was widely used in RSS
<pchampin> (vague memory of the F2F)
davidwood: out of time for this call
<mischat> i recall that pchampin too
<SteveH> pchampin, yes
<PatH> pcahmpin, good point. thnx.
davidwood: remaining issues =>
... call adjourned
<mischat> would be nice to have the next f2f sorted
<PatH> ivan, to handle that issue we discussed.
<mischat> bye all
<AndyS> webr3 - I see nothing about serialization
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/probably a good thing to include/probably not a good thing to include during SPARQL last call/ Succeeded: s/pat/davidwood/ Succeeded: s/pat/davidwood/ Succeeded: s/pat/davidwood/ Succeeded: s/poiints/points/ Succeeded: s/is good/is good in APIs/ Found Scribe: Thomas Steiner Found ScribeNick: tomayac WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: ACTION-42 AZ AlexHall Andy AndyS FabGandon Garlik IPcaller ISSUE-42 ISSUE-49 Ivan LeeF MacTed OlivierCorby OpenLink_Software P10 P17 P29 P30 P34 P7 PROPOSED PatH Russel Russell STRAWPOLL Scott ScribeNick Souri SteveH SteveH_ Tony aaaa aabb aacc aadd aaee aaff cmatheus danield david davidwod davidwood eric ericP gavin gavinc joined lee mbrunati mischat next pchampin rdf-wg sandro steveharris tomayac trackbot webr3 zwu zwu2 You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 04 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/04-rdf-wg-minutes.html People with action items: gavin william WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]