See also: IRC log
<trackbot> Date: 17 November 2011
<tomayac> sorry, i can only attend via IRC today
<ivan> agenda call
<ivan> scribe: Gregg
<ivan> scribenick: gkellogg
<ivan> last meeting's minutes
Next Thursday's meeting would be on Thanksgiving in the U.S.
// Propose to cancel next meeting.
<MacTed> (that *might* be escaped properly)
On to "low-hanging" fruit
<trackbot> ISSUE-97 -- Determine if datetime should be supported in HTML5 -- open
ivan: had mailing list discussion and there seems general agreement that it should be accepted.
… some details to settle, being specific XSD datatypes to use.
… dateTime, time, date, gYear, …, duration
… My proposal to keep to HTML5 micro syntax doc: dateTime, date, time.
niklasl: agree that HTML5 spec should dictate allowed values.
… not sure that the detail prevents using other XSD types
… all types are possible to unambiguously match. We could do this if HTML5 allows for it.
MacTed: looking at the issue, it seems that TimeZones are catered for. If not, this must be addressed.
<tomayac> +1 to niklasl. let's have html5 dictate the allowed values.
ivan: timezones are supported.
… includes full microsyntax
gkellogg: HTML5 iso a moving target, and we should indicate willingness to follow.
ivan: can make a proposal to add date, dateTime and time today, but intention is to follow the HTML5 spec.
<ivan> PROPOSAL: HTML5+RDFa will add the time element with date, time, and dateTime, and will also express the intention to follow the time element discussion for subsequent datatypes
<ivan> RESOLVED: HTML5+RDFa will add the time element with date, time, and dateTime, and will also express the intention to follow the time element discussion for subsequent datatypes
ivan: side remark from jeni: we did say that if the lexical content does not match any datatype, then generate a plain literal.
… however, it should ignore language setting.
<Zakim> ShaneM, you wanted to discuss language
gkellogg: also includes text content if there is no @datetime attribute.
shanem: concerned about "plethora" of special cases.
… @about on root element is another example, and issues with <head> and <body>
… including text content, otherwise it doesn't match gYear, ...
… another example of something to keep track of, also the fact that there's no language.
ivan: understand concern, but it generates better triples.
… for element content, we always say that literals that we generate keep whitespace. We should maintain the general rule.
… It may mean that some patterns aren't matched, but they can be constructed to match.
niklasl: we don't normalize? (no we don't)
<niklasl> "Thu, 17 Nov 2011 15:13:39 GMT"
… agree with language.
ivan: this does not follow micro syntax.
… would be a string (plain literal) with no language tag
niklasl: don't think things are as bad as they seem, as we are making things helpful for authors.
<Zakim> ShaneM, you wanted to get a clarification on element content
shanem: might be confused about earlier +1
… thought we were agreeing on @datetime as dateTime, …. Otherwise no triple.
ivan: we said in case string does not match any datatypes we put out a plain literal with the content.
… it is the property plus the value as a plain literal without language.
… no XSD datatype
shanem: disagree with that, if it doesn't match the pattern, it should get language.
<ShaneM> <time property="my:time">its time to fly</time>
ivan: looking at nilasl's example, it is definitely in english.
<ivan> PROPOSAL: if the datetime value does not match a datatype, it is put out as a plain literal, with possible language tag
<ivan> RESOLVED: if the datetime value does not match a datatype, it is put out as a plain literal, with possible language tag
<ShaneM> re: whitespace, this is what the spec says now: A conforming RDFa Processor must preserve white space in both plain literals and XML literals. However, it may be the case that the architecture in which a processor operates has made changes to the white space in a document before that document ever reaches the RDFa Processor (e.g., [XMLSCHEMA-1] processors are permitted to 'normalize' white space in attribute values - see section 3.1.4). To ensure maximum con
gkellogg: microdata-RDF should do the same.
ivan: manu must put this in the HTML5 document.
<scribe> ACTION: fold into HTML5 document anything relevant from these minutes [recorded in http://www.w3.org/2011/11/17-rdfa-minutes.html#action01]
<trackbot> Sorry, couldn't find user - fold
<trackbot> ISSUE-113 -- Add the value attribute of the HTML data element as a possible literal target for property -- open
ivan: value of @value attribute would become a literal target. Similar to @datetime, it is a moving target.
<ShaneM> can datatype effect the interpretation of @value on data ?
… don't think we should try to guess datatype, must be added specifically.
niklasl: it might be that the value is intended to convey a "machine readable" value, so perhaps we should guess datatype.
ivan: we have to rely on what we know today. Based on HTML5 document, we should not go down the road to guessing datatype.
… language tags issue comes up again.
shanem: must be included, there's too much unknown.
<ShaneM> I agree that the language should be preserved for @value on data
<niklasl> .. or a number
ivan: I don't think we should go down the route to try to guessing the intention of the author.
… The @datetime is clearly there to describe time, for data we have no idea what it is for. It may create situations where the guess is wrong and do more harm than good.
<Zakim> ShaneM, you wanted to say that we can't know what @value means
… if author really wants datatypes, author should put it there.
<ShaneM> <data xml:lang='lt' value='veni, vidi, vici' />
shanem: data has no semantics, its "data". Even if I could pattern match it, it could be wrong.
nilasl: it's too early for us to do anything based on maturity of HTML5 spec.
… it's called "data" as it's clearly intended for machine readable datatypes.
… otherwise, it's just an alias for <span>.
shanem: how can you be sure of
... <time> is clear, but <data> is not.
… too many possibilities.
ivan: I could say that I might
intuit the language of a string and add the language to the
literal. That's not our job.
... if HTML5 comes up with a micro syntax, we can look at again. Until then, we should not try to guess it.
niklasl: revisit if the HTML5 spec becomes more clear.
<ivan> PROPOSAL: Accept a <data> element with the @value attribute generating a plain literal with language retained; the HTML5+RDFa document will follow possible evolution of that element defintion for datatypes
<ivan> RESOLVED: Accept a <data> element with the @value attribute generating a plain literal with language retained; the HTML5+RDFa document will follow possible evolution of that element definition for datatypes
<scribe> ACTION: manu1 to resolve to implement 97 and 113 [recorded in http://www.w3.org/2011/11/17-rdfa-minutes.html#action02]
<trackbot> Created ACTION-104 - Resolve to implement 97 and 113 [on Manu Sporny - due 2011-11-24].
<trackbot> ISSUE-116 -- Consider owl terms for vocab expansion -- open
issue: this would mean adding to the current set of terms owl:equivalentProperty and owl:equivalentClass.
<trackbot> Created ISSUE-120 - This would mean adding to the current set of terms owl:equivalentProperty and owl:equivalentClass. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/120/edit .
gkellogg: didn't mean to create an issue, will remove it :(
<ivan> PROPOSED: add owl:equivalentProperty and owl:equivalentClass to the set of terms for the vocab expansion
gkellogg: concerned that it adds a greater burden if we don't replace rdfs:subClassOf, etc.
ivan: we can't remove the others.
niklasl: OWL does build on RDFS.
<ivan> RESOLVED: add owl:equivalentProperty and owl:equivalentClass to the set of terms for the vocab expansion
ivan: already made a version on the core document, and will CVS commit it.
… instead of referring to RDFS entailment, refer to OWL ruleset.
gkellogg: need to figure out how to deal with optional tests for these issues.
shanem: the whole is option, implement all or none.
<trackbot> ISSUE-118 -- Should we consider allowing the '/' character in a term -- open
ivan: "term" defined as NCNAME, meaning that it must begin with a alpha char and can't have a '/'.
<ShaneM> NCTERM is a simple term definintion that does not allow a colon
<ShaneM> NC == No Colon
ivan: propose to allow both a number as a first character and a '/'
shanem: can have a number with NCNAME, just not an ID.
shanem: can't dereference foo#123shane
ivan: so issue is, can we allow a '/'
niklasl: but not as the first character
… can an identifier (NCNAME) begin with a '/'?
shanem: can't have one at all.
<niklasl> .. fragment identifer
ivan: we're talking about a term which is concatenated.
<niklasl> .. vocab="foo#term-"
… vocab="foo", term="/shane" get "foo/shane".
… don't see this as an important use case, but don't see why it should be restricted.
<ShaneM> I have no objection to allowing a slash, but not as the first character....q+ to talk about restrictions
shanem: we don't have ambiguity now because of datatype restrictions. We only use terms with absURI or CURIE.
niklasl: thinking about problems with JSON-LD which may come up here in RDFa.
<ivan> PROPOSAL: allow '/' character to appear in a term, except for the first character
<ivan> RESOLVED: allow '/' character to appear in a term, except for the first character
ivan: will commit changes on
document with OWL terms. Shane, can you make this change?
... high-hanging fruit ...
<trackbot> ISSUE-108 -- Refine/deprecate Link relations for the RDFa 1.1 Default Profile. -- open
ivan: we had the discussion a few weeks ago and thought we had resolved it.
… IANA seemed reasonable, since then, information is that HTML5 decided not to use it, but instead they rely on the Microformat Wiki.
… this makes the list changeable and relatively uncontrolled.
… must revisit decision. My feeling is to drop link relations altogether.
gkellogg: I'd drop them too.
shanem: I don't appreciate the concern about the potential difference between HTML5's and our own. We should continue to use our existing definitions.
… Wiki and IANA solve a non-problem.
niklasl: worried about creative commons use of license.
ivan: we previously raised with ben, as people commonly use "cc:" prefix. (not too sure, though).
… CC encourages the use of prefixes and CURIEs.
ivan: can't push through a resolution now.
… general sense is agreement, but shanem is not in favor of this.
… can't push for a resolution at the top of the hour.
niklasl: expressed questions on the mailing list.
ivan: continue discussion on the
... open issues, @href content model of URL
… <head> and <body> issues.
… replace @about with @resource in RDFa Lite
… Link Relations.
… These seem to be remaining issues. Suggest that we try to reach equilibrium on mailing list so that we can make an easy decision.
… We should publish a draft in Dec. that resolves these issues.
ivan: no meeting next week.
<MacTed> trackbot, end meeting
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) WARNING: Bad s/// command: s/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-03/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-10/ Succeeded: s/date today/time today/ Succeeded: s/defintion/definition/ Succeeded: s/apha/alpha/ Succeeded: s/:/#/ Succeeded: s/2/1/ Found Scribe: Gregg Found ScribeNick: gkellogg Default Present: Ivan, ShaneM, gkellogg, scor, MacTed, niklasl Present: Ivan ShaneM gkellogg scor MacTed niklasl Regrets: Manu Steven Found Date: 17 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/17-rdfa-minutes.html People with action items: fold manu1 WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]