RDF Working Group Teleconference -- 22 May 2013

<trackbot> Date: 22 May 2013

<AZ> akim, who is here?

<sandro> trackbot, start meeting

<trackbot> Meeting: RDF Working Group Teleconference

<trackbot> Date: 22 May 2013

i can scribe if necessary

<scribe> scribenick: pfps

<ivan> http://www.w3.org/2008/04/scribe.html

<gkellogg> http://www.w3.org/2009/CommonScribe/manual.html

<scribe> scribe: pfps

admin

subtopic: minutes

proposed: accept minutes of last meeting minus one resolution (see agenda)

<AZ> "There are some format problems with the chatlog" it says

PROPOSED: accept minutes of last meeting minus one resolution (see agenda)

minutes looked acceptable to me

RESOLUTION: accept minutes of last meeting

<AndyS> So we are opening issue-131 then? It's just "raised" currently.

guus: resolution about blank nodes as graph names should be withdrawn

<sandro> guus: I'll make issue-131 "open"

<Arnaud> I fixed the formatting errors in the minutes of May 15

guus: resolution about blank nodes from last week is withdrawn and issue-31 is opened to track the question

subtopic: actions

pfps: I pushed quite a few actions to pending review - they all should be done by recent edits to Concepts or Semantics

<gavinc> Close ACTION-260

<trackbot> Closed ACTION-260 Gather data for resolving the turtle feature-at-risk..

<sandro> close action-264

<trackbot> Closed ACTION-264 Find the history and suggest phrasing for Concepts.

Close ACTION-264

<trackbot> Closed ACTION-264 Find the history and suggest phrasing for Concepts.

sandro: action 264 is obsolete

guus: please record status in action note

Concepts and Semantics LC drafts

Pat: Semantics needs some work to account for comments from peter

Peter: I looked over Concepts and it looks in good shape, modulo one issue

Guus: ISSUE-131 and language tags, language tags first

Language Tags

Andy: proposal is to define a value space for rdf:langString and do some more fixups

<sandro> andy: rdf:LangString becomes a normal data type except for ...

peter: what's the difference?

andy: currently abstract syntax doesn't correspond with what systems do

<sandro> andy: in the current rdf-concepts the abstract syntax messes around with the language tags

peter: the proposal is to do something different for language tags in the abstract syntax

andy: yes, the abstract syntax doesn't mess with language tags
... then it doesn't have to be built in

peter: I don't understand how this can be

<gavinc> (The abstract syntax DOES mess with language tags today)

<sandro> pfps: The way to make langstring not built in, you have to make it not-special.

peter: rdf:langString is special the only way to make it not built-in is to make it completely non-special

<sandro> PatH: The weird part is that it has two strings in its lexical space instead of one.

peter: the proposal is then to make it half-special?

andy: and also to remove lowercasing of language tags in the abstract syntax

sandro: what is the difference?
... what are the testcases? number of triples? entailment? anything else??

<ivan> issue-131?

<trackbot> ISSUE-131 -- How can one create an RDF dataset without being a web server? -- open

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

peter: it appears to me that the number of triples will change but no entailments will

<sandro> { <a> "chat"@fr, "chat"@FR }

<sandro> that's two triples in andy's proposal

pat: several issues: 1/ upper vs lowercase 2/ unspecial 3/ built-in
... we could not require rdf:langString in RDF entailment

<gavinc> sandro, that's two triples in raptor, 4store, jena, rdflib, ...

pat: I don't care about 1, we can't do 2, and I don't care about 3

peter: the hardest thing from the point of Semantics is to handle language tags specially

andy: isn't there special stuff for language tags?

peter: not really

<Zakim> ericP, you wanted to add minor issues around case-preserving and impl burden of BCP-sensitive normalization

eric: implementers care about case

<gavinc> It isn't one triple! It's two triples, and I can't see any implementations that make it one :P

sandro: rdf 1.0 is confusing

<gavinc> I agree, RDF 1.0 says it's one.

andy: rdf 1.0 is clear that language tags are lowercased

<gavinc> But everyone doesn't.

andy: and there is a test case

<PatH> andy is muffled hard to hear

<AZ> In RDF 1.0: "Plain literals have a lexical form and optionally a language tag as defined by [RFC-3066], normalized to lowercase"

<sandro> sandro: I don't think the language in the RDF 1.0 clear at all.

eric: we could say normalize to BCP recommended form (which would be annoying)

