- From: Ralph R. Swick <swick@w3.org>
- Date: Mon, 20 Jul 2009 14:46:19 -0400
- 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 UTC