SWBPD RDF-in-XHTML TF

New CURIE and RDF/A drafts

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

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

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

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 namespace

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 namespace
... I suggest that rel='next' interpret 'next' as being in the default namespace

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 'CURIE'

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 useful
... 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. xh2:next

Ralph Jeremy mentioned the ability to enumerate a group of legacy options.

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 behavior+semantics

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 xh1:next)
... 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> 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
... using SRC attribute as subject

-> Applying Metadata to the src URI

<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 mechanism
... 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 XInclude
... 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 issues list

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

Ben: take a look at the 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

Jeremy: we want feedback from the f2f on whether this will be acceptable to the Semantic Web community if it were adopted by the HTML WG
... 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]

next meeting: 1 Nov, regrets from Jeremy

[adjourned]

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