See also: IRC log
hrm, Mark still hasn't replied...
<ivan> ouch
<ivan> well, we can have our conversation:-)
<ivan> you are gathering opinions anyway...
yes, true...
<ivan> just ping me when you are ready
I'm ready...
<ivan> should I create an ad-hoc zakim channel now?
we have two options.
we can try to have the telecon at 12pm
or I can gather your opinions now and then have a separate telecon with Mark.
<ivan> I know that I am at fault here, sorry about that, but 12pm is a bit awkward for me indeed
up to you - if you think 12pm would be pushing it, let's have the telecon now.
ok, let's do the telecon now, then.
<ivan> so, watch what is happening on irc:-)
<ivan> that is it:-)
<ivan> this is ralph magic:-)
<ivan> I am in, waiting for you...
<scribe> scribenick: manu
Ivan: So, let's get started - let me try to summarize things the way I see it.
Manu: ok
Ivan: Had a brief chat with Ralph
about this stuff...
... I must admit, I need to understand @vocab/@map/@token
.
... Couple of things that are no-brainers for me - things that
we need in RDFa 1.1
... We need an alternative to xmlns:
... maybe @vocab attribute or something like that - we have to
have that.
... Default prefix for keywords - simple and works well for
simple cases - very obvious.
... There is some disagreement on @profile file stuff.
... There is the issue whether what is pulled in is essentially
RDF in some encoding, which produces triples that are used in
the author document - the RDFa Vocabulary proposal.
... The other disagreement, I don't understand,
context-specific interpretation of RDFa attributes via @token -
scares the hell out of me... sounds complicated.
... extra difficulties for tool providers... don't understand
what it buys us.
Manu: This is part of Mark's @token proposal
Ivan: Very ugly architecturally,
it hides data, tool providers will have to have two different
ways to parse an RDFa file - very very confusing.
... One more argument in favor of cleaner RDFa usage - it's
true that at the moment, this may look like it's more
complicated, however, what this also gives us is a general
mechanism that can be re-used in a future version of
RDFa.
... This allows us to add additional things later on - two
examples.
... My example is on whether or not we want to restrict
keywords to specific attributes.
... If we want to have such a restriction - I don't think we
want to do that, but if we do - it's a trivial extension -
rdfa:relrev
... This next one comes from Ralph
<ivan> [
Ivan: If we have in the future, we can have profiles like this:
<ivan> rdfa:uri "blablab"
<ivan> rdfa:alias "b"
<ivan> <blablab> a owl:Ontology ;
<ivan> <blablab> isatURI "balblab"
<ivan> <blabalba> has ....
<ivan> ]
Manu: Mark's position is that this is too complicated - why not just token="keyword: mapping; keyword: mapping;"?
<ivan> [ rdfa:uri "bbb"; rdf:alias "b" ]
<ivan> { "uri" : "bbbb", "alias" : "b" }
Manu: he thinks we need it
eventually , but the simpler solution is @token righ tnow
... Mark's point is that we're going to use text/html +
rdfa...
... Are the people that are going to create RDFa Profiles going
to have the technical knowledge to use this mechanism?
Ivan: There are far more people
that will /use/ RDFa Profiles than /create/ RDFa
Profiles.
... We are optimizing on the users of those profiles, not the
authors of the profiles.
... we are not optimizing on the profile authors.
... @token is much more complicated than this because of it
switching context.
Manu: Yes, but Mark does have a point @token is simpler to use syntactically.
Ivan: Yes, but it makes
interpretation of it and the mental model very confusing.
... We are saying via the @token proposal, that it's okay to
interpret a document in two completely different ways.
... RDFa Vocabulary syntax is slightly more complicated, BUT
it's an open-ended upgrade mechanism.
Ivan: It is correct that the
collapse of keywords and prefixes is consistent - that's right,
it's perfectly consistent.
... If we did it today from scratch, I would agree with
it.
... The problem is, and I agree with Ben, that we have already
developed a mental model for RDFa 1.0 - we have written Primers
and Tutorials with a conceptual separation of prefixes and
keywords, if we want to do what Mark is saying, we have to do a
decent amount of work to make it clean.
... This is not the way we presented CURIEs, this is not the
way we presented in the Primer,
... I accept that it is proper and clean, but I'm not sure that
this is something that is worth it... we don't really need the
collapse.
... We can do all of this other stuff by not collapsing the
concepts.
... it doesn't buy us too much... now that I say that,
... If we want to put extra restrictions on how certain
keywords can be used, collapsing doesn't really work well
anymore.
... it would be reasonable to say that keywords are classes -
keywords can be used only in @typeof/@rel/@rev - it would be a
reasonable restriction.
... it makes sense to have such restrictions... I don't feel
very strongly about the restrictions, but let's not throw that
out just yet.
Manu: So, Ben said that he is
very much against defining prefixes in RDFa Profile
Documents.
... *explains ben's position*
Ivan: I know there is this worry
that RDFa 1.0 processors might process RDFa 1.1 documents -
bottom line, @profile everywhere is not allowed in HTML5 or
XHTML.
... The "process invalid documents" argument doesn't resonate
for me.
... As for the second argument, what does it buy me by knowing
where a @prefix is coming from?
... If it comes from an RDFa profile document, and I can't
dereference @profile, we can use warnings to state that the
prefix may be invalid.
... What does it buy me to know where the prefix comes
from?
... Authors can create situations where they shoot themselves
in the foot - but this has always been a usability issue for a
long time.
... Allowing prefixes to be defined in RDFa Profile documents
allows authors to not make xmlns: declaration errors.
... If I want an RDFa Profile to use foaf and dc, and I don't
want my authors to deal with too many difficulties, I could
create a whole bunch of keywords - 100 different keywords, or I
could just specify two prefixes.
... Not allowing prefixes ensures that the RDFa Profile
mechanism doesn't scale.
... let's not forget that there are people out there that have
no problem using LOTS of prefixes... we want to address their
needs as well.
... I know my example is a bit extreme, 15 prefixes... but
others may do this too.
Manu: What about "The Default RDFa Profile"?
Ivan: less of a strong argument
for me - I would include RDF RDFS SKOS OWL
... Perhaps RDFa - that is a big social issue - what to add,
what not to add - W3C would make selections - which is
bad
... I don't think it's a strong argument, not fully sure that
we should go there.
... I am still of the opinion that using RDFa vocabulary to
define RDFa Profile document is the way to go - feel very
strongly about that.
... Having a default prefix mechanism is good - I am in favor
of that.
... I am dead against bringing RDF Schema into the picture -
really don't want to see that.
... We would shoot ourselves in the foot if we started to do
something like that.
... Having an error reporting mechanism in RDFa Processor would
be important.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/}/]/ Found ScribeNick: manu Inferring Scribes: manu Default Present: Ivan, manu Present: Ivan manu WARNING: Fewer than 3 people found for Present list! WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 24 Mar 2010 Guessing minutes URL: http://www.w3.org/2010/03/24-rdfa-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]