W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > October 2005

meeting record: 2005-10-25 RDF-in-XHTML TF telecon

From: Ralph R. Swick <swick@w3.org>
Date: Tue, 25 Oct 2005 11:59:58 -0400
Message-Id: <>
To: public-rdf-in-xhtml-tf@w3.org

The [1]record of today's telecon is now available for review.  A text snapshot
of  $Revision: 1.2 $ of $Date: 2005/10/25 15:55:12 $ is included below.

   [1] http://www.w3.org/2005/10/25-swbp-minutes.html



25 Oct 2005


      [2] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/0051.html

   See also: [3]IRC log

      [3] http://www.w3.org/2005/10/25-swbp-irc


          Ben Adida, Ralph Swick, Mark Birbeck, Jeremy Carroll

          Steven Pemberton




      [4] http://www.w3.org/2005/10/18-swbp-minutes.html


     * Topics
          + New CURIE and RDF/A drafts
     * Summary of Action Items


New CURIE and RDF/A drafts

   -> [7]Drafts of CURIE note, RDF/A spec, and Examples [22]

      [7] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/0043.html
     [22] http://www.w3.org/2005/07/26-swbp-minutes.html#action06

   Ben: those who've not read the documents produced over the weekend are
   appropriately chastized

   Ben: the [8]2005-10-21 RDF/A syntax document does not use '[...]'
   around every QName; e.g. in REL

      [8] http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-spec

   Mark: that's ok until we decide the CURIE issue
   ... '[]' will only be required in cases of ambiguity between QName and
   URI values

   Ben: so if we're working in the default XHTML namespace, then
   rel='next' should be interpreted as being in the default XHTML

   Jeremy: there are two ways of reading unprefixed QNames
   ... rel='next' can be interpreted as 'next' in the default (i.e.
   XHTML) namespace
   ... but the other way, as in unprefixed attributes, reads as the
   unprefixed attribute is in no namespace rather than in a default
   ... I suggest that rel='next' interpret 'next' as being in the default

   Mark: the two ways are to read as relative to xml:base or as relative
   to the XML namespace structure

   RESOLUTION: CURIEs read as relative to the XML namespace tree

   Mark: the predicates are changing anyway, so we're really talking
   about xh2:next

   Ben: in current HTML, it would be nice if the same syntax (rel='next')
   had a reasonable interpretation

   Jeremy: in XHTML1 rel='next' has no meaning in triples
   ... meaning in triples is new to XHTML2
   ... pragmatically it doesn't matter what namespace we put 'next' in
   ... we don't have to refer to the XHTML1 definition except as the
   XHTML2 definition may incorporate parts of XHTML1 definition

   Jeremy: we don't need to treat all the RELs the same; we can enumerate
   some values for one namespace, other values for a different namespace,
   and say what happens to all other values
   ... legacy considerations need not corrupt the design; we can treat
   them specially

   <Zakim> RalphS, you wanted to ask if the 'E' denotes anything in

   Mark: I added the 'E' to CURIE to distinguish this work from an old
   proposal 'canonical URI' that shows up in searches
   ... also, I liked the connection to the Curie family
   ... an advantage of rel='[...]' is that we can have full URIs when
   ... so we gain an easy way to make statements about predicates

   Ben: it's a quick way to include a triple without declaring namespaces

   Jeremy: I suggest we list the XHTML1 cases as special cases and go
   with CURIE in REL

   Mark: when we have defined the formal triples from XHTML2, much of the
   syntax works in XHTML1
   ... though in an XHTML2 document we'd generate xh2:next and in an
   XHTML1 document [the interpretation would be] xh1:next

   Jeremy: we can define the special cases to generate what we want; i.e.

   Ralph Jeremy mentioned the ability to enumerate a group of legacy

   Jeremy: 'next' should be supported for legacy reasons but a page that
   is explicitly XHTML2 should use '[next]'

   Mark: yes, if you want the triple use '[ ]'
   ... if you're only interested in browser behavior, don't write '[ ]'

   Ralph: I strongly argue against an approach that says to do different
   things if you're only interested in browser behavior versus declaring
   some semantics
   ... that is, 'next' means only behavior and '[next]' means

   Mark: one solution would be to define currentdocument:next as the same
   as xh2:next

   Jeremy: I'd rather this be a syntactic patch

   Ben: solution 1 is CURIE so rel='next' is interpreted as xh2:next (and
   ... solution 2 is to require '[ ]'
   ... solution 3 is to spec that 'next' is interpreted within the parser
   as '[ ]'; i.e. all the legacies are CURIE
   ... under solution 3 document authors have to be careful if they
   change the default namespace

   Mark: other languages, such as SVG, take pieces from XHTML

   Jeremy: could also tune the CURIE definition more to distinguish when
   a '/' is present or not

   Mark: there might be cases where having a URI rather than a CURIE
   might be advantageous but I think a generic solution will be better

   Jeremy: the RDF/XML experience is that supporting different ways to
   say the same thing is confusing
   ... i.e. different ways to define a predicate versus use a predicate
   slows deployment

   ACTION: Ben add "should rel, rev, and properties predicate be CURIE or
   CURIE/URI?" to issues list with a summary of the current status
   [recorded in http://www.w3.org/2005/10/25-swbp-minutes.html#action01]

   <benadida> [10]current-issues#src

     [10] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#src

   Ben: I've added 5 more issues that arose while writing the new RDF/A
   syntax document
   ... [11]using SRC attribute as subject

     [11] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#src

   -> [12]Applying Metadata to the src URI

     [12] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#src

   <benadida> <img src="photo1.jpg">
   <benadida> <link rel="cc:license" href="..." />
   <benadida> </img>

   Mark: in XHTML2 you can use src= anywhere; it's like transclusion
   ... the element content is used only if you fail to read the content
   at that URI
   ... so Ben's proposal for issue 6 means you could include metadata for
   the transcluded content

   Jeremy: transclusion is a defaulting mechanism rather than a failure
   ... i.e. the element content can be interpreted as 'additional to' the
   image rather than 'instead of' the image

   Mark: not sure
   ... e.g. one use case is to nest text inside image inside video
   ... where the intent was to use the image if the video failed and use
   the text if both failed

   Jeremy: but the user can configure the browser to, for example, show
   the image with the text popping up when the cursor was over the image
   and show the video when you click on the image

   Mark: there has been talk about treating this as a kind of conditional
   ... considering the impact on the DOM

   Jeremy: could have <p src='...'> and have metadata both in the
   document containing the <p> and the src document

   Mark: XInclude is expected to happen before the DOM is built; once you
   have the DOM you're not aware the XInclude has taken place

   ACTION: Mark report on the status of src attribute definition
   [recorded in http://www.w3.org/2005/10/25-swbp-minutes.html#action02]

   Ben Review others items on the [14]issues list

     [14] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues

   Mark: what else is critical before Thursday hand-over?

   Ben: take a look at the [15]class attribute issue
   ... get me feedback by the end of the day on Thursday and I'll send
   Guus a new draft on Friday, with apologies for being 12 hours late

     [15] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues#class

   Jeremy: we want feedback from the f2f on whether this will be
   acceptable to the Semantic Web community if it were adopted by the
   ... so as long as the issues list is not too long we should be able to
   provide adequate guidance to the HTML WG
   ... we don't have to decide all the minor issues but we do have to
   document them

   Mark: the real examples will help a lot

   ACTION: Mark send Ben the XML version of the new RDF/A draft
   [recorded in http://www.w3.org/2005/10/25-swbp-minutes.html#action03]

     [16] http://www.w3.org/2005/10/25-swbp-minutes.html#action03

   next meeting: 1 Nov, regrets from Jeremy


Summary of Action Items

   [NEW] ACTION: Ben add "should rel, rev, and properties predicate be
   CURIE or CURIE/URI?" to issues list with a summary of the current
   status [recorded in

   [NEW] ACTION: Mark report on the status of src attribute definition
   [recorded in http://www.w3.org/2005/10/25-swbp-minutes.html#action02]

   [NEW] ACTION: Mark send Ben the XML version of the new RDF/A draft
   [recorded in http://www.w3.org/2005/10/25-swbp-minutes.html#action03]

   [PENDING] ACTION: Steven track and report on Role discussion before
   next Tuesday [recorded in

   [PENDING] ACTION: Ben to put together the "ACID" test for XHTML2 RDF/A
   [recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action02]

   [PENDING] ACTION: Mark and Ben to check edge cases of inheritance in
   RDF/A [recorded in

   [PENDING] ACTION: Ralph and Ben to augment the issues list
   [recorded in http://www.w3.org/2005/09/27-swbp-irc#T14-30-04]

   [DONE] ACTION: Ben add repeating URI in IMG case to issues list
   [recorded in http://www.w3.org/2005/10/18-swbp-minutes.html#action03]

   [DONE] ACTION: Ben put notes in the Web from Boston discussion with
   Mark [recorded in

   [DONE] ACTION: Mark write CURI specification by 10 Oct
   [recorded in http://www.w3.org/2005/10/04-swbp-minutes.html#action02]

   [End of minutes]

   Change Log:
$Log: 25-swbp-minutes.html,v $
Revision 1.2  2005/10/25 15:55:12  swick
Cleanup for publication


    $Revision: 1.2 $ of $Date: 2005/10/25 15:55:12 $
Received on Tuesday, 25 October 2005 16:00:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:19 UTC