W3C

- DRAFT -

RDF Working Group Teleconference

16 Nov 2011

See also: IRC log

Attendees

Present
David, +30889aaaa, ericP, +1.707.861.aabb, AndyS, gavinc, yvesr, +1.707.318.aacc, Peter_Patel-Schneider, cgreer, Arnaud_LeHors
Regrets
Chair
SV_MEETING_CHAIR
Scribe
pfps

Contents


<trackbot> Date: 16 November 2011

<AndyS> trackbot, start meeting

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 16 November 2011

<Guus> strapoll: telecon on Thanksgiving?

<Guus> 0

<Scott_Bauer> 0

<sandro> 0

<davidwood> -1 (I can't attend)

<AndyS> 0 (can make TC, but if insuffcient numbers likely, maybe skip)

<gavinc> Telecon on day BEFORE thanksgiving (aka busiest travel day of the year?)

<gavinc> 0

scribenick pfps

<AndyS> scribenick: pfps

accept minutes

minutes accepted

guus: action items

<scribe> scribe: pfps

guus: all pending-review actions done
... open action review
... action 73 - fabien will handle in December
... action 82 continued
... action 94 continued
... action 99 continued
... action 100

sandro: in progress

guus: is action 99 critical?

sandro: no

guus: close it in favour of 100?

sandro: OK

guus: action 106

<sandro> close action-99

<trackbot> ACTION-99 Look at ISSUE-11 in relation to SPARQL 1.1 closed

gavin: waiting for action in Concepts

cygri: waiting for approval from Peter and Pat
... will push next week

guus: action 111 continued

<cygri> ACTION: cygri to add list of XSD types to Concepts (assuming no objection from PatH or pfps) until 2011-11-25 [recorded in http://www.w3.org/2011/11/16-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-122 - Add list of XSD types to Concepts (assuming no objection from PatH or pfps) until 2011-11-25 [on Richard Cyganiak - due 2011-11-23].

<cygri> ACTION-122?

<trackbot> ACTION-122 -- Richard Cyganiak to add list of XSD types to Concepts (assuming no objection from PatH or pfps) until 2011-11-25 -- due 2011-11-23 -- OPEN

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

guus: action 114 continued
... action 115

sandro: did get a reaction from Adobe

guus: so closed

sandro: reaction was rather negative to changes, but deprecation wasn't explicitly mentioned

action 116 continued

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

guus: action 116 continued
... action 117 - email seen, but still continue
... action 118 - email seen, but still continue

<AndyS> No progress on action 119, maybe this coming week, but not definite (did warn there might be a delay - it came to pass :-|)

guus: action 119 continue
... action 120 and 121 continue
... next week is 'Murican Turkey week
... skip a week, next telecon is 30 November

ISSUE-79

guus: issue 79

<ivan> ISSUE-79?

<trackbot> ISSUE-79 -- What is the value of a literal whose datatype IRI is not a datatype? -- raised

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

cygri: option 3 - no change to semantics - appears to be the winner, wording may be a bit tricky

guus: consensus may be achieved in the near future

ISSUE-37?

<trackbot> ISSUE-37 -- Handling of fragment identifiers in RDF embedded in other document formats -- pending review

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

ISSUE-69?

<trackbot> ISSUE-69 -- Handling of fragment identifiers in RDF Concepts -- pending review

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

<cygri> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-fragID

guus: proposal from minutes

<gavinc> ivan, this has a great deal to do with Turtle in HTML's meaning btw

<gavinc> and how it interacts with RDFa

cygri: I have new text for RDF Concepts - some review may be warranted, maybe even by TAG

guus: consensus on the proposal?

gavinc: text should address situations where RDF is embedded in other document types

cygri: there is a bit there already - please check it out

guus: this appears to be all about wording, not anything technical

yvesr: some of the wording may be a bit confusing for neophytes

<ivan> +1

<Arnaud> +1

<cygri> PROPOSAL: accept new RDF Concepts section 7

<cygri> PROPOSAL: resolve ISSUE-37 and ISSUE-69 by accepting new RDF Concepts section 7 as described in http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0056.html

<yvesr> +1, depending on rephrasing 'Since IRIs in RDF graphs can denote anything, this can be something external to the representation, or even external to the “shared information space” known as the Web.' to something simpler, like 'IRIs in RDF graphs can denote anything, so this is also true for fragment identifiers'

+1

<ivan> +1

<gavinc> +1

<zwu2> +1

RESOLUTION: resolve ISSUE-37 and ISSUE-69 by accepting new RDF Concepts section 7 as described in http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0056.html

<mischat> +1

<ivan> ISSUE-13?

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

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

guus: jeremy? (good timing)
... you wanted to make the point that things have changed, and there is a mess to be fixed

jeremy: I'm only the messenger

guus: change requires a new design

ivan: there are some emails on the subject

guus: we need a proposal to move forward
... can someone distil a proposal out of the emails?

cygri: design from email was close to a last-call design from 2003, can we just pull something from there?

jeremy: problem with first design is that in RDF/XML the literal is not an XML element, but is instead something else, so processing is ugly

ivan: is there any way around that at all?

jeremy: this was a historical artifact even in 2003

<sandro> does anyone really use this?

ivan: canonicalization is only needed when comparing XMLLiteral values

<gavinc> sandro: No. 'cause as far as I know raptor, python rdflib, and sesame don't work according to the spec ;)

jeremy: value space is then equivalence classes under canonicalization, so implementations don't have to canonicalization

<gavinc> +1000

andy: can we excise XMLLiterals from base RDF, thus lessening their impact?

<mischat> ooh, that sounds sensible

<AZ> +1

cygri: I would even prefer them to be optional in datatype maps

<AndyS> (still need to deal with in RDF/XML syntax)

<Zakim> cygri, you wanted to ask if wrapper element is really needed

<gavinc> Yes, well XML got a lot less sexy since 2003

<Zakim> pfps, you wanted to say that implementations don't have to canonicalize even under the current situation and to say that there was considerable pushback on this

<davidwood> It is no longer 2003

pfps: there was considerable pushback on making XMLLiteral optional in 2003

cygri: this may have been for internationalization, which should be muted now

<ericP> i believe cygri's proposal sacrifices { <s> <p> "<a:foo xmlns:a="abcd"/> } == { <s> <p> "<b:foo xmlns:b="abcd"/> }

<ericP> if we search hard, we might even find someone who's used that

<gavinc> http://www.google.com/trends?q=XML

pfps: the people who wanted RDFXML to be the one syntax for RDF wanted XMLLiteral to be required

<Zakim> JeremyCarroll, you wanted to mention syntax

andy: there are more syntaxes now, so the situation may have changed

jeremy: historical concerns were also a concern in 2003

<gavinc> PROPOSAL: Move XMLLiteral from Concepts and Semantics into a Note

<mischat> why can't it go into RDF/XML ?

ivan: proposal would be that XMLLiteral is just like any other datatype, and not even as important as XML datatypes

andy: document on XMLLiteral could be REC or NOTE

<Guus> suggest to go with with keeping it in doc as opaque datatype

ivan: separate document may be overkill - how about in the document but maybe optional?

<cygri> ivan +0.9

<AndyS> Put it in syntax? (as mischat)

<mischat> given that is only used in rdfxml why not move it in there ?

<AndyS> Various mentions in semantics

cygri: moving it out of the core documents is appealing, but it is mostly harmless to keep it in

andy: how about making it an appendix?

<swh> mischat, that would mean you couldn't do RDF/XML -> Turtle without loss - not necessarily a big thing

pfps: how about making it a footnote?

guus: let's get the editor to propose wording

<mischat> swh you can't at the moment, re: uriRef and iri , and other things iirc

guus: proposal - keep XMLLiteral in documents, but make it optional

ivan: OK by me

jeremy: opposition to this proposal is likely to be outside this group

ericP: are we expecting canonicalization

jeremy: yes, we expect canonicalization, but there are people who don't, and won't

ivan: can we state where canonicalization is to happen?
... currently many implementations don't conform here

jeremy: early canonicalization is easier, particularly in XMLLiteral

<zwu2> an example http://www.w3.org/TR/owl-test/misc-200-xmlliteral

ivan: jeremy - I do not agree that XMLLiteral is used only in RDFXML, e.g., DRUPAL

<AndyS> HTML in RDF is another matter.

<cygri> i'd like to do this in turtle: <> dc:title "E=mc<sup>2</sup>"

<ericP> cygri, { <> dc:title "E=mc<sup>2</sup>"^^rdf:XMLLiteral } >

<gavinc> Nope, that's not valid either ericP ;)

jeremy: if you are creating XMLLiterals you should be doing it right (which is not easy)

<Zakim> pfps, you wanted to discuss a modest proposal

<gavinc> <> dc:title "E=mc<sup>2</sup>"^^my:HTMLLiteral ;)

