Re: RDFa API - adding Namespace

Mark Birbeck wrote:
> 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'.

Indeed, and I sincerely hope I didn't indicate I thought otherwise, my 
earlier mail was no reflection on RDFa or the work done here, and more 
just a personal experience of how I was generally introduced to RDF - my 
learning curve would have been much simpler if RDF had been introduced 
in terms of Turtle and RDFa :)

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

[snip lots of cool stuff about working with RDF from a Javascript 
perspective - will reply under separate cover, or hopefully we can get a 
skype conversation]

> So where does that leave your original suggestion about namespaces?
> 
> Well...with respect I don't see how foaf('name') helps anyone.

Likewise with all due respect I do think foaf('name') helps /some/ 
people, and also see that c('foaf:name') helps others, whilst 
createIRI('http://xmlns.com/foaf/0.1/name') helps yet others.

I'd suggest that the core problem here is that URIs/IRIs are not 
generally supported as first class members of program languages (like 
string or int are), no less CURIEs, and that different people will 
prefer different approaches to handling them.

In any case, it was suggested to me that some people prefer one style 
whilst others prefer another, and so I tried to find the simplest way of 
  providing both, and suggested changing the return type of 
setMapping(prefix, iri) to return a CurieResolver - in the hope that we 
could allow people to do:

  var foaf = context.setMapping('foaf','http://xmlns.com/foaf/0.1/name');
  var c = context.resolveCurie;
  foaf('name') === c('foaf:name');

In other words use either style they wanted, let's not forget that to 
use CURIEs they must `register` them with setMapping() regardless, so in 
reality zero/none/no additional steps are added in to the API from a 
user perspective, it simply gives them a standardized way to use which 
ever style they prefer.

In reality, I personally don't feel that strongly about either - I see 
benefit in both approaches, however I feel the time I'm spending would 
be far better spent on other areas of the API and discussing those with 
yourself, from fundamentals through to implementation.

Personally I see no reason not to cater for both with this proposal - 
I'm aware that we can't standardize any kind of function that `pollutes` 
the global namespace (such as vocab() Namespace() ns() or similar) so 
for me it comes down to do we change that return type or not.

Either way it's a minor job to implement as part of the API with minimal 
change, and likewise as lib specific functionality.


> 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> :)

Likewise, apologies if you did get a little riled - quite sure that we 
all want to avoid mistakes of the magnitude or rdf/xml, that we all want 
a Javascript friendly API, and that none of us will rest until that's 
what we have - all on the same side with the same end goal :)

That said, I'm sure we can all agree that this:

data.context.createTriple( data.createBlankNode() , 
data.context.resolveCurie('cert:decimal') , 
data.createTypedLiteral("65537", "^^xsd:int" ) );

is hardly:

   { 'cert:decimal': 65537 }

Which I think, is the point all of us have been trying to get across (?)

Best,

Nathan

> 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 19:11:22 UTC