Scribed telecon discussion with Ben

We are discussing the following issues with Ben/Ivan while they're on
the road/can't make the telecons:

1. Importing prefixes via @profile is dangerous? (Ben)
2. Combine prefixes/tokens into a single "list of mappings" in the
   FPWD. (Ben/Ivan)
3. Do we want to pursue external documents as a means to declare RDFa
   Profiles in the FPWD. (Ben)
4. Any other objections to what may be placed into the FPWD. (Ben/Ivan)

Below is what I was able to scribe, it captures the gist of the
conversation and Ben and I think that we now understand the crux of the
disagreement.

------------------------------------------------------------------------

#1: Importing prefixes via @profile is dangerous

Manu: You believe that importing prefixes from @profile is dangerous, right?

Ben: What I do agree on with the design of HTML5/Microformats - don't
enable every feature under the sun - we should measure what the benefit
is? What is the benefit of opaque import of prefixes via @profile? What
use case are we trying to support with that? We don't need it for
Microformats-like markup.

Ben: We want to support the simplest possible markup - I see the wisdom
that you want to give simple markup - there is still a cost. If it's a
keyword, you know where it came from. if it's a prefix, you don't know
if it came from a @profile or @xmlns: or both.

Ben: We have to make sure the upside is worth it, and right now I'm not
sure that it is.

#2: Combine prefixes/tokens into a single "list of mappings" in the FPWD.

Manu: There is an argument for simplification of the concepts in RDFa...
how do we make it easier to understand RDFa? How do we enable the
Default RDFa Profile? How do we make sure Dublin Core and FOAF are
processed by Google/Yahoo while staying true to the spec?

Ben: I think that whether we have prefixes/tokens in a single list of
mappings is an implementation issue. The author doesn't care -
prefix:reference or keyword:reference or keyword looks the same to them
- they care more about examples than the mental model of RDFa.

Ben: My concern is that if I see foo:bar - that "foo" /could/ have been
declared via xmlns: or it could be in a @profile... and I can't tell.
This is important for backwards-compatibility reasons - if we keep
xmlns: as the only way to define foo: then we can be certain that we
don't generate the wrong triples. We either generate prefixed triples,
or we don't generate anything at all.

Ben: I think there is some elegance to declaring prefixes in @profile
and unifying prefixes/keywords. The outcome for the HTML author is
somewhat different. Let's assume a:foo and b:bar - those prefixes could
come from a profile instead of two xmlns: statements. What's the
advantage there? What does that buy us other than allowing tons of
xmlns: declarations to be placed into a @profile document? If we want
Microformats-like markup, Microformats don't depends on tons of xmlns:
declarations. So, if the argument is that migrating xmlns: declarations
makes it easier for authors, I don't buy it. If the argument is that
providing keywords for authors makes it easier, I definitely agree.

Ben: If we enabled profiles that allow keywords, we are suddenly
bringing to the table beginner web authors that like simpler markup, and
that's great.

Ben: If we allow prefixes in profiles, we're not bringing anyone else to
the table.

Ben: We try to make this consistent with a rule that makes it
everywhere. We will use this if Google uses a explicit profile when
there is a @profile. While the generalization is appealing, we don't
think it'll happen. If these things are undefined, we suggest that the
following prefixes would be assumed.

Manu: What about combining prefix/keyword concepts and putting it into
FPWD to get feedback from Google/Yahoo? If they don't want to implement
the Default RDFa Profile or combine prefix/keywords, we take it back out
of the spec?

Ben: Don't get me wrong. I don't want to go against all recommendations
- if this is what everybody else wants, I will reluctantly live with it.
We are trying to make things simple, but I'm afraid that we're making
them more complicated. There is no mechanism in rdf/xml for doing this
kind of syntactic sugar. Enabling this makes authors lives more
complicated - if Google/Yahoo accepts default RDFa Profiles, then I
would agree that we should do this.

Ben: It makes it confusing if something is a URI or CURIEs, right? If a
prefix is not declared it's assumed to be a Internet protocol. What if
you can't look up the @profile. What if there is ambiguity there?

