RDF Working Group Teleconference -- 30 Nov 2011

<trackbot> Date: 30 November 2011

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 30 November 2011

<scribe> scribenick: gavinc

Admin

Guus: Didn't have a meeting last week for Thanksgiving. Small meeting this week with so many at SemTech

gavinc: Updated Graph-TF wiki page, tried to find more info from mailing lists. Added link to RDF Concepts datatypes to Turtle

<AndyS> AndyS has no progress to report on action #119 "Create a short example for a TriG document and a clear notion of what is entailed by it" - sorry

AndyS: No progress on ISSUE-119

<AndyS> s/ISSUE/ACTION/ !!!!!!!!

<AndyS> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs

Guus: PatH completed ACTION-116
... Sandro and David Wood can't make it next week. May need to cancel

RDF XMLLiterals

Guus: Richard is not here. Who wants to give the current status of this debate?

AndyS: I don't see any reason to keep XMLLiterals hard coded into the specs.

<PatH> +1

AndyS: As long as their optional, not that concerned about them

PatH: Was there any consensus in emails?

Guus: Needed for RDF/XML, but not much else.
... No significant disagreement

avk me

gavinc: No strong opinions if it's optional, but the value space is a bit complicated

JeremyCarroll: People seem not to want to mention XML C14N. I think I should provide a rationale

<PatH> +1 to Jeremy. I suggest masking it optional taks away most of the pain.

<PatH> masking/making

JeremyCarroll: If you need to compare things, C14N is a requirement. If you want to do logical operations over it then you need to do the C14N. We need to specify how to do compare, but not every application needs to do compare
... Making it optional seems like the key change.
... I prefer doing in L2V mapping, but was easier as an implementor do it in the XML parser
... At some point will need to compare an XMLLiteral from RDF/XML and Turtle, wherew will we do the work? I think right now we're saying to do it durring the compare

<ericP> editorially, we could motivate this by use cases: "For use cases which motivate equivalence between XML literals, generators of XML literals rfc2119:SHOULD canonicalize XML literals by XML Canonicalization"

AndyS: You said that the XML comunity has done some work on equality?

JeremyCarroll: XML C14N talks about equality, XML infoset doesn't.
... Namespaces are an example of this.
... XML C14N addresses what to do with XML Namespaces
... There are not perfect answers here.

pfps: If reading from an XML document, I understand why you need to get this right, but if your not using XML documents. In Turtle you can treat them as string

Guus: This could be in RDF/XML no RDF Concepts?

<PatH> if this is optional as a datatype, then we can have two kinds of xml literals with different mappings and values.

JeremyCarroll: I think pfps, I think XMLLiteral should compare as a String, and RDF/XML should do the XML C14N, but in Turtle don't do anything. Only works if hand codded perfectly.

<ericP> gavinc: pfps's approach sounds OK

<ericP> ... i've used XML literals a fair amount. I don't think XML literal meets any of its original use cases.

<ericP> ... you can't use it for fragments 'cause c14n talks about documents

<ericP> ... fragments get strange

<JeremyCarroll> hmmm - xc14n is all about fragments not documents ...

<ericP> ... adding formatted XML into RDF seems like a good use case, but we can't use c14n

<PatH> in this pfps proposal, what is the L2V map? what are the literal values? c14n or text?

<ericP> ... we and others put escaped HTML into strings

Guus: I don't want to spend a huge ammount of time on this issue.

ACTION gavinc raise issue around formated text literals

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

ACTION Gavin raise issue around formated text literals

<trackbot> Created ACTION-124 - Raise issue around formated text literals [on Gavin Carothers - due 2011-12-07].

<Zakim> JeremyCarroll, you wanted to correct Gavin's backwards

ericP: ... said stuff about XML C14N ...

Guus: what is the impact?

ericP: for some use cases, generators should use XML C14N

<PatH> editorial...

ericP: Pushing back on only being in RDF/XML

JeremyCarroll: That's a large editoral change.
... Muddling up use cases with normative text is not a direction I want the specs to go

Turtle and SPARQL escapes

Guus: is there consensus?

AndyS: I thought Richards desire and ericP's desires could be resolved with character escapes
... SPARQL can go on with a at risk feature.
... Haven't seen a responce from ericP

ericP: I see all of it as an improvement

<ericP> +1 from me

<AndyS> If this has consensus, SPARQL-WG can proceed as described in http://lists.w3.org/Archives/Public/public-rdf-dawg/2011OctDec/0229.html

<PatH> The 'committee' heuristic: always make as few binding decisions as possible.

<AndyS> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0249.html (first comment)

"Is escaping the URI-legal, non-alphanumerics as character escapes acceptable to you?"

<JeremyCarroll> shall we create an action to make the text?

<identifier_char> : [a-zA-Z0-9-] | \\[URI-legal, non-alphanumerics]

? :D

Named Graphs

Guus: There have been some messages on the uses of the 4th column
... IRI in the 4th column seems to be the consensus

AZ: It is still useful to have Literals in the 4th column

Guus: has to be extreamly compelling to change the design

AZ: For temporal RDF, people are annotating with VALUE, not a IRI
... other proposals that annotate with trust values, which again, are values.

PatH: Allow literals in 4th positions, one can imagine uses
... I don't think we have preserve existing desgin, we don't have one

<AZ> strong +1 PatH

