RDFa Working Group Teleconference -- 13 Jan 2011

<trackbot> Date: 13 January 2011

<webr3> scribenick: Nathan

<webr3> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0052.html

<ShaneM> where is sip access to zzakim?

<ShaneM> 'cause I can't get dialin to work today

<ShaneM> never mind...

<webr3> manu: let's go ahead and start, any additions / changes to the agenda?

ISSUE-60: XMLLiteral context preservation

<manu> http://www.w3.org/2010/02/rdfa/track/issues/60

<webr3> manu: there are a number of things we can do to address this, some complicated

<webr3> ... all we need to do is preserve values in xmlns: and in no particular order, is that correct?

<ShaneM> The text currently reads:

<ShaneM> In order to maintain maximum portability of this literal, any children of the current node that are elements must have the current in scope profiles, default vocabulary, prefix mappings, and XML namespace declarations (if any) declared on the serialized element using their respective attributes. Since the child element node could also declare new prefix mappings or XML namespaces, t

<webr3> ivan: in my implementation, I can produce all the xml statements, are definitions from within a prefix allowed?

<webr3> manu: some @prefix values may override xmlns values

<webr3> ivan: its really quite simple because all of this goes in to a single table

<webr3> ivan: if i forget about the xmlliteral then I can do that, perfectly valid and works

<webr3> manu: they need to be kept seperate for case insensitive searching

<webr3> shane: you can't put everything in lowercase

<webr3> shane: lets focus, i think it makes the msot sense to tell people to maintain different tables, regardless - did we agree that we weren't going to do what is currently in the draft

<webr3> manu: i thought we decided against the text in the draft

<webr3> ivan: i believe the core of what i said is true, it forces me to keep things seperate that at some point are not seperated

<manu> This is the issue: xmlns:FOObar vs xmlns:foobar

<manu> prefix="FOObar: ..."

<webr3> manu: we need to keep these seperate because prefixes defined by xmlns are case insensitive, prefixes in @prefix are case sensitive

<webr3> shane: why? (are they case sensitive)

<manu> xmlns:Agent="..."

<webr3> shane: they should not be case sensitive in @prefix

<manu> term: "agent" => ...

<webr3> ivan: they should not be case sensitive in @prefix

<manu> prefix="Agent: ... , agent: ..."

<webr3> ivan: prefix and term are different

<webr3> manu: there's another issue which means they are not so different

<manu> Agent => Class, agent => property

<webr3> ivan: term and prefixes are different

<webr3> shane: prefixes are only prefixes if they are followed by a colon

<webr3> manu: mark and I believe prefixes are valid without a colon, used as tokens

<manu> prefix="Agent: ... , agent: ..."

<ShaneM> The text current reads: Otherwise, if a CURIE consists of a non-empty prefix and reference, and if there is an in-scope mapping for prefix (when compared case-insensitively), then the URI is created by using that mapping, and concatenating it with the reference.

<webr3> ivan: I worry that we may over-complicate rdfa

<ShaneM> (to be clear, the xmlns syntax is NOT case insensitive - stupid browser implementations are)

<webr3> ivan: prefix and xmlns should behave the same

<manu> prefix="Agent: ... , agEnT: ..."

<webr3> ivan: yes case insensitive

<webr3> shane: it leads to more room for error

<webr3> general agreement

<webr3> manu: would we then have to encode all @prefix and @xmlns in XMLLiterals

<webr3> ivan: we should not go out of our way for an infrequently used feature

<webr3> manu: Drupal do this, it is quite common, 30k sites++

<webr3> ivan: if we map prefixes on to xmlns in the literals then it will all work

<webr3> manu: seems a little strange

<webr3> shane: i thought you were arguing that we sould only put xmlns on xmlliterals

<webr3> manu: true

<webr3> shane: doesn't that conflict w/ drupal use case

<webr3> manu: are we making a decision to not allow deep processing of XMLLiterals

<webr3> correct: google reference above should be drupal

<webr3> manu: we can say 1: the only things that get preserved are xmlns statements (are prefixes included)

<webr3> manu: or 2: we do not support deep processing of xmlliteral (w/ terms, profiles etc too)

<Steven> s/correct: 01google reference above should be drupal//

<webr3> ivan: it complicates implementations in a way I'm not happy about, but..

<webr3> manu: if we were to preserve everything it would complicate things even more

<webr3> ivan: i can live with that (2)

<Steven> s/correct: g01oogle reference above should be drupal//

<webr3> ivan: xmlns are pushed out to XMLLiteral and nothing else

<webr3> manu: does that include things defined in @prefix or not?

<webr3> manu: any objections?

<webr3> manu: let's push it out to the list rather than strawpoll

<webr3> ivan: we have to answer Gregg Kellogg w/ proposal and ask if they are happy with the resolution, will be in tracker

ISSUE-62: @prefix processing order

<webr3> no objections heard

<manu> http://www.w3.org/2010/02/rdfa/track/issues/62

<manu> @prefix="a: http://a.b a: http://c.d"

<manu> will end in a->http://c.d

<webr3> manu: order of prefix evaluation?

<webr3> shane: prefixes are ordered from left to right, in the sequence, section 7.5 ..

<webr3> ivan: need to specify this, no preference for which order

<webr3> ivan: problem I have is that we have decided that the processing order of @profile is specified, so @prefix should probably be defined too, and match @profile

