Re: RDFa API - adding Namespace

Hi Nathan,

With all due respect to everyone concerned, I think RDFa is the
simplest thing to ever happen to RDF. Prior to that most web
programmers who ever came across RDF (and that wasn't that many)
thought about RDF in terms of RDF/XML, and concluded that RDF was 'too
complex'.

I believe the continued success of RDFa is based on the fact that our
approach is to start with things that people are already doing --
i.e., marking up documents -- and then try to think about how their
existing practice could be 'interpreted' as RDF.

That's a very different approach to trying to work out how to put RDF
into HTML or XML documents. (Remember that the last time that was
tried we got RDF/XML embedded inside comments!)

And the original designs for an RDFa API tried to take the same
approach, looking at what JavaScript programmers would do anyway in
their code, and then trying to work out how to give that an RDF
'twist'.

For example, imagine I create a JSON object like this:

  var vehicle = {
    "wheels": 2,
    "engine": true
  };

These kinds of JSON objects are what programmers would want to
manipulate and do things with, and so our starting-point should be
about layering RDF onto them.

Which means allowing people to query a triple-store and have objects
like this be automatically generated 'for free' (like SPARQL
projections). Which in turn means allowing the triple-store to be
manipulated and conceptualised as something other than a simple set of
triples.

This approach allows us to go even further, making it possible to
manage JSON objects with reasoning and inference.

For example, any programmer -- whether interested in RDF or the
semantic web, or never having heard of it -- would see the benefit of
writing a rule that manages a third property of 'type' for you on the
object I gave above:

  assert(vehicle.type === "motorbike");
  vehicle.wheels = 4;
  assert(vehicle.type === "car");

IMO this is the 'gentle' route to the semantic web; we start with the
tasks that people already want to do and make them not only easier,
but add a qualitative difference in functionality.

So where does that leave your original suggestion about namespaces?

Well...with respect I don't see how foaf('name') helps anyone.

It's not just that it's RDF-oriented (I've been steeped in RDF for
about a decade, so I can live with that) -- the bigger issue is that
it's not good JavaScript:

* as Toby rightly pointed out, if you want to do this in your code,
then just use closures and maybe some currying;

* and as Manu rightly pointed out, whilst a programmer unfamiliar with
the namespaces you are using might guess at what dc('title') is doing,
they'd probably be stumped when it comes to v('adr').

Apologies if I come across a little riled; I certainly don't mind
discussing the possibility of adding new features, but I can't help
responding when the discussion becomes about how the RDFa API is
complicated yet namespace functions are easy, or about how we might
repeat the RDF/XML all over again by not having enough RDF in our
specs.

</soapbox> :)

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)


On Tue, Oct 12, 2010 at 11:20 AM, Nathan <nathan@webr3.org> wrote:
> Tim Berners-Lee wrote:
>>
>> On 2010-10 -11, at 20:23, Manu Sporny wrote:
>>>>>
>>>>> When we did the second pass of the design phase on the RDFa API, we
>>>>> attempted to make sure that it was a simple as possible for those not
>>>>> familiar with RDF.
>>
>> That was what happened in the RDF/XML design and it was to a certain
>> extent a disaster.   It is much more important to make it very clean for
>> this who do understand RDF, and then people will actually
>> learn RDF that much faster.  RDF is very simple, in fact.
>
> I wanted to pick up on this under separate cover, because personally, I wish
> somebody had said 'RDF is very simple, in fact' to me when I first started
> getting heavily involved in sem web related work.
>
> The fact is that RDF was presented to me (generally, by the community and
> via Linked-Data) as being a complex beast full of nuances and complexities
> that required a thorough understanding of not just RDF, but all it's
> serializations, OWL, web architecture and a host of other technologies.
>
> Due to this I approached learning RDF from a perspective of expecting
> something complex, and thus it was - I literally 'lost' several thousand
> hours which had real life repercussions resulting in lost contracts,
> delivery delays and knock-on effects in my personal life which I still feel
> to this day. In some ways it's a sad story, but in other ways I'm very glad,
> because I'm here and surrounded by some great minds in an interesting fast
> moving sector, and glad of all the heavy studying I did along the way.
>
> The end result for me though, is that my first sentence to anybody when
> speaking about RDF is "it's really very simple" followed by the simplest
> explanation of a triple that I can manage - usually taking the approach of
> saying that you simply take an object, stick the id on the left, swap id's
> for web scale guid's (URIs), mount the results on the web and then do the
> same for class blueprints (schemas), introducing the benefits of each as I
> go - I find this works quite well with programmers and usually they grok it
> in circa 30 minutes.
>
> Bringing this back to the current context, I do feel the
> RDFa-document-specific part of the API is simple, I also feel the RDF API
> we're working on is simple for implementers and provides a core subset of
> functionality needed by javascript developers. What we're doing definitely
> isn't "a simple, usable RDF API for javascript developers" though, and as
> discussed this would need to be handled separately.
>
> Which leads me to think, perhaps we do need to split the RDFa API in to two
> documents, one with the RDF & Data Interfaces (the core RDF API) and another
> with the RDFa document-based API - in order to keep it simple and present it
> as such.
>
> Best,
>
> Nathan
>
>

Received on Tuesday, 12 October 2010 11:18:52 UTC