RDF Web Applications Working Group Teleconference -- 17 Nov 2011

<trackbot> Date: 17 November 2011

<tomayac> sorry, i can only attend via IRC today

<ivan> agenda call

<ivan> scribe: Gregg

<ivan> scribenick: gkellogg

admin

<ivan> last meeting's minutes

Minutes accepted

Next Thursday's meeting would be on Thanksgiving in the U.S.

// Propose to cancel next meeting.

<MacTed> s/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-03/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-10/

<MacTed> (that *might* be escaped properly)

On to "low-hanging" fruit

Low hanging fruits

<ivan> ISSUE-97?

<trackbot> ISSUE-97 -- Determine if datetime should be supported in HTML5 -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/97

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

<niklasl> +1

<ivan> +1

<tomayac> +1

<scor> +1

<ShaneM> +1

<MacTed> +1

<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.

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

<ShaneM> +1

<scor> +1

<ivan> +1

<niklasl> +1

<MacTed> +1

<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

<ivan> ISSUE-113?

<trackbot> ISSUE-113 -- Add the value attribute of the HTML data element as a possible literal target for property -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/113

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 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 intended datatype?
... <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

<niklasl> +1

<scor> +1

<MacTed> +1

<tomayac> +1

<ivan> +1

<ShaneM> +1

<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].

<ivan> ISSUE-116?

<trackbot> ISSUE-116 -- Consider owl terms for vocab expansion -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/116

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> +1

<niklasl> +1

<ShaneM> +1

<ivan> RESOLVED: add owl:equivalentProperty and owl:equivalentClass to the set of terms for the vocab expansion

<tomayac> n/a

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.

<ivan> ISSUE-118?

<trackbot> ISSUE-118 -- Should we consider allowing the '/' character in a term -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/118

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> vocab=foo

<ShaneM> property='shane'

<ShaneM> vocab="foo#'

<ShaneM> foo#shane

<ShaneM> foo#123shane

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

<niklasl> +1

<ivan> +1

<scor> +1

<tomayac> +1

<MacTed> +1

<ivan> RESOLVED: allow '/' character to appear in a term, except for the first character

<ShaneM> +1

<MacTed> :-)

ivan: will commit changes on document with OWL terms. Shane, can you make this change?
... high-hanging fruit ...

link relations

<ivan> ISSUE-108?

<trackbot> ISSUE-108 -- Refine/deprecate Link relations for the RDFa 1.1 Default Profile. -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/108

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 mailing list.
... 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

- DRAFT -

RDF Web Applications Working Group Teleconference

17 Nov 2011

Attendees

Contents

admin

Low hanging fruits

link relations

Summary of Action Items

Scribe.perl diagnostic output