PatH: Should not prohibit values in fields in RDF

JeremyCarroll: Original design had a 5th column
... When you think about it, you want to talk about small graphs (molecules). Give those subgraphs name...

<PatH> the fourth column need not be a graph name. We dont yet have enough experience to know how quads may be used.

<PatH> q

JeremyCarroll: I don't understand the restince to I don't understand the resistance to named graphs.

AZ: Need to be able to relate the IRI to the graph itself as the label.
... The IRI doesn't denote the graph
... Then you can't annotate the triples

PatH: the 4th column doesn't denote, so we shouldn't restrict how it's used

Guus: We don't require the 4th column to denote, so we shouldn't place other requirements on the 4th column

<PatH> losing sound?

<AZ> in SPARQL does really have a "fourth column"

AndyS: SPARQL does not "denote", but does require an IRI

<PatH> to hell with writing a spec in order to preserve someone's optimizers.

<pchampin> anyway, SPARQL does allow literals in subject position, doesnt it?

<pchampin> so optimizing that way is already non-compliant :)

AndyS: The words in the SPARQL algebra say IRI, but could change.

Guus: Would feel more comfortable if the SPARQL working group would respond formally

<AZ> To me it's ok to have SPARQL forbid literals as "name for graphs", it's just that quads with literals would not translate directly to SPARQL datasets

ACTION Guus to ask SPARQL WG about allowing literals in the 4th column

<trackbot> Created ACTION-125 - Ask SPARQL WG about allowing literals in the 4th column [on Guus Schreiber - due 2011-12-07].

<PatH> +i az

<PatH> +1 az

<AndyS> ... That's a gotcha. :-(

<Zakim> JeremyCarroll, you wanted to argue for Named Graphs (with denotation)

JeremyCarroll: The thing with RDF is that we don't have a Triple. We have a subject, predicate, and object. Those are all different

<ericP> i didn't see any LL(1) or LALR(1) grammar conflicts when adding literals to http://www.w3.org/2005/01/yacker?name=trigTurtle&replace=1&lang=perl#prod-trigTurtle_EGP-graph

JeremyCarroll: That is the design. The design is about making choices. You get inter op by having a design and limitations.
... The goal of named graphs was to add the least amount of change to address new use cases.
... I don't see allowing literals in the 4th field to be anything other then us failing to do our jobs

<AndyS> Does any TriG parser enforce one-use of an IRI to id a graph?

<AZ> If it's doomed to be an IRI, then we should be more precise about what that IRI refers to

<JeremyCarroll> Jeremy: the purpose of a standards body is to make decisions in the design

pchampin: no one wants to restrict what the 4th column can be

<JeremyCarroll> Jeremy: not to provide general machinery that can be used in a non-interoperable fashion

<JeremyCarroll> Jeremy: previous group went for Subject, Predicate, Object as a triple, not three general items

<JeremyCarroll> Jeremy: we should specify what the 4th column is specifiying

pchampin: going back to older proposal graph is not labeled not by an IRI but by a resource

<JeremyCarroll> Jeremy: making it identify the graph is clear and works with the previous spec

PatH: I'm sympathetic with JeremyCarroll's position. I like that design. I've been working there for some months, but that it's untenable.
... quad stores violate that design.
... we need to rethink what that 4th position is
... we shouldn't tie ourselves up

<pchampin> +1 to pat

Guus: If the IRI is not forced to denote, then we should make very clear why it's an IRI

Back to Escapes

<AndyS> (this discussion invalidates my action 119)

<AndyS> The set of character escapes for the local part of prefix names is ~.-!$&'()*+,;=:/?#@%_ (token: PN_LOCAL), the set of URI-legal, non-alphanumerics (path, query and fragment).

<AndyS> Any generated IRI is still subject to rule governing the legality of IRIs. e.g. og:audio\:title (This does not cover one way or the other (1) adding %xx with unescaped % in PN_LOCAL (2) \u escapes in Turtle)

<PatH> I will escape now:-)

#! ;)

<AndyS> PROPOSAL: The set of character escapes for the local part of prefix names is ~.-!$&'()*+,;=:/?#@%_ (token: PN_LOCAL), the set of URI-legal, non-alphanumerics (path, query and fragment).

<ericP> +1

ISSUE-67

<MacTed> The set of character escapes for the local part of prefix names is ~.-!$&'()*+,;=:/?#@%_ (token: PN_LOCAL); i.e., the set of URI-legal, non-alphanumerics (path, query and fragment).

ISSUE-67?

<trackbot> ISSUE-67 -- \xxxx escaping in prefixed names -- open

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

ISSUE-74?

<trackbot> ISSUE-74 -- Prefixed names and slashes -- open

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

<MacTed> +1 to proposal, with my insert :-)

<AndyS> PROPOSAL: resolve ISSUE-74 with -- The set of character escapes for the local part of prefix names is ~.-!$&'()*+,;=:/?#@%_ (token: PN_LOCAL); i.e., the set of URI-legal, non-alphanumerics (path, query and fragment).

<ericP> +1

<MacTed> +1

<AndyS> RESOLVED

trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

30 Nov 2011

Attendees

Contents

Admin

RDF XMLLiterals

Turtle and SPARQL escapes

Named Graphs

Back to Escapes

Summary of Action Items

Scribe.perl diagnostic output