[foaf-protocols] Using @rel to broaden scope of what we currently call FOAF+SSL

Kingsley Idehen kidehen at openlinksw.com
Thu May 13 19:57:23 CEST 2010


Story Henry wrote:
> On 13 May 2010, at 18:04, Kingsley Idehen wrote:
>
>   
>> Nathan wrote:
>>     
>>> Story Henry wrote:
>>>       
>>>> On 13 May 2010, at 17:40, Kingsley Idehen wrote:
>>>>
>>>>         
>>>>> I think you are missing my fundamental point.
>>>>>
>>>>> This is an option.
>>>>>
>>>>> An option is but one item in a contimuum.
>>>>>           
>>>> As I said in the other thread, we don't have a lot of people.
>>>> Much more important is to get this accepted by a standards body.
>>>>
>>>> I think we should proceed on with that next.
>>>>         
>>> +infinite 1's
>>>
>>>       
>> Henry,
>>
>> I am not really asking anyone to implement anything.
>>
>> I am saying: how about this approach? I can implement this protocol with the increased implementation dexterity that I seek. It just so happens that I do tend to want to share my thinking with others too.
>>     
>
> A protocol with just one implementation is not that interesting. 
>   

Still crossing wires.

I am not describing a protocol in the context you are dealing with right 
now. Isn't FOAF+SSL a protocol, in this context?

I am talking about the location and discovery of the data that serves 
the protocol.

And most important of (one more time), nobody has to implement 
anything.  Those FOAF+SSL implementations that are purely about FOAF and 
SPARQL are fine. Nothing stops implementations of the same protocol 
offering lower activation thresholds should they choose.


> As I said I don't think this is solving any issues I encounter in the wild as I give talks around.

This is really why I do prefer to implement and explain, rather than 
suggest and then implement.

For now. Just live as is.

I don't break things, I enhance them. But, I typically would demonstrate 
the enhancement rather that talk and debate it.


>  It will just make things more complex, and take us further away from growing our WebId deployment.

Exactly, simplicity has become complexity, because we are now have a 
conversation that has completely broken context.
>  It will be more testing.
>
> There are so many other things we can do.
>   

Yes, like doing the things you want to do.

I was sharing an idea that I have in mind that I'll more than like have 
implemented.

> For me: finish implementing foaf+ssl on myxwiki, working on ping, better documentation, standard tracks, implementing in more apps, simple access control, develop real test suites, ...
>
> For you: get it to work better with your platform, so that I can click a button and have the same effect as on foaf.me at least, or better integration. 
>   

Your issue will soon be resolved. It has no bearing on this matter 
though. The problem is in the RDFa parser which has been fixed and 
making its way out etc..
>   
>> Goal: get more IDs out there.
>>
>> Approaches:
>>
>> 1. A few implementors (that can process RDF data representations) generate a lot of IDs
>> 2. Many people (including the "No RDF in any guise" crowd) implement IDs (because implementation threshold is low).
>>     
>
> We can give them a standard template to add to their HTML. 
Don't dispute that, this was one of the bootstrap patterns I worked on 
with Martin Hepp re. GoodRelations, and recently we felt even that 
wasn't low enough re. activation threshold.  I am sure you've seen how 
many HTML+RDFa cookbooks associated with GoodRelations.

Even worse, the opengraph folks receive a chunk of RDFa that only 
required pasting into a <div/> within <body/> and as of this time, their 
HTML page hasn't been updated etc..

But most important of all, I offered a suggestion. Validity or 
invalidity of its merits is something that plays out over time etc..

> That would work just as well. And it would not take long to develop.
>   

I don't know what you feel needs to be developed here? That said, it 
doesn't matter right now. There's an option out there that nobody needs 
to implement or use :-)


Kingsley
> Henry
>
>   
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	      President & CEO OpenLink Software     Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen 
>>
>>
>>
>>
>>     
>
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 







More information about the foaf-protocols mailing list