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

meeting record: 2009-07-16 RDF-in-XHTML Task Force telecon

From: Ralph R. Swick <swick@w3.org>
Date: Mon, 20 Jul 2009 14:46:19 -0400
Message-Id: <5.1.0.14.2.20090720144334.03bd4548@127.0.0.1>
To: public-rdf-in-xhtml-tf@w3.org
Cc: public-swd-wg@w3.org
The minutes of last week's RDF-in-XHTML Task Force telecon
are now available as

  http://www.w3.org/2009/07/16-rdfa-minutes

Thanks once again to Manu for scribing and sending me the cleaned
version very quickly, and apologies once again for not posting these
to the Web shortly after receiving them from him.

A text snapshot follows:

----

                       RDFa in XHTML Task Force

16 Jul 2009

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0085.html

   See also: [3]IRC log, previous:
   [4]http://www.w3.org/2009/07/09-rdfa-minutes.html

      [3] http://www.w3.org/2009/07/16-rdfa-irc
      [4] http://www.w3.org/2009/07/09-rdfa-minutes.html

Attendees

   Present
          Steven Pemberton, Shane McCarron, Ben Adida, Mark Birbeck,
          Manu Sporny, Ralph Swick

   Regrets
          Michael Hausenblas

   Chair
          Ben Adida

   Scribe
          Manu Sporny

Contents

     * Topics
         1. Action Items
         2. Token @proposal
     * Summary of Action Items
     _____________________________________________________

   ShaneM: What about publishing the RDFa errata from the last meeting?

   benadida: Yes, we should talk about that.
   ... We should have a discussion about xmlns
   ... It should be a different discussion... keep the topics separated

   <ShaneM> <li>Section 4.1. Document Conformance - In the future it is

   <ShaneM> possible that RDFa will also be defined in the context of
   HTML.

   <ShaneM> Consequently document authors SHOULD use lower-case prefix
   names

   <ShaneM> in order to be compatible with current and potential future

   <ShaneM> processors.

   <ShaneM> </li>

   Manu: I think we learned something important about xmlns in HTML5
   yesterday

   benadida: Is that the errata?

   ShaneM: Yes

   Manu: +1, that looks good.

   <Steven> +1

   <benadida> +1

   <markbirbeck> +1

   <Ralph> +1
   RESOLVED: to publish the above errata on lowercase prefix names
   benadida: Good that HTML5+RDFa went out
   ... I think Sam thought we were trying to do something that we
   weren't with RDFa IG.

   <ShaneM> Errata is updated at
   [9]http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/

      [9] http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/

   benadida: But it's nice that RDFa IG is supported.

   Ralph: There were misunderstandings on both sides.

   benadida: Still concerned that HTML WG and WHAT WG are seen as two
   separate entities.

