Chat with Ivan on RDFa 1.1 Authoring features

Here's the most recent chat with Ivan about the RDFa 1.1 Authoring features:

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

TOPIC: RDFa Vocabularies proposal and @token proposal

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 - @token is used to declare
prefixes and tokens. I think most (except for Ben and maybe Toby) are
okay with that. @token can replace xmlns:, but it also can create
prefixes/keywords for author documents when used in Profile documents.
It's declarations are not scoped when used via @profile.
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: If we have in the future, we can have profiles like this:
<ivan> [
<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;"? Simpler for authors - no
need to fully understand RDFa.
<ivan> [ rdfa:uri "bbb"; rdf:alias "b" ]
<ivan> { "uri" : "bbbb", "alias" : "b" }
Manu: he thinks we need RDFa Vocabularies eventually, but the simpler
solution is @token right now
... Mark's point is that if 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? He thinks they won't -
and he's right to some degree, for people that don't want to learn
RDFa... just use it.
Ivan: There are far more people that will /use/ RDFa Profiles than
/create/ RDFa Profiles.
... We are optimizing on the users of those RDFa Profiles, not the
authors of the RDFa Profiles.
... we are not optimizing on the RDFa 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.

TOPIC: Collapsing prefixes/keywords into a single concept.

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.

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

-- 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 Wednesday, 24 March 2010 15:33:38 UTC