Re: Mandatory client supported serializations

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.


-- 

Regards,

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