See also: IRC log, previous 2007-09-27
-> http://www.w3.org/2007/09/27-rdfa-minutes.html#ActionSummary
<scribe> ACTION: [NEW] Ben to add implementations page to RDFa.info [recorded in http://www.w3.org/2007/09/27-rdfa-minutes.html#action08] [DONE]
Ben: I started to move stuff
<scribe> ACTION: [NEW] Ben to remind the WG reviewers about review for FtF [recorded in http://www.w3.org/2007/09/27-rdfa-minutes.html#action07] [DONE]
<scribe> ACTION: [NEW] Shane to send a link to new editor's draft to Ben [recorded in http://www.w3.org/2007/09/27-rdfa-minutes.html#action10] [DONE]
Ben: I fwd link to SWD
<scribe> ACTION: [PENDING] Ben to look into Science Commons use case [recorded in http://www.w3.org/2006/12/11-htmltf-minutes.html#action04] [CONTINUES]
<scribe> ACTION: [PENDING] Ben, Mark, Elias, and other implementors to add xml:lang support [recorded in http://www.w3.org/2007/08/23-rdfa-minutes.html#action11] [DONE]
<benadida> ACTION: Ben to add status of various implementations on rdfa.info [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action06]
<scribe> ACTION: [PENDING] Michael look for a more semantically correct predicate for tests 42-45 [recorded in http://www.w3.org/2007/09/06-rdfa-minutes.html#action14] [DONE]
-> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0038.html report
<Steven> I edited the cruft from last week's minutes
Ben: Change the TC accordingly
<scribe> ACTION: [PENDING] Michael make sure to confirm a design for checking that the ASK SPARQL queries evaluate (yes/no) [recorded in http://www.w3.org/2007/09/06-rdfa-minutes.html#action07] [CONTINUES]
<scribe> ACTION: [PENDING] Michael to create "Microformats done right -- unambiguous taxonomies via RDF" on the wiki [recorded in http://www.w3.org/2007/08/23-rdfa-minutes.html#action06] [CONTINUES]
-> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0001 Ivan's TC proposal
Michael: I have looked them over and they appear to be reasonable
Ralph: I encouraged Ivan to propose these so we had test cases that document our decision w.r.t. subject of @instanceof
Michael: I'm only being cautious
about the process -- want the TF to discuss adding them before
we review them
... Fabien's proposed test cases are more complex
Mark: I'd prefer to review the proposed tests after Michael has uploaded them to the test suite archive
<scribe> ACTION: Michael add Ivan's proposed tests to the test suite [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action10]
Michael: Fabien's proposed tests are not atomic; they're quite complex
Shane: do we have a process for more complex cases?
<mhausenblas> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0069.html
Michael: the tests are nice but complex
<mhausenblas> http://sw.joanneum.at/rdfa/rdfadebug/index.php
Ralph: Fabien's proposed 0046 with multiple space-separated properties seems the shorted possible test; what's the problem?
<scribe> ACTION: Michael add Fabien's proposed tests to the test suite archive [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action12]
Ben: Let us review the new TC (Fabien's and Ivan's) together next time
Ben: AFAIU Primer is a note and Syntax goes REC-Track
Steven: Second that
... why having a rec on non-normative stuff
Ben: Tom asked for SWD regarding this issue
Ralph: Most SW TR package have
this
... REC Track has a precise definition
[[http://www.w3.org/2005/10/Process-20051014/tr.html]]
scribe: so Steven is right in saying that there may be more work with it
Steven: May risk that the Primer may hold up the whole package
Ben: Just want to make sure that it si no problem for SWD WG
Ralph: eg GRDDL Primer is a
note
... so might be no reason to push the Primer through REC
Track
Ben: So we have Primer, Syntax,
UC, TC
... Syntax goes REC Track
... Primer and UC are notes
<benadida> PROPOSE to bring syntax as rec track, primer and use cases as notes, and test cases as supporting doc for syntax.
+1
<benadida> RESOLVED
<benadida> RESOLUTION: to bring syntax as rec track, primer and use cases as notes, and test cases as supporting doc for syntax.
Ben: Proposed the HTML URI
Mark: We seem to have agreed on a
pre-processing step
... takes out null values
scribe: I'd like to see them put in a kind of general space
Ben: The goal is that for people
that use DC conventions
... which are not RDFa compatible, to make them work
... ignoring non-prefixed
... so I do favour the pre-processing
Mark: Agree
Manu: What does it mean semantically
Mark: When undefined, certain use cases might be problematic
Ben: When writing the RDFa
extractor - what is the instruction for non-prefixed
... we should focus the discussion
... identify what is part of the RDFa spec
Mark: Right - look into it
Ben: It is ok to say that @rel
only excepts prefixed values
... @instanceof does not have this legacy problems
Ralph: For the record. What is the proposal?
Ben: To ignore unprefixed
@rels
... after pre-processing
<RalphS> Mark: the preprocessor will expand the reserved words in the HTML namespace
<RalphS> ... a processor might also have a DC preprocessing step
Ben: Proposal that RDFa defines a
generic pre-processing step
... the pre-processing turns known attributes into prefixed
ones
<RalphS> Steven: for @rel and @property both?
Ben: the actual processing ignores all unprefixed ones
<RalphS> Ben: @property is one we've added
<RalphS> Mark: it would be nice to be able to use <span xmlns="...foaf..." rel="knows" /> shorthand
<RalphS> Ben: but that modifies the host language namespace
Ben: being open for other pre-processing steps
RalphS: So @rel/@rev unprefixed
after pre-processing are ignored?
... we should be careful wrt the HTML host language
... reserved words are expanded
... so RDFa extractors can rely on that
Ralph: To state something
undefined is problematic
... regarding common usage
Ben: For example take profile in the head
<RalphS> Ralph: saying "undefined" for a feature that users may come to depend on in some implementation will lead to interoperability problems.
Ben: so we should not overwrite it
Mark: There are two end of the
scale
... just to ensure to make things available
... Might be a solution to put these triple into a non-default
graph
Ralph: Layering issues,
here
... whatever happens in the pre-processing step is up to the
application
Mark: range from ignored to undefined
Ralph: ignored means that pre-processing should have been done else
Ben: Towards a proposal ...
... work with buckets
... define which goes into what
Manu: Fine when application-specific pre-processing is done that generates extra triples
<RalphS> Manu: suggest handling unprefixed values in the same way as "extra triples" -- just say that if these generate triples, they are not in the default graph
Mark: Shouldn't we be more
specific
... hard to tell if a document is valid, etc.
Ben: IMHO it is not a RDFa extractor issue
Mark: It is confusing not to state it explicitely
<RalphS> Ben: if an application generates extra triples, whether they're from unprefixed @rel values or not, they get handled the same way. Don't need to restate this multiple times.
Mark: Just as we defined it at CURIE's
Ben: Enable developer to extract more triples
in a defined way
Ben: We seem to have a
resolution
... non-prefixed @rel/@rev do not generate triples
<RalphS> ("in the default graph")
<benadida> PROPOSE: @rel and @rev values that are non-prefixed and not in the XHTML reserved words do not generate triples in the default graph
<RalphS> +1
+1
<msporny> +1
<Steven> ok
Mark: For consistency: @property the same?
<Steven> ok with me
Ben: Separate issue
<Steven> Consistency is important
Ralph: The issue with @rel/@rev is that there is already a usage
<Steven> and @property is new
<RalphS> Mark: property="foo" will, by CURIE rules, go into the 'vocab' (i.e. non-default) graph
<RalphS> ... must write property=":foo" to use the in-scope namespace
<RalphS> ... according to the current Syntax document
<markbirbeck> http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070927/#s_curies
Ben: Need to continue this discussion, based on the goal
Mark: Acknowledge legacy usage of @rel values
<RalphS> [I'm interested in the new input from Manu that having different rules for @rel values vs. @property values will be overly confusing]
<benadida> ACTION: Ben to bring non-prefixed @rel issue to email [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action13]
<RalphS> [I really want @property="foo" to use the in-scope namespace, but I'm interested in more discussion especially from Manu]