<JeremyCarroll> jeremy: was misscribed ....

<davidwood> pfps +1

<sandro> +1 I like the idea of "just string"....

pfps: how about making XMLLiteral be string, and pushing off to parsing

<mischat> +1

<sandro> why canonicalize it in RDF/XML ?

<cygri> sandro, because RDF/XML does that already

<sandro> guus: so the datatype is basically just a semaphore

<gavinc> Oh god, oh god, oh god

jeremy: then RDF/XML spec specifies canonicalization, and value space is canonicalization equivalence classes

<zwu2> not a bad implementation :)

pfps: this would not be my proposal

<Guus> ipeter's proposal makes the spec easier; I like that

ivan: in a triple store, what do I do with an XML Literal

pfps: in my proposal, it is just a string - I think that this codifies current practice

<AndyS> FILTER(007 = 7) is true.

<AndyS> Strict, minimal pattern matching (RDF) and FILTER (XSD) differ

cygri: canonicalization is because RDF/XML parsers change the input, so canonicalization is the only way to recover
... so canonicalization in RDF/XML makes sense, and everyone else just leaves it alone

<ericP> i think cygri's suggestion applies to RDF/XML using parseType="Literal", but probably not to <rdf:Description><foo:bar rdf:datatype="http://...XMLLiteral">E=mc&lt;sup&gt;2&lt;/sup&gt;</foo:bar><rdf:Description>

