Re: Cert Ontology and WebKeys (Re: WebID History - is also: Webid Editor/Author issue)

On 3 Jun 2013, at 10:18, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 3 June 2013 10:02, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 3 Jun 2013, at 09:26, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> >
>> > 1. http://news.cnet.com/8301-1023_3-57481166-93/oauth-2.0-leader-resigns-says-standard-is-bad/ -- what I think Henry is concerned about (also triggered my questions to Manu about his WebID criticisms)
>> 
>> yes. Small is beautiful.
>> 
>> I have not looked at Manu's work because I am overwhelemed with work myself, and I am sure he is too.
>> 
>> I appreciate that you have limited time, but I think it would be more positive for the group, to make sure the current specs are maintained and published than to go chasing authorship issues.
>> 
> 
> And I would appreciate if after years following this work you started learning a just bit of semantic web basics, so 
> that we don't have to spend weeks pointing out to you obvious things such as to list a few from the recent past:
> 
>  -  our spec is not inconsistent with giving keys URI (as you argued recently in this thread)
>  - your attempt to argue for weeks that we should loosen the relation between webids and keys
> 
> I didnt argue that.  I said there is a gap between the theoretical and the practice.  Case in point, your own webid does not have a URI.
> 
> Axiom zero : "Any resource of significance should be given a URI."
> 
> http://www.w3.org/DesignIssues/Axioms.html
> 
> I suggested that we try and guide people towards this axiom.  The vast majority of webids that I see do NOT have a URI.  My argument was to have a SHOULD, which allows the flexibility we still have.

 But as you see there is no reason for the WebID-TLS protocol to put that SHOULD. So we don't. If another protocol
comes along and has a need for it as I pointed out then they can make it a SHOULD. Public keys can be thought of
as similar to literals using owl keys furthermore, so there is no reason for us to make this a MUST.

Perhaps later when we have a reason: don't constrain without reason.

>  
>  - and more below
> 
>> But I think
>> he is writing an ontology for keys and signatures. He seems to be putting a lot of work into that, and modulo
>> the need for us to have a inverse functional relation from a WebID to a key ( and not documents to keys ), I'd be very happy
>> if we could re-use his work. Perhaps there is space next to the cert ontology for manu's keys ontology,
>> or perhaps it can just be merged into cert. And of course there Manu would be author and editor.
>> 
>> WebKeys has some significant advantages to the cert ontology in many ways, as the cert ontology only does auth, but the webkeys ontology does auth / signing / encryption / verification and lays the way for payments.  
>> Cert only allows a subset of keys, such as RSA (indeed RSA is the only implemented key in WebID+TLS), webkeys allows any key, including DSA, Elliptic curve etc.  
> 
> Very good. I knew Manu or someone else was going to do this, so there was no reason for us to waste too much time on it too.
> Small is beautiful, we can re-use the best work.
> 
> that's great but it means changing the implementations 

Well if Manu wants to put his ontology in the cert namespace, as I said, and we review it then well
everyting would be fine. It's up to him.
>  
> 
>> 
>> Webkeys allows any type of profile, including FOAF, schema.org, open graph protocol etc. whereas cert is tied to FOA
> 
> We have told you for months now that this is nonsense, so please stop making a fool of yourself, by repeating
> it. Your point above reveals your complete lack of understanding of the semantic web. Kingsely Idehen and others have
> pointed out to you that { foaf:Agent owl:equivalentClass other:Agent } makes it easy to switch between different 
> ontologies. 
> 
> Im talking about the current cert ontology.  There are possible solutions, but until then, you cant claim it's fixed.

There is no bug here: that is what you have trouble understanding. So there is no need for a fix. Whatever Agent
class you take someone could argue that there is another Agent class that is better. foaf:Agent seems good enough
at present.

>  
> 
>> Webkeys allows associating a key with an account, whereas cert only associates a key with a FOAF agent.
> 
> You mean WebKeys has a relation from a document to a key. Good. 
> WebID *needs* the relation from a WebID to a key, which we called cert:key .
> 
> There is no incompatibility here.
> 
> Again you are talking about a theoretical fix, not the current state of affairs.  

Well we'd need to look at the use case of linking a page to a key. We have not 
found a use case for it.

> 
>> 
>> These points have been brought up in the community group and you have each argued against them, and made it clear that you were opposed.
> 
> yes, I argued that clearly for WebID we need the cert:key relation. I never argued that other relations could not
> be used ( though they would not express necessarily what we *NEED* )
> 
>>   That's why manu did not join the xg, and has made an independent work
> 
> Manu has his reasons for not joining the WebID XG as he had other needs. It is good that he has 
> done independent work too. There was already enough noise on this mailing list, without
> two communities that want to do different things stepping on each others toes.
> 
>> That all said, done is done, and it would be good to see things working together now.
> 
> The beauty about the semantic web is that we can work seperately from Manu and still have the results 
> be compatible. But one could help make things easier to understand for newbies like you by
> putting things into a namespace on the W3C and having it be blessed by going through 
> the W3C process. That seems to me something for a WG. 
> 
> Henry, I honestly dont mind, but why do you have to make things personal.  I'm not trying to waste your time, the points I have made are accurate.  There are theoretical fixes, but they are not there at this point.  Things take time in this group, it's been going 5+ years and webkeys only 1-2 years.  Im simply comparing like for like.

You are saying certain things are needed, such as a link between a page and a key. But you never specify 
what type of relation what the meaning of it is. WebID over TLS does not need such a relation as we
have demonstrated by working very well in many implementations. There may be other use cases where
it is needed but you never made clear what they were. And since between any two things there are an infinite
number of relations you can create defining the required relation through a use case is very important.

What I do think is needed is to extend our ontology for the other crypto algorithms. 

Henry

> 
>> 
>> It seems that putting something like this into the W3C name space would be very useful.
>> 
>> >
>> > 2. http://twitter.com/kidehen/status/339748133468786688 -- How to resolve conflicts based on terminology and meaning.
>> >
>> > --
>> >
>> > 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
>> >
>> >
>> >
>> >
>> >
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/