andy: i would like there to be two triples

<gavinc> 4store is... amusing in this area ;)

<sandro> "Note: The case normalization of language tags is part of the description of the abstract syntax, and consequently the abstract behaviour of RDF applications. It does not constrain an RDF implementation to actually normalize the case."

andy: if there is one, then there is the issue of what surface form to keep
... but it is required to act as if it did normalize

sandro: so in practice it's like 1 and 01 - sparql let's implementations vary

andy?: the SPARQL test cases are quite specific

<gavinc> One reason why it "works" in RDF 1.0 is that XML says that language tags can only be BCP 47 valid language tags, which includes case... but is not the SAME case as the abstract syntax expects

<sandro> andy: SPARQL weasels around this by saying you can normalize on loading.

<sandro> sandro: I think we need to do something wealy like that in RDF as well.

pat: where is the SPARQL test case that give two results, for 1 and 01

andy: it depends on where and whether entailment is in force

<sandro> andy: In a FILTER then value matching applies; in graph matching 1.0 and 1.00 look different.

pat: in practice then normalizing is wrong

<ericP> Plain literals have a lexical form and optionally a language tag as defined by [RFC-3066], normalized to lowercase.

sandro: no, systems can normalize on input, so you can't figure out what is going on

<sandro> sandro: So what about SPARQL UPDATE? Insert 1.0 does it match 1.00 ???

guus: can we make progress?

<gavinc> I am happy with the proposal as is.

sandro: compatability says we be permissive

http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0224.html

<ericP> +1 to Andy's #2

guus: second part of the proposal? any changes?

<ericP> +1 to the *spirit* of Andy's #2

<gavinc> It already IS an exceptional case.

pat: this doesn't fit into the standard datatype model, so it has to be exceptional

<gavinc> +1 to defining the value space of langString

andy: this is all about the value space of lang string

pat: langString is a special case, and there is no proposal to make it not so

<sandro> PROPOSED: The value space of rdf:langString is the set of pairs (string, LC-lang) where LC-lang is a lowercase language tag.

<ivan> +1

<davidwood> +1

<Souri> +1

<ericP> +1