<webr3> shane: @profile is age old and should be defined as @profile always has been - prefix does not have to be the same

<webr3> ivan: within the same specification, they should be ordered the same to save errors

<webr3> manu: i agree

<webr3> manu: seems like last defined should win in presendence ( @prefix="a: http://a.b a: http://c.d" )

<webr3> manu: where does it say in html4 how @profile values are given presedence

<webr3> shane: common usage.. comes from css? some comment?

<webr3> ivan: i think it has something to do with css

<ShaneM> html4 says: profile = uri [CT] This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.

<webr3> manu: people are used to last declared wins

<webr3> ivan: i agree

<webr3> manu: shall we propose both profile and prefix are declared left to right, and last declared wins.

<manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0134.html

<webr3> ivan: it's more natural to say, processed from left to right, and has to be clearly documented

<ShaneM> rdfa core says: If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.

<manu> Toby explained that the XMDP approach is to say that profiles appearing first in the list are /more significant/ than those coming later. That already points to a way of conceptualising this that is 'left-to-right'.

<Steven> I propose we say "in document order" and not "left-to-right"

<webr3> manu: i don't mind..

<webr3> steven: "in document order" is what we say

<webr3> shane: or "beginning to end" because languages have different directions

<webr3> ivan: commenter is happy

<webr3> all on call are happy with defining prefix and profile should follow in the same order, preference going to in document order

<webr3> manu: no objections?

<webr3> ivan: add a note to say right-to-left is more complicated than left-to-right

<manu> Implementation experience states that processing right to left is far more complicated than left-to-right

ISSUE-64: Add rel=describedby to the XHTML vocab

<manu> http://www.w3.org/2010/02/rdfa/track/issues/64

<webr3> manu: i think that's fine

<webr3> ivan: there was a huge discussion about this on public lists, and sem web community "discovered" described by and that it should be used

<webr3> ivan: we may have a seperate question about default profile - still undecided w/ an issue..

<webr3> ivan: i think we decided we need a profile, not what it will contain

<webr3> manu: yes issues are how do we decided what goes in, how it changes etc etc

<webr3> ivan: I raised that because it would have to be in both profiles (xhtml and html)

<manu> ZZZZ ISSUE-62 overturns decision made in ISSUE-23

<webr3> manu: everyone okay with adding?

<webr3> everyone: yes, good idea

<webr3> manu: any objections

<webr3> none heard..

ISSUE-65: Michael Hausenblas' LC Comments

<webr3> http://www.w3.org/2010/02/rdfa/track/issues/65

<manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0025.html

<ShaneM> suddenly it is very very quiet

<Steven> I can hear you too

<webr3> ivan: it looks like Michaels comments are editorial

<ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/att-0031/RDFa_Object_Resolution.pdf

<webr3> ivan: Michael suggests a diagram, I've sketched one out

<webr3> ivan: shane do you think this is something we should use, or will it over-complicate the document?

<webr3> shane: still unsure.. let's discuss as it's editorial

<webr3> ivan: agreement

<webr3> ivan: can you all go through the diagram to double check

<webr3> consensus: all editorial issues, make a decision about the diagram and add + respond to Michael

<ivan> new charter

<manu> Charter looks good AFAICT

<ivan> maybe

<ivan> I came up with the name, i would be happy to see alternatives

<manu> (and specifically state that it deals w/ RDF in the charter)

<ivan> structured data is so vague to me, we would get all the xml activity on our back

<webr3> YARDF?

<ivan> :-)

<webr3> piratey..

<ivan> so putting a stake in the ground on RDF in the working group name is probably a good idea

<Benjamin> that's good :)

<manu> What about RDF API WG?

<ivan> then the RDFa part goes down the drain

<manu> True, but they'll be in LC in a few months, right?

<manu> we can informally call ourselves the RDFa WG until that happens, then change to the new WG name?

<webr3> WebRDF WG? (that'd go down well)

<manu> ooh

<manu> I do like that

<manu> What about WebRDF WG, Ivan?

<manu> (it's a bit redundant, but I don't care much about that)

<ivan> WebRDF WG... yeah, maybe,

<ivan> ... doesn't that suggest too much?

<ivan> ... maybe not...

<ivan> the RDF API WG is not really good for the lack of RDFa; yes, it is in LC in a few month, but the group has to go through the whole rec line

<ivan> so that is not good

<ivan> WebRDF WG... I will raise it with the team, too

<webr3> general comment about sip: noted the new nexus phone from google has built in sip support

<ivan> I have an iphone 4, and pretty happy with it...

<webr3> ivan, webrdf may be a good name to save if linked data protocol ever gets standardized (which i personally think should happen asap)

<ivan> the problem with webrdf is that it suggests RDF was not on the web until now...

<webr3> does that matter?

<ivan> well, it is all about imaging, isn't it?

<ivan> anyway, I forwarded it to the team, it might be better than the current name anyway

<ivan> so bye, see you around tomorrow

<webr3> cool - cya & enjoy :)

<Benjamin> bye

<webr3> scribenick: webr3

- DRAFT -

RDFa Working Group Teleconference

13 Jan 2011

Attendees

Contents

ISSUE-60: XMLLiteral context preservation

ISSUE-62: @prefix processing order

ISSUE-64: Add rel=describedby to the XHTML vocab

ISSUE-65: Michael Hausenblas' LC Comments

Summary of Action Items

Scribe.perl diagnostic output