Manu: That happens in all cases where we depend on an external @profile
document. It's inescapable.

Ben: I don't think that's the case if we keep prefixes out of @profile
documents. If I ask a system to generate a triple, if you ask people
that have been doing markup for years about the similatiries between
"foo:bar" and "baz", specifically whether "foo" is in the same "bucket"
as "baz", they'll say no. "foo" is a namespace with "bar" as the
reference. "baz" is a reference - that's how we've thought about this
for a very long time and that's because that was what was natural to the
group. That may be what's natural to most people that understand XML.
Until Mark came up with token idea, we all were functioning on the
assumption that "baz" is on the same level as "bar" - it was a reference.

Ben: What do we do about unprefixed CURIEs? Something without a colon is
a suffix without a prefix. What that may indicate is that the average
person will see it as prefix:reference.

Ben: If we adopt the token view of the world, we would be doing this
like nobody else does it. Nobody looks at QNames and namespaces like
this... it's a very interesting way to look at it, but nobody does it.

Ben: I think the concept of namespaces is something that has exposure to
regular web devs. I think @token is a slightly contrived way to look at it.

Manu: So, you're for keeping a separate list of prefixes and tokens in
the RDFa Processor?

Ben: Let's look at it another way - what happens if you say that
keywords are defined by xmlns:? It's not a namespace anymore, it's a
token. This is going to really confuse people that know how to use
xmlns:! If you did something like this in in RDF/XML - it wouldn't work.

Ben: Worried that consistency that we're aiming for is consistency in a
virgin world. Yes, it's consistent... but it's consistent in a way that
nobody else has modeled this before... which will lead to confusion.

Ben: If we keep prefix/keyword separate, @token would only affect the
reference, never the prefix. "Person: xyz;" would be kosher, but "foaf:
http://xmlns...foaf;" would only expand if "foaf" was used by itself.

Ben: @profile is a way to get new keywords... it's an incremental story
- that's the way we should pitch it. Default values in HTML next/prev/ -
you can pull in own concepts in xmlns:... if you want it to make easier
on everyone - pull in keywords via @profile. If we combine prefixes and
keywords, we're changing the way we have to explain a large amount of
this work.

Ben: If we wanted an alternative to xmlns: - it has to be overridden by
xmlns: to be backwards compatible. Otherwise, we can't guarantee
backwards compatibility.

Manu: What about the notion that xmlns: may never be correctly supported
in HTML5.

Ben: We're all in agreement about xmlns: - going away from it entirely
is not do-able, something will have to happen in HTML WG to support
xmlns: declarations because they happen all the time in HTML5.

Ben: I think there will be two attributes if we get rid of xmlns:. One
to declare prefixes, the other to declare keywords. How do I write the
new version of xmlns:foaf with @profile? Let's say we replace xmlns with
prefix="" and then we have @profile everywhere. That would accomplish
the same thing that @token/@map/@vocab accomplishes.

Ben: Support prefix="" and support including @profiles. URIs can be
everywhere. We don't need more of the same mechanisms.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

Ben: May be difficult to agree on this, but I think we finally
understand the crux of the issue.

Ben: You and Mark seem to be searching for the cleanest design.

Ben: I look at it as what is the simplest incremental change? What is
the most consistent story? How to have least possible impact on
backwards compat issues? If this was RDFa 1.0, I would lean more in your
direction... but we have implementations, markup and courses already out
there and it's much easier to tack the @profile concept on as a slide at
the beginning/end of a presentation than to rewrite the entire way we
model and teach RDFa.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ben: There is a down-side to this approach and I wanted to make people
understand that we do give up a number of things if we combine
keywords/prefixes into a single attribute or allow both to be defined in
the @profile document. It's not as straight-forward of a decision as it
may seem.

------------------------------------------------------------------------

That's most of it - I may have missed bits and pieces because I was
talking. I'm sure Ben will fill in any points that I missed. I didn't
scribe most of what I said, but the vast majority of it was just
pointing to arguments that have already been made on the mailing list.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Tuesday, 23 March 2010 00:11:57 UTC