RDF Working Group Teleconference -- 01 May 2013

<trackbot> Date: 01 May 2013

scrbenick cgreer

scribenick cgreer

<ivan> scribenick: cgreer

thx

admin

proposed: accept minutes of 24 April telecon

pfps: The links in the minutes absorb trailing punctuation
... the URI poster is somehow messed up

RESOLUTION: to accept the minutes of the 24 April telecon

subtopic: action items
... Etiquette for responding on public-comments list

Guus: We must be polite and take comments seriously

<sandro> +1

Guus: we've got a lot of documents going out and keep this in our mind at this time
... so keep in mind difference between public list and internal one

ericP: Apropos of comments, I've been tracking them in the wiki, just on turtle.

<ericP> turtle comments

ericP: I'm looking for people to close issues. The protocol is to put your name under the owner.
... If you're taking ownership of comments, record owner and resolution please

PatH: I was wondering if there's been any behavior to prompt this comment

Guus: About RDF/JSON is what I was mainly referring to, but we'll discuss that when Manu is present.

Issues related to Concepts and Semantics

subtopic: issue 118 Simplifying datatype semantics

<PatH> http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0012.html

PatH: The text here basically tries to avoid a semantic-y taint
... It instead speaks of IRIs and referents

ivan: Perfectly answers my comments

pfps: I'm trying to look up 'rigid identifier'
... It's not in semantics yet.

PatH: Right, but it's in the proposed text

pfps: My concern -- if somebody uses an IRI for a datatype, it seems as though that 'fixes it for everyone'
... The change would be 'implementations that recognize datatype X'...

PatH: I'll adapt, get rid of 'rigid identifier'
... It's a red flag anyhow
... I'll prepare something to vote on now

subtopic: RDF Merge in Semantics

See http://lists.w3.org/Archives/Public/public-rdf-wg/2013Apr/0139.html

pfps: AZ has a point that other specs use 'merge' so it has to stick around in addition to 'union'
... That's OK. You keep the term around for those circumstances where you need to cope with blank nodes

<pfps> PROPOSED: add wording to Semantics to again define the merge of two RDF graphs

<sandro> pat: it was an editorial mistake which I will correct. no need for group decision

<sandro> guus: fine.

action to PatH: add wording to Semantics to again define the merge of two RDF graphs

<trackbot> Error finding 'to'. You can review and register nicknames at <http://www.w3.org/2011/rdf-wg/track/users>.

<Guus> ACTION: PatH to add wording to Semantics to again define the merge of two RDF graphs [recorded in http://www.w3.org/2013/05/01-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-261 - Add wording to Semantics to again define the merge of two RDF graphs [on Patrick Hayes - due 2013-05-08].

Turtle

gavinc: one of the possible outcomes of the problem is to remove XML and HTML from concepts.
... the issue is DOM requirements
... The HTML fragment parsing as it stands produces an HTML document.
... There's a spec in progress for a fragment, but it's part of Web Components
... and it's still a WD
... for XML, we're referencing DOM4, not DOM3
... the question of 'can we reference DOM4' is resolved, but what about fragment parsing part of HTML

sure it makes sense

Guus: What do we need to fix?

gavinc: The DOM4 vs. 3 is resolved. The HTML issue is a little more complex
... The fragment parsing for HTML just ain't stable

ivan: Why do you say referencing DOM4 is OK?
... This is also a WD
... I'm wondering whether we need DOM4.

gavinc: THere are comparison methods in DOM3, but they are not implemented

<gkellogg> You could reference the WHATWG version of DOM4.

<markus> was just about to propose the same :-)

gavinc: What's specified in DOM4, although it's a WD, there are implementations at least

ivan: We still don't know whether or not we can reference DOM4. The other issue though...
... perhaps we can say that HTML datatype is not normative

gavinc: That gets around process problem, but doesn't help implementors
... I want to just make sure that implementors get HTML datatypes right

sandro: Let's put aside procedural problems.
... So this comes up if somebody's writing an RDF system and somebody wants to match HTML datatypes, even if representations are different
... worst case is that they cannot do value comparisons