cygri: canonicalization for comparison appears to be missing a use case

<cygri> ericP, yes, i meant only parseType="Literal"

jeremy: RDF/XML spec also requires ignoring some syntax features

<Zakim> JeremyCarroll, you wanted to add to Ricghard's point

ivan: in turtle, XMLLiteral is just passed through; why do differently in RDF/XML?
... RDF/XML parsing does something

cygri: RDF/XML parsers use an XML parser, which may modify strings

ivan: agreed, but who cares, d-entailment will fix

cygri: but RDF says that these changes should not occur when storing

<gavinc> No

ivan: so change MUST to SHOULD

<gavinc> They don't

<gavinc> raptor, rdflib, etc

pfps: I agree with gavin

<Zakim> ericP, you wanted to say RDF/XML's parseType="Literal" would produce a subset of the possible lexical space. turtle-writers looking for equivalence with stuff parsed in RDF/XML

eric: RDFXML parsing produces a subset of the literal space, others should stick to this subset but need not

ivan: literal space has a bunch of XML Literals, parsers do different things

guus: continue debate and see where we get
... action on issue 76 on semantics

<gavinc> Whoohoo! Named Graphs!

Named Graphs

guus: some consensus that graph names should be URIs

sandro: what

guus: the four slot

sandro: graph label was also not objectionable

<sandro> sandro: don't call it 'graph name', call it "graph label" or "fourth column"

guus: any more consensus?

<gavinc> Question!

guus: closing pending issues

<gavinc> ah well

<gavinc> -q :(

<mischat> bye

<cgreer> thanks

<gavinc> So we're about half way into the WG time line... expected publication date for TriG? :\

<gavinc> trackbot, end meeting

Summary of Action Items

[NEW] ACTION: cygri to add list of XSD types to Concepts (assuming no objection from PatH or pfps) until 2011-11-25 [recorded in http://www.w3.org/2011/11/16-rdf-wg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/11/16 17:17:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/pending/pending-review/
Succeeded: s/action 129/action 119/
Succeeded: s/nor/or/
Succeeded: s/gavinc/eric/
Found ScribeNick: pfps
Found Scribe: pfps
Inferring ScribeNick: pfps
Default Present: David, +30889aaaa, ericP, +1.707.861.aabb, AndyS, gavinc, yvesr, +1.707.318.aacc, Peter_Patel-Schneider, cgreer, Arnaud_LeHors
Present: David +30889aaaa ericP +1.707.861.aabb AndyS gavinc yvesr +1.707.318.aacc Peter_Patel-Schneider cgreer Arnaud_LeHors

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

Found Date: 16 Nov 2011
Guessing minutes URL: http://www.w3.org/2011/11/16-rdf-wg-minutes.html
People with action items: cygri

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]