See also: IRC log
<trackbot> Date: 08 September 2011
<gkellogg> zakim ??P7 is me
<scribe> Scribe: Steven
<ivan> scribenick: Steven
<ivan> issue-106?
<trackbot> ISSUE-106 -- Should RDFa support the creation of ordered lists? -- open
<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/106
Ivan: Comments came in from Jeni, asking if we would have syntax for creating lists
gkellogg: this is a resurfacing of an earlier question, for merging with microdata
gkellog: Sparql makes this more
relevant
... no collection attribute, but a member attribute to reduce
syntax needed
... became too complicated with lists within lists
<gkellogg> http://www.w3.org/2010/02/rdfa/wiki/Lists#Processing_Rules_addition_with_.40member_alternative
gkellog: not sure of use case
forthat, except for covering full Turtle
... wiki shows state of play now
... for processing rules
Ivan: I looked at Greg's
approach, implemented it, giving the second
implementation
... shows it is working
... I am happy dropping my original pre-preocessing
approach
... do we want this functionality in RDFa?
... if so, do we accept this approach?
... So do we have enough evidence for the need?
gkellogg: There really has been a
need to describe an ordered list in the past
... used seq in the past, may now be obsolete
... rdf uses linked list semantics, which reduces their
expressibility
... now being addressed in RDF
... otherwise used classes from ordered list ontology
... which is verbose
... schema.org examples show use cases
... so is missing in RDFa, we need to add it
lindstream: Agree
Ivan: Does drupal miss this, Stefan?
Stefan: there are examples
... usually lists in drupal are ordered
<lindstream> Things that need lists: owl:unionOf, bibo:authorList, parts of the LD-API...
Stefan: another question - couldn't we add steps that rely on the ordering in the DOM tree?
Ivan: I think the algorithm
already does that
... Greg's syntax puts a flag on each element that has to be
added
... I propose we ask the people here what we think, and
finalise the decision on the list.
<MacTed> straw poll
Ivan: So first question - do we think we should add a list mechanism?
<gkellogg> +1
<lindstream> +1
<MacTed> +1
<scor> +1
<ivan> +1
Steven: +1
Ivan: Clear enough
... Second question: Do we use Greg's syntax?
lindstream: Basic mechanism is
good
... there are details that I am not comfortable with
... like repeating the predicate
... I need to try it out more
<lindstream> http://schema.org/docs/schemaorg.owl
<scor> gkellogg: have you looked at Toby's proposal for lists in RDFa? (I'm not familiar with it, I just recall he posted something a while ago)
lindstream: such as on Owl examples
<gkellogg> I did some time ago, and wasn't a real fan.
lindstream: but is the name 'member' suitable?
<lindstream> @listitem(of)? @inlist? @appendsto... (says what happens)
lindstream: it may not be; may be one of these:
<lindstream> inlist="owl:unionOf"
lindstream: using @inlist it could then include the predicate
Ivan: we should leaving naming to the end of the discussion
gkellogg: We still have the
uncompleted triples mechanism
... so in regards to @rel, there is no repetition of
predicate
... I also looked at @member taking a value, and it does add
some confusion
<ivan> +1 to gregg
gkellogg: having another place for a property
Ivan: I didn't try to implement it that way, but I see Greg's point
lindstream: I hadn't seen the use of a hanging member, but agree that would mean less repetition
lindream: Problem is readability;
empty attribute bugs me a bit
... it really changes how @rel and @property work
<lindstream> <li><a rel="owl:unionOf" member="" href="#ClassOne"></a></li>
Lindstream: Consider this example
<lindstream> <li><a inlist="owl:unionOf" href="#ClassOne"></a></li>
Lindstream: I'll discuss it more on the mailing list
Ivan: That's fine, we just need to make a decision quite quickly
lindstream: The member processing hint may be problematic, since it is not backwards compatible
Ivan: One radical thing to use
would be inlist with a property
... a decent way of solving this
<lindstream> <li><a inlist="owl:unionOf" rel="related" href="#ClassOne"></a></li>
lindstream: Here is a strawman
Ivan: Leave this for the mailing
list
... as for naming, I have no strong feeling. I see the
advantage of @inlist
gkellogg: I go with the
consensus
... but adding a value would make processing rules more
complicated
Ivan: OK, discuss on email
<ivan> Topic issue 104
<ivan> ISSUE-104?
<trackbot> ISSUE-104 -- Determine if RDFa should normatively state that <link> and <meta> elements are supported in flow content. -- open
<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/104
Ivan: HTML5 allows link and meta
only in the head
... XHTML2 proposed allowing them anywhere
... HTML5 microdata proposes allowing them in the body as
well.
... should we allow it too?
... I don't think we have to make the decision
... RDFa can cope with it either way
Steven: Agree. We only need
attributes, and they would work if these elements are in the
content
... but we can emulate the effect of them as well without the
elements
Lindstream: There may be a rule that the elements are only allowed in content if they have microdata attributes
<scor> ivan: how about the @rev attribute then?
<scor> we (RDFa) do add it on top of the HTML5 spec
Ivan: THis is an issue that came from Jeni via the HTML5 camp
<scor> even though it's not allowed in HTML5
<scor> I agree though @rev is an attribute and link/meta are elements
Steven: We can still add our attributes onto the elements
Lindstream: Can we reply to Jeni that for it to work we need our attributes to be acceptable on them
Ivan: Yes.
<ivan> PROPOSED: on issue 107: this is not what this wg can solve, the HTML5 WG has to allow these elements everywhere, the RDFa processing rules automatically apply
Steven: relaxing the microdata attributes requirement
<ivan> PROPOSED: on issue 107: this is not what this wg can solve, the HTML5 WG has to allow these elements everywhere by relaxing the restriction of being used with microdata attributes only; the RDFa processing rules automatically apply
+1
<ivan> +1
<gkellogg> +1
<lindstream> +1
<MacTed> +1
<ivan> RESOLVED: on issue 104: this is not what this wg can solve, the HTML5 WG has to allow these elements everywhere by relaxing the restriction of being used with microdata attributes only; the RDFa processing rules automatically apply
<scor> +!
<scor> +1
<lindstream> oh, that's 104?
<lindstream> http://www.w3.org/2010/02/rdfa/track/issues/104
<scribe> ACTION: gkellogg to write a reply to Jeni about issue 104, in line with the resolution [recorded in http://www.w3.org/2011/09/08-rdfa-minutes.html#action01]
<trackbot> Sorry, couldn't find user - gkellogg
<scribe> ACTION: gkelloggg to write a reply to Jeni about issue 104, in line with the resolution [recorded in http://www.w3.org/2011/09/08-rdfa-minutes.html#action02]
<trackbot> Created ACTION-93 - Write a reply to Jeni about issue 104, in line with the resolution [on Gregg Kellogg - due 2011-09-15].
<ivan> ISSUE-107?
<trackbot> ISSUE-107 -- Determine if @src attribute should be viewed in the object position instead of the subject position. -- open
<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/107
Ivan: This would be an
incompatible change
... Gregg you have a problem with this?
Gkellogg: I see examples of this
causing problems
... I believe it was added for the use case of license
information for images
... which I have never seen
... in the wild
... so not clear how much the backwards incompatibility would
be a problem
Ivan: I feel your pain
Stefan: We do use this @src as a
subject in some cases
... but I do support the change
... we use it in combination with @typeof
Steven: I opposed this originally, but CC may use it a lot; I was overruled. I think we need to consider the existing users before we remove it
<lindstream> <img rel="depiction" src="me.jpg"/> vs. <img rel="depicts" src="me.jpg" resource="#me"/>
lindstream: Consider this example
<lindstream> <img rel="depiction" src="me.jpg"/> creates no triple today
<lindstream> <img rel="depiction" src="me.jpg"/> would create $currentSubject :depiction <me.jpg>
Ivan: Let's take a straw
poll
... are we sympathetic to @src behaving like @href
-1
<ivan> +1
<gkellogg> +1
<scor> +1
<lindstream> +1 with reservation for me not remembering Ben Adida's needs
<MacTed> +0
[ADJOURN]
<ivan> trackbot, end telcon
<ivan> steven, manu or I will take care of the minutes cleanup
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) Succeeded: s/log/logg/ Succeeded: s/ism/ism?/ Succeeded: s/questionn/question/ Succeeded: s/h:/:/ Succeeded: s/+0/+1/ Succeeded: s/../.../ Succeeded: s/woul/would/ Succeeded: s/k// Succeeded: s/TH/Th/ Succeeded: s/Jenni/Jeni/ Succeeded: s/Jenni/Jeni/G Succeeded: s/autoamtically/automatically/ Succeeded: s/+1// Succeeded: s/autimatically/automatically/ Succeeded: s/autimatically/automatically/ Succeeded: s/107/104/ Succeeded: s/Topic/Topic:/ Succeeded: s/Gkellog/gkellogg/g Succeeded: s/SH/Sh/ Found Scribe: Steven Found ScribeNick: Steven Default Present: lindstream, Ivan, gkellogg, MacTed, Steven, +1.781.866.aaaa, scor Present: lindstream Ivan gkellogg MacTed Steven +1.781.866.aaaa scor Regrets: Manu Shane Found Date: 08 Sep 2011 Guessing minutes URL: http://www.w3.org/2011/09/08-rdfa-minutes.html People with action items: gkellogg gkelloggg[End of scribe.perl diagnostic output]