gavinc: Either that or people expect HTML that you can actually use

ivan: Or equality in SPARQL, but it doesn't happen

sandro: Because you're expecting normative ops, attribute order, whitespace, etc.

gavinc: Or all-closed elements vs non-closing ones.

sandro: As a programmer, I'd be happy if it matched, but we're not used to that as of yet

gavinc: every web browser will do the right thing here
... This does happen a lot

sandro: But are you comparing HTML literals really?

gavinc: But output HTML we expect to look the same, as an effect of parsing

sandro: We can disagree about how important this is, but that people can get by without this

gavinc: Value vs. literal for HTML (and XML)

<PatH> revized wording for issue 118 is now here, suitable for voting if voting is required: http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0014.html . Just sayin.

sandro: Is this the only thing wrt HTML?

gavinc: Yes, that's it

sandro: I'd be comfortable with our declaring that the HTML datatype value process is still not fully determined
... and until that's settled, the datatype is a flag
... to expect further work in this area

gavinc: And to point to where value processing is being worked out
... we want people to implement this, but also to point out that it's not final yet

sandro: Is it also a question about non-HTML syntax?
... like a literal that's '<' but HTML datatyle

gavinc: That's an ill-typed literal

<AndyS> Suggest we avoid test cases if we're outsourcing to DOM4/whatever for final definition as small details may change after we're finished..

gavinc: you have to be able to parse at least

<markus> wondering whether it wouldn't be better to rename rdf:HTML to rdf:HTML5...

<ericP> <p class="C" style="color:red;"/> == <p style="color:red;" class="C"/>?

<ericP> can we count on trivial equivalence?

<gavinc> yeah, stuff like that ericP

sandro: I'm proposing that we look for an older HTML that is meaningful for this?

gavinc: There's no standard anywhere about HTML fragments

ivan: And we can't refer to an older one.

gavinc: older HTMLs also didn't deal with fragment parsing

sandro: My point is that we don't specify which HTML

<markus> good point

<yvesr> +1

PatH: This does seem as though we're doing something too wishy-washy with HTML

gavinc: the idea is to dodge the lexical-value mapping for HTML

PatH: Which violates our spec

ivan: I don't see another choice.
... We could wait a couple of years to finalize RDF but that's not an option either

<sandro> PROPOSAL: we're specifying rdf:HTML deferring the semantics (lexical-to-value mapping) to whatever is latest/greatest HTML standard. This only comes up for people trying to do D-Entailment on rdf:HTML literals --- determining equality of value, and checking for ill-typed.

sandro: This is so complex .. the basic idea has been stable, but little bits keep changing

PatH: But we didn't have HTML before.

ivan: Now we have HTML which is not XML. It's much more common now

markus: Why do we need to normalize HTML at all?

<gavinc> Not normalizing! Just parsing

markus: we could just use string comparison
... isn't that viable?

ivan: In practice that would be difficult.
... same issue in XML. XML literals rely on XML tools
... and the tools can produce a different literal

markus: but you can't have interoperability in this case.

<gavinc> eh, 3 or 4 months ;)

ivan: out hope is that in two years HTML5 WG will finalize

markus: Then HTML6 will come

gavinc: To be clear we're talking about fragment parsing algorithm, not HTML5
... this is weirder than you think it is

<PatH> we are tslking about this: http://www.w3.org/TR/rdf11-concepts/#section-html

sandro: How about two data types. HTML-String and parsed-HTML-string
... we can't define the latter yet

pfps: I've seen a solution to this in Schema-datatypes
... to be compliant you can either use XML 1.0 or XML 1.1
... which was written when 1.1 was in flux

sandro: It's a bit analogous to our dependency on Unicode

ericP: But the contract with Unicode is that there will be no new punctuation

gavinc: and HTML's main goal is backwards compat

ericP: HTML doesnt provide for forward compat

gkellogg: Perhaps we can require that implemenations provide equality based on string comparison, but have an option to change in future

sandro: The question is what if we do use D-entailment

<gavinc> Yeah, we WANT people to do lexical-to-value mapping

sandro: we want people not to have to remember the string
... the string is gone if you parse
... sounds like we need two datatypes, the second one will change

