Re: Chat with Ivan on RDFa 1.1 Authoring features

As Ben, I am amazed by the scribing capacities of Manu:-)

Just few small modifications.

On 2010-3-24 11:33 , Manu Sporny wrote:
> 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.

What I meant to say is that the @token/context-specific mechanism seems
to be an alternative to the approach that pulls in essentially RDF

> ... 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 ....

Should say <blablab> hasSomething ...

The point is that other vocabularies may be used to characterize the
vocabulary we are talking about.

Whether this is the right example or not is not the issue; the issue is
that using RDF as part of the @profile mechanism is open ended, in the
sense that later evolution of RDFa may allow to add additional features
that we do not envisage yet (in an RDFa2.0, etc).

> <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" }

What I wanted to say: if, say, Turtle is used, it is not much more
complicated than JSON...

> 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.

What I said, to be more precise: if our goal is (and I think it is) to
simplify RDFa and bring it closer to HTML(5) authors, then we should
keep away from RDFS. We would shoot ourselves in the foot in the sense
that it would make RDFa more complex conceptually, something we do not
want to do... (sorry Toby:-)

Also, what I said about the collapse of the keyword and prefix mechanism
was that I am not dead against it any more (the weekend thinking helped)
but I just do not see what it buys us while it leads us to extra work to
update old primers, descriptions, tutorials and such. We should not do
that unless there is a good reason for it.

> ... Having an error reporting mechanism in RDFa Processor would be
> important.

Thanks Manu!

Ivan

> 
> ----------------------------------------------------------------------
> 
> -- manu
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf