[foaf-protocols] Using @rel to broaden scope of what we currently call FOAF+SSL
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
>> 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
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
> 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.
>> 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 Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
President & CEO
More information about the foaf-protocols