gavinc: The one that doesn't map to a value doesn't have a datatype

PatH: It's its own value space

sandro: The value space is 'string'

gavinc: This reads funny. lexical space and value space are the same

sandro: yep it's string with a flag

gavinc: I'm amused

sandro: I need to know about the flag.

gavinc: Would then HTML entities be equivalient to same string?
... would seem to be no

ivan: I'd me more comfortable keeping what we have now, plus a little hand waving

<sandro> STRAWPOLL: (1) two html datatypes, parsed and unparsed; (2) one html datatype, semantics not set yet, (3) something else

<sandro> 1 2

<ivan> 2

<PatH> tnx ivan

<Guus> pref 2, can live with 1

I prefer 2

<gavinc> 2 (lexical to value mapping to be defined later)

<gkellogg> 2

<AndyS> 2

<pchampin> 2

<ericP> live with 1, prefer 2

<yvesr> 2

<SteveH> 2

<zwu2> 2

<TallTed> prefer 2, OK with 1

<markus> 1 2 (would prefer to just have unparsed)

<PatH> 3

<Souri> 2

<gavinc> +1 PatH

PatH: 'something else' is that we should be explicit about defining but that it's changeable

ivan: That's what I meant by 2
... we make it clear that it's a soft target

<sandro> PROPOSAL: we'll specifying rdf:HTML by deferring the semantics (lexical-to-value mapping) to whatever is latest/greatest HTML standard. This only comes up for people trying to do D-Entailment on rdf:HTML literals --- determining equality of value, and checking for ill-typed.

<sandro> +1

<ivan> +1

<yvesr> +1

<PatH> +1

<zwu2> +0

<gavinc> +1

<TallTed> +1

<sandro> guus: it's editorial how much of this we say this now.

<Souri> +1

<sandro> RESOLVED: close issue-63: we'll specifying rdf:HTML by deferring the semantics (lexical-to-value mapping) to whatever is latest/greatest HTML standard. This only comes up for people trying to do D-Entailment on rdf:HTML literals --- determining equality of value, and checking for ill-typed.

<sandro> (or it was already closed, but tag this as related to issue-63)

<PatH> http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0014.html

subtopic: back to issue 118

<Guus> PROPOSED: to resolve ISSUE-118 according to Pat's proposal in http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0014.html

hahah

<ericP> what's the interpretation of { <s> <p> """<script type="text/turtle"><s><p2><o2></script>"""rdf:HTMLLiteral . } ?

<ivan> +1

<pfps> +1

<ericP> 8.3

<PatH> +1

<gkellogg> +1

<TallTed> +1

<zwu2> +1

<sandro> +1

<pchampin> +1

<yvesr> +1

<markus> +1

<Guus> RESOLVED: to resolve ISSUE-118 according to Pat's proposal in http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0014.html [17:55] <cgreer> hahah

Guus: We're done with concepts and semantics.

<PatH> woot

<sandro> eric, that graph means that s has a p which is the html text "<script type="text/turtle"><s><p2><o2></script>".

Guus: Two minutes for JSON-LD and Turtle
... How about that turtle test suite?

gavinc: blocked by feature at risk

ericP: Also 0 in literals

gavinc: That's fine in test cases
... we should datatype them something else if they're not strings
... I started the action for feature at risk.

<sandro> +1 have some test cases on "\0"^^<example.org/something>

gavinc: lots of 'meh' on prefixes
... and some who don't like it

Guus: please complete action by next week

sandro: is everything on comments page?

<markus> just realized that JSON-LD LC ends next week

gavinc: yes, no positive ones, just two negative ones.

<PatH> gotta run. bye.

gavinc: strongest argument is that we've not changed turtle except this

sandro: but that's not true

<ericP> i would characterize DBooth's response to those comments as positive

Guus: but we are done for this week.

<Guus> trackbot, end meeting

- DRAFT -

RDF Working Group Teleconference

01 May 2013

Attendees

Contents

admin

Issues related to Concepts and Semantics

Turtle

Summary of Action Items

Scribe.perl diagnostic output