Action Items

   <scribe> ACTION: Ben to author wiki page with charter template for
   RDFa IG. Manu to provide support where needed. [recorded in
   [10]http://www.w3.org/2009/05/28-rdfa-minutes.html#action10]
   [CONTINUES]

     [10] http://www.w3.org/2009/05/28-rdfa-minutes.html#action10

   <scribe> ACTION: Ben to prepare "how to write RDFa" screencast with
   fragment parser [recorded in
   [11]http://www.w3.org/2009/06/11-rdfa-minutes.html#action05] MOVED
   TO WIKI]

     [11] http://www.w3.org/2009/06/11-rdfa-minutes.html#action05

   <scribe> ACTION: Mark create base wizard suitable for cloning
   [recorded in
   [12]http://www.w3.org/2008/09/11-rdfa-minutes.html#action12] MOVED
   TO WIKI]

     [12] http://www.w3.org/2008/09/11-rdfa-minutes.html#action12

   <scribe> ACTION: Mark write foaf examples for wiki [recorded in
   [13]http://www.w3.org/2008/09/11-rdfa-minutes.html#action13] MOVED
   TO WIKI]

     [13] http://www.w3.org/2008/09/11-rdfa-minutes.html#action13

   markbirbeck: We should create a wishlist on the rdfa.info/wiki site

   benadida: Yes, sounds good.

   <scribe> ACTION: Ralph make a request for an RDFa issue tracker
   instance [recorded in
   [14]http://www.w3.org/2009/05/28-rdfa-minutes.html#action11] MOVED
   TO WIKI]

     [14] http://www.w3.org/2009/05/28-rdfa-minutes.html#action11

   Ralph: There can only be one tracker instance per WG

   benadida: Technical constraint?

   Ralph: If we move forward with RDFa IG, there will be a tracker
   instance there.
   ... We can share SWD tracker for now and move data over

   <scribe> ACTION: Ralph think about RSS+RDFa [recorded in
   [15]http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]008/09/1
   1-rdfa-minutes.html#action15] [MOVED TO WIKI]

     [15] http://www.w3.org/2008/09/11-rdfa-minutes.html#action15

   <Ralph> [16]last week's minutes

     [16] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0104.html

Token @proposal

   benadida: I think we agree that the main goal of the @token proposal
   is to make RDFa markup simpler and more Microformats-like.

   markbirbeck: That makes it sound like it makes it more for the
   beginner author...

   ShaneM: Dynamically extending collection of reserved words is also
   important.

   benadida: So you can use unprefixed values easily?
   ... What you said Shane, would rule out things like rel=":name",
   with @token we'd be able to do rel="name"

   <benadida> property=":name"

   benadida: That wouldn't quite fit your use case... right?

   <markbirbeck>
   [17]http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-
   the-semantic-web

     [17] http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web

   markbirbeck: If you do rel="name:" we already have that facility.

   benadida: Just trying to clarify the problem we're trying to solve.

   markbirbeck: We can already dynamically assign the prefix tokens...

   benadida: If we go the route of "as simple as Microformats", ":name"
   doesn't necessarily work.
   ... at least it may not be as simple as we want it.
   ... Currently, rel="name" isn't supported and could be via a minor
   tweak.
   ... Any other points?
   ... Here's my concern with the @token proposal.
   ... It's basically saying that there are some tokens you can find at
   URL X.
   ... By saying something like this:

   <benadida> <div token="{url}">

   <benadida> </div>

   benadida: Everything within that DIV have rules that expand tokens.

   markbirbeck: @token is merely a new proposed name for xmlns:
   ... It's exactly the same as @prefix before.

   markbirbeck: The bit you're talking about is the @profile attribute.

   markbirbeck: I'm not the only one proposing that @profile should be
   used.
   ... The concensus seems to be that @profile is the way to get
   external documents.

   benadida: How can I say name is foaf:name?

   <markbirbeck> <html

   <markbirbeck> xmlns:Agent="[18]http://purl.org/dc/terms/Agent"

     [18] http://purl.org/dc/terms/Agent

   <markbirbeck> xmlns:Person="[19]http://xmlns.com/foaf/0.1/Person"

     [19] http://xmlns.com/foaf/0.1/Person

   <markbirbeck> xmlns:title="[20]http://xmlns.com/foaf/0.1/title"

     [20] http://xmlns.com/foaf/0.1/title

   <markbirbeck> xmlns:fn="[21]http://xmlns.com/foaf/0.1/name"

     [21] http://xmlns.com/foaf/0.1/name

   <markbirbeck> >

   <markbirbeck> <div

   <markbirbeck> about="[22]http://www.ivan-herman.net/me"

     [22] http://www.ivan-herman.net/me

   <markbirbeck> typeof="Person Agent"

   <markbirbeck> >

   <markbirbeck> <h1>

   <markbirbeck> <span property="title">Dr</span>

   <markbirbeck> <span property="fn">Ivan Herman</span>

   <markbirbeck> </h1>

   <markbirbeck> </div>

   <markbirbeck> </html>

   markbirbeck: That's how you get the Microformats-like markup.
   ... You can achieve that with @token by making the same mappings.
   ... Instead of requiring typeof="Person:", you can do
   typeof="Person"
   ... That's proposal 1
   ... Defining them external to the document is the RDFa Profiles
   discussion.

   benadida: The worry I have is with proposal #2
   ... The idea of pulling these in from a different URL...
   ... Google with Rich Snippets could be the first customer of this
   feature - they're concerned about the number of prefix declarations.

   markbirbeck: Yes, that's a concern.

   benadida: Then let's use them as an example.
   ... If they were to use @profile - and we think of RDFa as you
   browsing across websites and collecting triples.
   ... If the @profile is not available for any reason, you have to
   delay interpretation into triples until it's available.
   ... You can't just use a plain RDF store...
   ... You /could/ do it via vocabulary equivalencies.
   ... You could say google:title is the same thing as dc:title...
   ... Then maybe the only thing we need is the ability to redefine the
   base prefix.

   <benadida> prefix="[23]http://rdf.data-vocabulary.org/rdf#"

     [23] http://rdf.data-vocabulary.org/rdf

   <markbirbeck> I think...

   benadida: The matching of terms could be done via an RDF vocabulary
   ... only when it's an unreserved term does it use the default
   prefix.
   ... Is my concern clear?

   markbirbeck: Yes, but in terms of the definition of @profile, the
   concern isn't as great as you might think.
   ... As with schemas, you're allowed to not dereference the document.
   ... an RDFa parser would be entitled to know the prefix mappings by
   derefercing the URI
   ... It's not that you don't dereference, it's that things won't
   break as often as you think.
   ... We could argue that we should /never/ dereference.

   <Zakim> Ralph, you wanted to support Ben's concern and proposal

   Ralph: This is a potential interaction that we haven't really
   discussed.
   ... We don't depend on @profile now.
   ... Up to this point, without derefercing namespace URIs we can't
   construct the named graph without dereferencing.
   ... The ability to parse the document and get the triples out of it
   is important.
   ... If we find a mechanism that allows us to minimize the prefix
   bindings to just one, we can always parse the document.
   ... We may not be able to dereference the URI, but we can at least
   put the triple into our graph.

   benadida: Yes, that's a better way to say it. I think we can cache
   these things.
   ... Don't know if /requiring/ another layer of indirection is a good
   thing.

   markbirbeck: If you know what a URI means, you don't have to
   dereference it.

   Ralph: Sure, but we're creating a mechanism that allows us to
   encounter completely unknown @profile URIs...
   ... If we create a mechanism where we don't know how to expand the
   "Person" token without dereferncing another URI.
   ... Today, we can always expand the URI and put it in the triple
   store.

   markbirbeck: Sure, let's put that to one side... I don't think we
   get all of the features that we want from what Ben is suggesting.
   ... One of the big things is the number of namespaces. Ben's
   proposal gives us 1.
   ... We're resurrecting the [default prefix mapping]
   ... The thing that keeps coming up with SearchMonkey is that they
   have a ton of namespaces up top.
   ... We created "vocabularies" that are built from other
   vocabularies.
   ... We end up with quite a few namespaces.
   ... If we don't want to go @profile, then that's fine.
   ... Let's stop thinking about explicit vocabularies, and more about
   mixing vocabularies.
   ... You need a more subtle and flexible vocabulary term declaration
   mechanism.

   Ralph: By taking a bunch of terms I want to use from different
   vocabularies, I can give them names in my "ralph" namespace.
   ... My "ralph" namespace has a URI - I can parse triples out of
   them.

   <ShaneM> let's call that a "hybrid vocabulary"

   Ralph: The one dereference of the Ralph namespace gives me the
   meaning of all of the names (mapping to dublin core, foaf, etc.)
   ... Dublin Core had this sort of approach in the past.
   ... It's a question of how the indirection happens...
   ... Where does the indirection go?
   ... In your proposal, you must dereference @profile.

   markbirbeck: No, it doesn't.

   Ralph: minutes are wrong...
   ... My understanding of the @token proposal is that you have to
   dereference.

   markbirbeck: That doesn't have anything to do with the @token
   proposal.

   ShaneM: It has to do with the @profile proposal.

   <Ralph> [I stand (sit) corrected. Sorry for misunderstanding]

   benadida: Dereferencing for @profile proposal is happening at the
   parser level.
   ... It's not an issue of how many dereferencings are happening, it's
   at what level does it happen?
   ... It's not a syntax issue, it's a vocabulary issue.
   ... Maybe it should sit at the vocabulary layer of the stack.

   markbirbeck: I'm confused about this...
   ... Proposal 1 is simply saying, instead of doing "Agent:", we allow
   "Agent"

   <Ralph> [indeed, my concern is about _requiring_ URIs in @profile to
   be dereferenced before a string such as "Agent" can be expanded to a
   full URI]

   markbirbeck: We haven't said anything about @profile in the @token
   proposal.
   ... You have more indirection and it's a bit more complicated.

   benadida: Let's take a step back and look at the goal..

   <benadida> <div XXXXXXXX>

   <benadida> My name is <span property="name">Ben</span>

   <benadida> ...

   <benadida> </div>

   benadida: We want that markup to be simple and non-prefixed.
   ... We want that to be do-able in RDFa.
   ... What is the enabler of that technology.
   ... If you try to do it incrementally, you end up with the @token
   proposal.
   ... maybe that mapping belongs at the vocabulary level.

   markbirbeck: You're saying you can use owl:sameas at the vocabulary
   level.
   ... I'm saying that we can solve it at the CURIE level.

   <markbirbeck> a:b a x:y .

   Ralph: I stand corrected with my earlier response.
   ... I could view @token syntax as a step beyond CURIEs.
   ... People are going to be frustrated with the list of items they
   have to use in their document.
   ... They're going to be annoyed by having to cut/paste entire chunks
   of @token attributes.
   ... @profile is a way to do that.
   ... Now we're at the point of having an external document that
   provides a list of external mappings.
   ... When I look at the token proposal, I see a slippery progression
   to the point that we need something like @profile.
   ... I want to try to avoid that temptation.

   <Zakim> ShaneM, you wanted to discuss profiles vs vocabs

   ShaneM: Ben, owl:sameas ...
   ... Hybrid vocabularies are fine, go ahead and do it, we already
   enable that (more or less).

   benadida: No, we need to modify CURIE processing for that to happen.

   ShaneM: Creating those external collections that you can use is an
   external issue

   benadida: What do you think we're not focusing on enough.

   ShaneM: We keep talking about the @token proposal, and others keep
   talking about external vocabularies.

   Ralph: We can't look at either in isolation, we need to look at it
   from both ends.
   ... I don't think we can answer them in isolation.

   markbirbeck: My prime goal is a Microformats look-alike.
   ... If we don't have an external document solution, then I'm not
   concerned with "Agent:"

   <ShaneM> remember that
   xmlms:shane="[24]http://www.aptest.com/IDs/shane" works today

     [24] http://www.aptest.com/IDs/shane

   <ShaneM> We had a straw horse proposal for external definitions at
   [25]http://www.rdfa.info/wiki/RDFa_Profiles

     [25] http://www.rdfa.info/wiki/RDFa_Profiles

   markbirbeck: I'm not concerned with @token in-so-much as I'm
   concerned with Microformats simplicity.

   benadida: We should try and simulate that the right way.

   <Ralph> Manu: I think we need to be able to support external
   vocabularies

   <Ralph> ... I don't yet understand Ben's proposal to see how to
   combine audio & media vocabularies with microformat vocabularies

   <Ralph> ... this is a use case we have right now

   <Ralph> ... I'll explain in email

   <Ralph> ... if Ben's proposal is to allow a CURIE without a ':', I
   don't see how to do this in a way that works like Mark's proposal

   <Ralph> ... it falls back to the vocabulary layer so the RDFa
   processing rules and parser don't need to say much

   <Ralph> ... but it creates a big burden on users to create these
   'bundled' vocabularies

   <Ralph> Ben: we have a technology to map vocabulary terms and it
   worries me to create more layers of mapping

   <Ralph> Mark: my model is to have tokens that map to [full] URIs

   <Ralph> ... vocabulary mapping with owl:sameAs has been observed to
   require a higher level of RDF processor

   <Ralph> Manu: this inferencing mechanism may not belong in the RDFa
   specification

   <Ralph> ... where would we advise document authors of how owl:sameAs
   works? Best practices?

   <Ralph> Ben: I'm suggesting we leverage more of the existing RDF
   mechanism

   <Ralph> ... yes, it's present at a different layer

   <Ralph> Mark: I'm only talking about an additional mechanism for
   abbreviating URIs

   <Ralph> ... owl:sameAs is a very different kind of mechanism

   <Ralph> ... it requires a higher level of [semantic] processing

   Ralph: We can't process triples if we can't dereference in Mark's
   @profile proposal
   ... It's not clear-cut how we externalize token mappings.

   ShaneM: Yes, but those are two separate issues.
   ... They're orthogonal issues.

   Ralph: They come from an objective that Mark's proposing - making
   the syntax look as close to Microformats as we can.

   ShaneM: I don't think it's a lookup step.

   markbirbeck: I think that Mark's understanding of expanding the
   definition of CURIEs is correct.

   benadida: I don't think that's the issue
   ... It doesn't include the definition of @profile.
   ... Don't have an issue with augmenting the way CURIEs are parsed.

   rel="foobar"

   prefix="[26]http://example.org/#"

     [26] http://example.org/

   benadida: Clearly and edge case we'd need to hash out.
   ... My proposal is only intended to highlight this particular
   architectural issue.

   Steven: On vacation for 3 weeks.

Summary of Action Items

   [PENDING] ACTION: Ben to author wiki page with charter template for
   RDFa IG. Manu to provide support where needed. [recorded in
   [27]http://www.w3.org/2009/05/28-rdfa-minutes.html#action10]
   [MOVED TO WIKI] ACTION: Mark write foaf examples for wiki [recorded
   in [28]http://www.w3.org/2008/09/11-rdfa-minutes.html#action13]
   [MOVED TO WIKI] ACTION: Ralph make a request for an RDFa issue
   tracker instance [recorded in
   [29]http://www.w3.org/2009/05/28-rdfa-minutes.html#action11]
   [MOVED TO WIKI] ACTION: Ralph think about RSS+RDFa [recorded in
   [30]http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]008/09/1
   1-rdfa-minutes.html#action15]
   [MOVED TO WIKI] ACTION: Ben to prepare "how to write RDFa"
   screencast with fragment parser [recorded in
   [31]http://www.w3.org/2009/06/11-rdfa-minutes.html#action05]
   [MOVED TO WIKI] ACTION: Mark create base wizard suitable for cloning
   [recorded in
   [32]http://www.w3.org/2008/09/11-rdfa-minutes.html#action12]
   [MOVED TO WIKI] ACTION: Mark to send Ben ubiquity related wizard
   stuff [recorded in
   [33]http://www.w3.org/2008/11/20-rdfa-minutes.html#action11]
   Wiki todo items: [34]http://rdfa.info/wiki/todo
   [End of minutes]
     _________________________________________________________

     [27] http://www.w3.org/2009/05/28-rdfa-minutes.html#action10
     [28] http://www.w3.org/2008/09/11-rdfa-minutes.html#action13
     [29] http://www.w3.org/2009/05/28-rdfa-minutes.html#action11
     [30] http://www.w3.org/2008/09/11-rdfa-minutes.html#action15
     [31] http://www.w3.org/2009/06/11-rdfa-minutes.html#action05
     [32] http://www.w3.org/2008/09/11-rdfa-minutes.html#action12
     [33] http://www.w3.org/2008/11/20-rdfa-minutes.html#action11
     [34] http://rdfa.info/wiki/todo


    Minutes formatted by David Booth's [35]scribe.perl version 1.135
    ([36]CVS log)
    $Date: 2009/07/20 18:43:54 $
     _____________________________________________________

     [35] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
     [36] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 20 July 2009 18:48:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 July 2009 18:48:16 GMT