<sandro> +1 (but this doesn't settle everything about langString)

<gkellogg> +1

<gavinc> +1 (someone else gets to go see if langMatchs is unhappy with that)

<Guus> +1

<AndyS> +1

<gavinc> Yay

<gavinc> :D

<AZ> In RDF 1.1 Concepts: "Language-tagged strings have the datatype IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#langString. No datatype is formally defined for this IRI because the definition of datatypes does not accommodate language tags in the lexical space. The value space associated with this datatype IRI is the set of all pairs of strings and language tags."

<AndyS> concepts : 3.3 and notes on sec 5

-1, because this proposal doesn't match the discussion

eric: let's make them two triples

sandro: no, the proposal is to make the number of triples ambiguous

<AZ> The proposal makes <s> "aaa"@EN and <s> "aaa"@en two triples

eric: so a SPARQL query would give one triple in 2004, but now would be either one or two
... the motivation for allowing two triples is that implementations work this way
... are there people who are counting on these two triples?

<sandro> PROPOSED: The value space of rdf:langString has the language tag in lower case; the lexical form MAY be converted to lower case (as RDF 1.0 says, but not everyone does).

eric: if there is enforcement then no one may care

<sandro> PROPOSED: The value space of rdf:langString has the language tag in lower case; in the lexical form, the language tag MAY be converted to lower case (as RDF 1.0 says, but not everyone does).

<gavinc> BCP 47 says that en-US is a BCP language tag, and en-us isn't :P

<sandro> eric: BCP-47 says language strings are case insensitive.

sandro: BCP-47 says that language tags are case insensitive

<davidwood> Section 2.1.1 of BCP 47: "At all times, language tags and their subtags, including private use

<davidwood> and extensions, are to be treated as case insensitive"

<davidwood> +1

<sandro> +1

<gkellogg> +1

<ivan> +1

<gavinc> +1

<AndyS> +0.5

<PatH> +1

-0, because this is a change that I don't think needs to be made

<yvesr> +0.5

<sandro> RESOLVED: The value space of rdf:langString has the language tag in lower case; in the lexical form, the language tag MAY be converted to lower case (as RDF 1.0 says, but not everyone does).

<AZ> +0.5

<ericP> "At all times, language tags and their subtags ... are to be treated as case insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning.

<Souri> question: if I use { ?x :attrName "color"@en-us} in SPARQL what is the expected output if data presented was: _:b1 :attrName "color"^^EN-us

<ericP> "

david: I'll put this into concepts

<sandro> ACTION: david to implement the langString resolution in rdf-concepts AND ENJOY IT [recorded in http://www.w3.org/2013/05/22-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-265 - Implement the langString resolution in rdf-concepts AND ENJOY IT [on David Wood - due 2013-05-29].

<gavinc> ericP, Yep :D

guus: section 3 of proposal

<PatH> souri, it has to match in that case.

<gavinc> However the ABNF is case sensitive, and has lovely rules like sgn-BE-NL

andy: section 1 loosens requirements for RDF processors
... there are no conformance issues being raised

sandro: syntax processors need to be able to handle the special syntax for rdf:langString

andy: Semantics says that processors must recognize rdf:langString

<Souri> thx Pat, so every RDF implementation is required to at least keep it in the form _:b1 :attrName "color"^^en-us, but optionally, in addition, it may also store _:b1 :attrName "color"^^EN-us.

pat: we now have something special that is being stuck in Semantics for rdf:langString

andy: but that's already in Section 8

sandro: it already was a test case

<sandro> So RDF Simple Entailment: <a> "chat"@FR ENTAILS <a> "chat"@fr

andy: D-entailments include rdf:langString

guus: time

pat: I don't care either way

guus: part 3?

<AndyS> PROPOSAL: remove "other than rdf:langString and xsd:string"

<sandro> agreed observation: <a> "chat"@FR ENTAILS <a> "chat"@fr IF you recognize rdf:langString. Whether that's in RDF Simple Entailment isn't decided yet.

<AndyS> PROPOSAL: remove "other than rdf:langString and xsd:string" in "RDF processors are not REQUIRED to recognize any datatype IRIs other than rdf:langString and xsd:string"

<sandro> +1

-1

<Souri> +1

-0.5

<PatH> 0

<Souri> +0

<yvesr> 0

<ivan> 0

<AZ> +0

<gkellogg> 0

<AndyS> (section 7 of MT)

pfps: there is all this stuff for rdf:langString so we should require it

<AZ> actually +0.5

<AndyS> +1

<gavinc> +1

<PatH> +1

<gavinc> xsd:strings are NOT for binaries

pfps: there was a discussion last week about using strings for binaries, and this change validates that very, very, very bad usage

<sandro> pfps: The reason to keep it: discussion last week on xsd:string for binaries. This change invaldates that.

<sandro> pfps: If you allow RDF implemntations to treat strings as ininterpreted, then you're allowing zeros in them.

<sandro> andy: By you can put NUL into integers!

<sandro> pat: It's just an ill formed integer

<AZ> BTW, currently, Simple semantics implies: {<s> "chat"@FR} does not entail {<s> "chat"@fr}

<sandro> <a> "\u0000"^^xs:int is a syntactically valid RDF triple.

<sandro> guus: Not comfortable accepting this resolution yet.

guus: there does not appear to be obvious consensus

pfps: it would be nice to have some consensus forming via email

guus: can we have discussion of 131 via email this week
... we want LC drafts of Concepts and Semantics by mid-June

andy: W3C team please remind us what happens if we miss the end of the extension

ivan: we will be in deep trouble

<gavinc> Turtle? :(

guus: we need to resolve these issues next week

pat: these issues need to implemented in documents, so they need to be implemented

ivan: if Semantics isn't ready by the end of next week then I can't review it

guus: is Semantics close?

pfps: there are a few things that need to be resolved

pat: I hope that these can be fixed on Friday

<AZ> I will review Semantics

guus: the initial review can be done next week

ivan: i will do my best

<gavinc> PrEfIx?

guus: adjourn?

<ericP> wHaT AbOuT It?

<PatH> thanks antoine

gavin: we are trying to wrap things up

sandro: it's not a complete blocking issue

gavin: test cases is waiting on a resolution

<PatH> +1 to whatever y'all are talking about.

sandro: I don't think everyone has looked at it

gavin: please comment on the mailing list

pat: can we get a summary

sandro: we should follow the W3C recommendation

ivan: I don't buy that

gavin: OK I'll write a message
... I haven't seen arguments on the positions

guus: adjourn !

<Guus> trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

22 May 2013

Attendees

Contents

admin

Concepts and Semantics LC drafts

Language Tags

Summary of Action Items

Scribe.perl diagnostic output