W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: Mandatory client supported serializations

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 30 Dec 2011 16:54:08 -0500
Message-ID: <4EFE3300.4070403@openlinksw.com>
To: public-xg-webid@w3.org
On 12/30/11 5:38 PM, Jiří Procházka wrote:
> Well probably the main reason I wrote that is because it is also to
> consider in the choice of mandatory serializations.
> So far it seems WebID is set on requiring a more or less random bunch of
> serializations based on guessing what mostly the publishers are going to
> want to use, which has following aspects:
> + publishers get more freedom of choice
> - hard implementing client code
> - probably limiting the WebID use by high serialization parsing requirements
> - alienating the fans of not chosen seralizations
> Now lets consider the alternatives:
> 2) chooising 1 syntax with low parser requirements (n-triples?)
> + easy to implement client
> + low client implementation requirements
> - less choice on publisher side
> - alienating the fans of not chosen serializations
> 3) write the core spec by NOT requiring ANY specific serialization, but
> create a separate document specifying a restrictions for creating an
> interoperability "trade"mark, which carries all the points of 1) (maybe
> lessening the - of alienation) but maintaining the WebID core
> serialization agnostic, which is good modularity which avoids the
> conflict of interests wanting the WebID to be most open and flexible and
> wanting it to be a central piece of reliably interoperable network.
> Feel free to add + and - points to the above, I just want to know why is
> 1) the way WebID is headed, not 3).
> I know I am not participant of WebID XG, nor I have any implementation
> ready, but I don't think that any of those facts makes my point less
> logically valid.
> Best,
> Jiri
> PS: I didn't add the subjective point of supporting the client side is
> more important then giving mroe choice to the publishers
> On 12/30/2011 07:53 PM, Henry Story wrote:
>> On 30 Dec 2011, at 20:42, Jiří Procházka wrote:
>>> Hi,
>>> I think WebID should be flexible enough to be used on low memory
>>> embedded systems, does this put any restrictions on the mandated
>>> syntaxes? I figure turtle because of prefixes would be no go, and other
>>> syntaxes too - the algorithm for webid validation (client code),
>>> including the parsers for all required syntaxes, would be best to have
>>> constant space complexity...
>>> I don't think such concerns nor the use case are so outlandish they
>>> shouldn't be taken in consideration.
>> I am trying to keep that in mind and keep in mind development for the freedombox.
>> Swap-scala from Dan Connolly seems to indicate that you can write parsers in very little
>> space for all the well known serialisations.
>>    http://code.google.com/p/swap-scala/
>> So there is a lot that can be done I think to reduce the space consumption of tools like Jena.
>> Henry
>>> Best,
>>> Jiri
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols@lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> Social Web Architect
>> http://bblfish.net/

Kicker here is "alienation of some set of syntax fans."

We can surmount this problem via HTML with a structured data island as 
the base. We are then left with HTML+Microdata, HTML+RDFa, and 
XHTML+RDFa as vehicles for the aforementioned base document type.

Methinks, most will use HTML+Microdata to publish due to the influences 
of search engine vendor appeasement. Remember, stuff goes on the Web to 
be discovered. For now, Google is extremely influential and important.



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Friday, 30 December 2011 21:54:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:28 UTC