Re: attempting to merge the 'vocab' and 'profile' documents

On 2010-3-5 16:58 , Mark Birbeck wrote:
> Hi Ivan,
> 
>> Right. And I would also be happy to keep to profile if we can... that being said, what this means
>> that if the HTML5 evolution does not allow for @profile (because it is not reintroduced) the
>> @vocab term might not be ideal either...:-(
> 
> I'm not too worried about this. If @profile is part of HTML5, then we
> use it. If it's not part of HTML5 then we create it.
> 

(Also answering to Shane here) technically that is obviously a
no-brainer. I am more concerned by the, shall we say, 'political' issues
that this might raise: HTML5 WG decides to remove an attribute and then
the RDFa WG decides to reintroduce it... that would be a recipe for
flame wars

> 
>> I guess my only point was to take some sort of a JSON encoding of RDF and not just a simply key-value pairs.
> 
> This is where I would disagree.
> 
> First, it feels somewhat bloated to me, to start taking values that
> drive processing and expressing them in RDF.
> 
> N3, SPARQL, RDF/XML, RDFa...they all have ways to express things that
> help when processing a document, but without having to resort to using
> RDF. For example, in this:
> 
>   @prefix foaf: <http://foaf-namespace> .
> 
>   <> foaf:name "Ivan Herman" .
> 
> Why turn @prefix into RDF? The data we want is your name, and the
> 'foaf' prefix mapping just helps us get there.
> 
> And second, I think to create these mappings using RDF is to look at
> this at the wrong level of abstraction. There invariably needs to be a
> way to bootstrap a parser, and expressing that bootstrapping in the
> same language as the language to be parsed is a little circular.
> 
> But also, it really is the case that we have a name/value pair here --
> it becomes quite contrived to turn the pair into a triple, by making
> up a subject.
> 

It is not my goal to use RDF just to use RDF, obviously. But RDF gives
me a way to define both the concepts and the resulting mechanism in an
abstract manner that is independent of the serialization. And that is
what I think is nice in Manu's original document.

Actually, it would be possible to say that the vocabulary can be defined
in _any_ RDF serialization format and the RDFa tool could then use that,
except that this would be a bit of an overkill for the tool that would
have to understand and parse RDF/XML, turtle, RDFa... Ie, it is only for
practical considerations that the we restrict it to one or two
serialization formats. And it is for this symmetry that I am looking for
an RDF/JSON syntax (whatever that may be). I do not see any issue with
circularity...

> 
>> That being said: we still have to decide whether we _do_ need JSON... I for one would be happy to get rid of
>> it here though, I must admit, these b...dy security issues make me think twice (and more...)
> 
> Right. And for me the browser is a key target, hence the reason for
> introducing JSON.

But we should be careful not to make the non-browser implementation too
complex either. It is true that there are json tools for, say, python,
ie, reading and parsing in a json file is easy. That JSONP, however, is
different, I do not expect the regular tools to handle that. In other
words, a Python tool would have to parse the JSONP by hand, so to say,
which is a bit disagreeable to do... I expect similar problems with Perl
or PHP, for example.

(That being said there might be tools that handle JSONP for other
languages, too. I just do not know)

Ivan

> 
> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)

-- 

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