RDFa in XHTML Task Force

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 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 http://www.w3.org/2009/05/28-rdfa-minutes.html#action10] [CONTINUES]

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

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

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

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 http://www.w3.org/2009/05/28-rdfa-minutes.html#action11] [MOVED TO WIKI]

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 http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]008/09/11-rdfa-minutes.html#action15] [MOVED TO WIKI]

<Ralph> last week's minutes

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> 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="http://purl.org/dc/terms/Agent"

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

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

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

<markbirbeck> >

<markbirbeck> <div

<markbirbeck> about="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="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="http://www.aptest.com/IDs/shane" works today

<ShaneM> We had a straw horse proposal for external definitions at 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="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.