Re: Domain of :key

On 29 March 2013 18:35, Henry Story <henry.story@bblfish.net> wrote:

>
> On 29 Mar 2013, at 18:32, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> On 29 March 2013 18:28, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 29 Mar 2013, at 18:24, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> On 29 March 2013 18:15, Henry Story <henry.story@bblfish.net> wrote:
>>
>>>
>>> On 29 Mar 2013, at 16:28, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On 29 March 2013 14:08, Henry Story <henry.story@bblfish.net> wrote:
>>>
>>>>
>>>> On 29 Mar 2013, at 13:35, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 29 March 2013 13:21, Henry Story <henry.story@bblfish.net> wrote:
>>>>
>>>>>
>>>>> On 29 Mar 2013, at 11:11, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 29 March 2013 11:01, Henry Story <henry.story@bblfish.net> wrote:
>>>>>
>>>>>>
>>>>>> On 29 Mar 2013, at 10:50, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 29 March 2013 10:41, Henry Story <henry.story@bblfish.net> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 29 Mar 2013, at 10:25, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 29 March 2013 09:52, Henry Story <henry.story@bblfish.net> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 29 Mar 2013, at 09:21, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29 March 2013 09:14, Henry Story <henry.story@bblfish.net>wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29 Mar 2013, at 08:53, Melvin Carvalho <
>>>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29 March 2013 08:37, Henry Story <henry.story@bblfish.net>wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 22 Mar 2013, at 10:42, Melvin Carvalho <
>>>>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Currently we have:
>>>>>>>>>>
>>>>>>>>>>     rdfs:domain foaf:Agent;
>>>>>>>>>>
>>>>>>>>>> This seems slightly restrictive.
>>>>>>>>>>
>>>>>>>>>> Many things can have a key, e.g. a certificate, an account, an
>>>>>>>>>> app etc.  Agent perhaps does not cover every conceivable use case?
>>>>>>>>>>
>>>>>>>>>>
>>>>>> We are not here to cover every conceivable use case. That would be
>>>>>> absolutely impossible to do.
>>>>>>
>>>>>>
>>>>>>>>>> You can create new relations to relate those things to keys if
>>>>>>>>>> you need to.
>>>>>>>>>>
>>>>>>>>>>   foaf:primaryTopic can relate a document keys it is about for
>>>>>>>>>> example.
>>>>>>>>>>
>>>>>>>>>> We need a relation to relate the agent that is the one that
>>>>>>>>>> controls the private key
>>>>>>>>>> of the public key to the public key, as that is what WebID
>>>>>>>>>> authentication and most
>>>>>>>>>> other protocols need to work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In bitcoin users have a pseudo anonymous account.  Each account
>>>>>>>>> has a key pair.  It would be great to be able to model this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why could one not think of an account as an Agent? It can transfer
>>>>>>>>> money, it can accept payments, etc... It is a micro agent related to you.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ah OK, if an agent can also be an account, that works.
>>>>>>>>
>>>>>>>>
>>>>>>>> It depends of course on what the bitcoint:Account thing is that you
>>>>>>>> are speaking of.
>>>>>>>> And one would need to  compare that to the definition of foaf:Agent.
>>>>>>>>
>>>>>>>> Say for sake of argument that you think of such an account more as
>>>>>>>> a bucket, in which you
>>>>>>>> can add money like you could add water to a bucket, and from which
>>>>>>>> you can remove money
>>>>>>>> as you could pour water out of a bucket into someone else's glass.
>>>>>>>> Here thinking of the bucket as
>>>>>>>> an Agent does not sound right.
>>>>>>>>
>>>>>>>
>>>>>>> This is a great analogy.  Each bitcoin account is like a bucket that
>>>>>>> contains 0 or more bitcoins.
>>>>>>>
>>>>>>> It makes no assumptions whatsoever about ownership.  Indeed, there
>>>>>>> need be no concept of ownership.
>>>>>>>
>>>>>>>
>>>>>>> There has to be a relation between an agent that knows the private
>>>>>>> key and can prove its ownership
>>>>>>> of that key, at least in so far as it signed the private key. That
>>>>>>> requires the relation between an agent
>>>>>>> and a key, which cert:key is about.
>>>>>>>
>>>>>>
>>>>>> cert : key can be used for this.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Then you can think of the access to the bucket as being restricted
>>>>>>>> to certain
>>>>>>>> agents. In which case you can use the Web Access Control vocabulary.
>>>>>>>>
>>>>>>>>  http://www.w3.org/wiki/WebAccessControl
>>>>>>>>
>>>>>>>> The wac ontology relates an Agent(a), a resource, and actions that
>>>>>>>> can be done on those
>>>>>>>> resources.
>>>>>>>>
>>>>>>>> So there are a number of ways of relating different things. One
>>>>>>>> does not need to use cert:key
>>>>>>>> for each of these ways of relating them.
>>>>>>>>
>>>>>>>
>>>>>>> It would be great if I could say
>>>>>>>
>>>>>>> <> a foaf : OnlineAccount
>>>>>>>   cert : key [ ... ]
>>>>>>>
>>>>>>> Independent of any ownership details.
>>>>>>>
>>>>>>>
>>>>>>> You can say that, but not with the cert:key relation. Changing the
>>>>>>> cert:key relation means
>>>>>>> we then have to change all the specs.
>>>>>>>
>>>>>>> I'd rather we now finish the specs as we have them, so that we can
>>>>>>> propose this to the
>>>>>>> W3C for a Working Group. BitCoin can then join that Working Group by
>>>>>>> proposing a clear
>>>>>>> use case, with an ontology that it is using, which can then be used
>>>>>>> to extend the ontology.
>>>>>>> This XG is past the end of its life time, and this is not the time
>>>>>>> to make drastic revisions.
>>>>>>>
>>>>>>
>>>>>> Yes totally agree we should move forward ASAP.
>>>>>>
>>>>>> I think this is a minor bug fix.  The cert ontology is not about
>>>>>> WebID it's about certificates and security.  We can fix it in the hg like
>>>>>> we quickly fixed some bugs earlier this week, and added DSA.
>>>>>>
>>>>>> Why do you think this is a drastic change, I dont think any
>>>>>> implementations need change?
>>>>>>
>>>>>>
>>>>>> Because we have defined a WebID as an identifier for an Agent, not an
>>>>>> identifier for any
>>>>>> resource. We have defined WebID auth over TLS as identifying an
>>>>>> Agent, that can prove
>>>>>> the private key of the public key. Here we now need to add new text
>>>>>> in every spec in order
>>>>>> to speak about accounts. We would then need to rework all these
>>>>>> specs.
>>>>>>
>>>>>
>>>>> I'm trying to follow the logic here.
>>>>>
>>>>> Let's consider Mo's proposal just to widen the range to something like
>>>>> rdfs : Resource
>>>>>
>>>>>
>>>>> A WebID can still be an agent, yes?
>>>>>
>>>>>
>>>>> yes.
>>>>>
>>>>
>>>> good
>>>>
>>>>
>>>>>
>>>>> The problem is that you need to define how for some object X you
>>>>> relate it to the private key.
>>>>> In order to distinguish your definition from the current one, so that
>>>>> we don't have misunderstandings
>>>>> let us call your relation mlv:key .
>>>>>
>>>>> mlv:key a rdf:Property;
>>>>>      rdfs:domain rdfs:Resource;
>>>>>      rdfs:range cert:Key .
>>>>>
>>>>
>>>> fine
>>>>
>>>>
>>>>>
>>>>> Now that means I can relate any object to a key. For example why could
>>>>> I not take the Eiffel Tower,
>>>>> and write:
>>>>>
>>>>>      dbpedia:EiffelTower mlv:key <
>>>>> http://bblfish.net/people/henry/card#key1> .
>>>>>
>>>>
>>>> why could you not?  you just did
>>>>
>>>>
>>>> Indeed you can. So if you want you can publish the mlv:key ontology in
>>>> your namespace.
>>>> Perhaps it will get traction.
>>>>
>>>> The point of writing ontologies for reasoning is that you don't just
>>>> stop at that point.
>>>> You can relate anything to anything by some relation.  The problem is
>>>> distinguishing your
>>>> mlv:key relation from every other relation. What distinguishes it from
>>>>
>>>> mlv:loves
>>>> mlv:saw
>>>> mlv:wantToOwn,
>>>>
>>>> etc...  You need to do the work of defining it. And when you do that
>>>> you'll start seeing that
>>>> your problems start building up, as shown below.
>>>>
>>>
>>> Please reread what you wrote.  First you said you can not, now you say
>>> you can.  This makes little sense.
>>>
>>>
>>> I am developing the consequences of your proposal. mvn:key does what you
>>> want.
>>> But does it do what WE need it to do? My argument is that it does not
>>> make things simpler
>>> as you claimed it does. In fact it raises a whole bunch of issues, and
>>> puts work on our
>>> plate for a benefit that is completely hypothetical.
>>>
>>
>>
>> As I said, please reread your sentences, they dont make sense.  I suspect
>> you have typoed something somewhere.
>>
>>
>> Please just define mvn:key put it up somwhere and then we can discuss.
>>
>>
>>
>>>>
>>>>> Good so now what kind of relation is that? What is the relation of the
>>>>> private key to the Eiffel
>>>>> tower that we need in order to prove cryptographically the identity of
>>>>> a user of the key? You
>>>>> want some kind of way of limiting what objects you can truthfully add
>>>>> the cert key relation to,
>>>>> otherwise it is meaningless.
>>>>>
>>>>
>>>> eiffel tower has a public key ... not sure it's problematic
>>>>
>>>>
>>>> What does it mean for the eiffel tower to have a public key? Do you
>>>> mean it's written on it? Do you
>>>> mean you would like it to have one? Do you mean it can sign documents
>>>> with it ( in which case it's an
>>>> agent, and the problem does not arise )
>>>>
>>>
>>> Eiffel Tower   "has" key ... [ pubkey ]
>>>
>>> just like <#hjs>  "has" name "Henry Story".
>>>
>>> It's your example, you can decide what it means.
>>>
>>> What is the purpose of your example, are you trying to raise a counter
>>> example?
>>>
>>>
>>> I am developing YOUR example. You are the one in charge of the meaning
>>> of mlv:key .
>>> So it is up to you to tell me what it means. I don't know what it means
>>> for the eiffel tower
>>> to have a public key. Or I don't know what to make of that information.
>>> I don't know how
>>> I would decide if it were true or false for example. Ie: the meaning of
>>> that statement is not
>>> clear.
>>>
>>
>>
>> mlv : key and eiffel tower are your examples
>>
>> you seem to have constructed a triple that is either non nonsensical or
>> ambiguous
>>
>> unsure what this proves
>>
>>
>> dbPedia:EiffelTower mlv:key key .
>>
>> is a sentence that your ontology allows since the domain is anything. So
>> what would it mean
>> for a shoe, the eiffel tower, or an atom to have a key? How would I know
>> it is true or if it is false?
>>
>
> there's probably an uncountable number of triples that are ambiguous or
> nonsensical
>
> what does it mean for a rainbow to have a smile?
>
>
> We are not trying to develop ontologies here to write poetry.  That sounds
> like a fun exercise,
> but for another list.
>

Read tim's 'working without being hijacked by ambiguity' ... you brought in
the eiffel tower having a private key.  Why?

People are trying to work, not consider esoteric ambiguous edge cases.


>
>
> isnt it an exercise for the reader?
>
> you can use the sem web to write nonsense, that can never be forbidden,
> what does it prove?
>
>
> So why do you say it is nonsense for the Eiffel Tower to have a key? How
> would I know that
> it is rather than not?
>

I'm just unsure what point you are trying to prove by trying to contruct
sentences which dont, on the surface make much sense.

If you're trying to raise a point, please explain if there's an objection.

I've introduced a non breaking change, which in my view is a bug, if
something breaks, please do say so.

Else we can just reach a consensus and move forward.


>
>
>
>
>>>>> Perhaps I need a relationship of ownership to the EiffelTower to be
>>>>> able for the relation to the
>>>>> agent to work?  Perhaps
>>>>>
>>>>> mlv:owns a owl:InverseFunctionalProperty;
>>>>>     rdfs:comment """
>>>>>        an agent that owns according to all legal system the object.
>>>>>        (If we add relativity to a legal system things get more
>>>>> complicated)
>>>>>     ";
>>>>>     rdfs:domain foaf:Agent;
>>>>>     rdfs:range rdfs:Resource .
>>>>>
>>>>> So then we would have the rule
>>>>>
>>>>> { ?agent mlv:owns ?thing . ?thing mlv:key ?key } => { ?agent cert:key
>>>>> ?key } .
>>>>>
>>>>> So your "simplification" in fact is going to create more complexity
>>>>> elswhere.
>>>>> You could argue that when the ?thing is an agent it owns itself
>>>>> perhaps, and
>>>>> so that in that case it should fall out through reasoning. But now we
>>>>> have
>>>>> introduced an "if x is an Agent then do Y else do Z" into our code
>>>>> everywhere,
>>>>> and we need to specify everywhere that people have to write out for
>>>>> anything
>>>>> they put a mlv:key on that they need to specify that it is a
>>>>> foaf:Agent.
>>>>>
>>>>
>>>> Are you saying that people are making inferences on the :key relation
>>>> to assume the subject is an agent, and that, that is your objection?
>>>>
>>>>
>>>> Yes, that is the whole point of cert:key. It relates the agent who
>>>> controls the key to the
>>>> key. That is why this relation is useful to use in the WebID/TLS spec.
>>>>
>>>
>>> OK got it.
>>>
>>> So you need to make the case that this inference is important.  I dont
>>> think it is.
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> ie: you can't put:
>>>>>
>>>>> <#me> mlv:key key.
>>>>>
>>>>>     you need to write
>>>>>
>>>>> <#me> a foaf:Agent;
>>>>>           mlv:key key .
>>>>>
>>>>
>>>> surely this is good practice anyway, a subject should specify a type,
>>>> we do think in JSON-LD with @type, for example
>>>>
>>>> is this your objection?
>>>>
>>>>
>>>> I am just listing all the ways in which your "simplification" is
>>>> increasing complexity.  This is one
>>>> of them.
>>>>
>>>> The other that you ignored is that our code is now bifurcated, into
>>>>  "if x is an Agent then do Y else do Z ( find the mlv:owns
>>>> relationship(s?) to x )"
>>>>
>>>
>>> Branching on type is quite normal.  You would not treat a person the
>>> same way as you would a building.  What you are suggesting is to infer the
>>> type from the predicate, in the event that it is missing.  This seems like
>>> a) an edge case b) bad practice so I dont think it's relevant unless you
>>> have evidence otherwise
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> And none of this yet prooves that your hypothetical bitcoin example
>>>>> would not be
>>>>> better off with the cert:key relation.
>>>>>
>>>>
>>>> sure, but does not make the question invalid
>>>>
>>>>
>>>> It does. Because you are asking us to do a lot of work here, for some
>>>> hypothetical
>>>> work you may want to do in the future, but which you have not bothered
>>>> doing,
>>>> and for which you have no clear support.
>>>>
>>>
>>> Who's "us" ... this is a community group.  You have a subjective view
>>> that it's a lot of work, it's a two line change.  I can write the turtle or
>>> this.  We just need a streamlined process for updating a vocab, in line
>>> with consensus, so we can be agile.
>>>
>>>
>>>>
>>>> If Bitcoin comes to the table and helps us form a Working Group then we
>>>> can
>>>> look at this in detail. But without them here, it is a waste of time to
>>>> guess what they
>>>> could be wanting.
>>>>
>>>
>>> As I have explained to you, bitcoin is not an organization.  It's a
>>> decentralized accounting system and currency.  The whole point of bitcoin
>>> is that there is no central point of control.  So your statement of binging
>>> bitcoin to the table, doesnt make much sense.
>>>
>>>
>>> Well perhaps someone developing an ontology for bitcoin, and developing
>>> the use cases where they
>>> would use the ontology, would be useful. Your brought bitcoin to the
>>> discussion as an important use case.
>>> Then you said that they NEED your relation. I don't know why they would
>>> need that relation rather than
>>> another one. For that you'd need a lot more work on developing the
>>> bitcoin use case.
>>>
>>
>> Well this is the second time it's been attempted to use webid and
>> payments together.  Payswarm was the first and they gave up, now we have
>> the cert ontology and the sec ontology as a result:
>>
>> http://payswarm.com/specs/source/vocabs/security#publicKey
>>
>> Perhaps we will have a third public key definition if you want to tightly
>> bind the idea of a public key to WebID via the "key" predicate.  The terms
>> "key" and "agent" are need not be closely coupled, but I can see why you
>> may want to do that.
>>
>> As usual I'll go with the consensus, and if that means building new
>> instead of reusing, we can just have (yet) another vocab.
>>
>>
>>>
>>> And this is without mentioning that I still don't know what it means for
>>> the Eiffel Tower to have a key.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> For reference currently we have:
>>>>>
>>>>>   119 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l119> :key a owl:InverseFunctionalProperty;
>>>>>
>>>>>    120 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l120>     vs:term_status "unstable";
>>>>>
>>>>>    121 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l121>     rdfs:label "key"@en;
>>>>>
>>>>>    122 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l122>     rdfs:isDefinedBy <cert#>;
>>>>>
>>>>>    123 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l123>     owl:inverseOf :identity;
>>>>>
>>>>>    124 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l124>     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
>>>>>
>>>>>    125 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l125>     rdfs:domain foaf:Agent;
>>>>>
>>>>>    126 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l126>     rdfs:range :Key, :PublicKey .
>>>>>
>>>>>
>>>>> ( It should say something about the control the agent has over the
>>>>> corresponding private key .
>>>>>   A previous version had that text in there. We seemed to have lost
>>>>> it.)
>>>>>
>>>>>
>>>>>
>>>>> Why do you feel the webid spec would be forced to change.  Would
>>>>> leaving the text the same introduce a bug or inaccuracy?  My suggestion is
>>>>> to leave the webid specs the same.
>>>>>
>>>>>
>>>>>>
>>>>>> The WebAcessControl implementations and ontologies also need to be
>>>>>> reworked sine
>>>>>> they are working in terms of agents.
>>>>>>
>>>>>
>>>>> Why would WAC implementations need change?  Im unsure this is
>>>>> inaccurate.  Again I propose leaving implementations untouched.
>>>>>
>>>>>
>>>>>>
>>>>>> So you are asking us to revise something for a use case you call
>>>>>> bitcoin for which we have
>>>>>> no idea how they would write up their ontology, if they even need
>>>>>> what you suggest they may
>>>>>> need, etc... It's a lot of hypotheticals for something that is easy
>>>>>> to add later with a new relation,
>>>>>> or for which they may in fact be satisfied with what we have.
>>>>>>
>>>>>
>>>>> This is not use case driven.  I gave an example.
>>>>>
>>>>>
>>>>> You gave a use case yes. We don't know if the use case is best
>>>>> modelled the way
>>>>> you are thinking of modelling it. That would require people to work on
>>>>> the bitcoin model
>>>>> in detail, and they could end up being satisfied with the cert:key as
>>>>> it is now.
>>>>>
>>>>> I think you need to prove that this cannot be the case.
>>>>>
>>>>>
>>>>> I repeat I think it's a bug in the cert ontology that would come up in
>>>>> an XG or WG.
>>>>>
>>>>> I may be wrong but I thought this was a simple fix.
>>>>>
>>>>>
>>>>> It looks simple, but it creates complexity elsewhere.
>>>>>
>>>>
>>>> I'm still trying to work out where (if at all) ... we're getting closer
>>>> it seems.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> This is a lot of work, and until bitcoin is really sitting at the
>>>>>> table, which they will only do
>>>>>> as part of a WG then we are just speaking hypothetically.
>>>>>>
>>>>>
>>>>> It need not be a lot of work.  Bug fixes in specs should have a fast
>>>>> turn around.
>>>>>
>>>>>
>>>>> It is a hypothetical bug. You have suggested a modelling need for
>>>>> bitcoin. But there has
>>>>> been no scrutiny of this. There cannot be: since the work has not been
>>>>> done. And the work
>>>>> of doing this is not something that can be done on the back of an
>>>>> envelope in 5 minutes.
>>>>>
>>>>
>>>> If I can clarify the situation it will be possible to build a proof of
>>>> concept.  Running code is always a help in achieving consensus.
>>>>
>>>> In short, I'm unsure you've raised a compelling objection, base on any
>>>> concrete cases.
>>>>
>>>> So far on this thread there's
>>>>
>>>> in favour of rdfs : Resource +2
>>>> In favour of foaf : Agent +1
>>>>
>>>>
>>>>>
>>>>> Henry
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> So rather than do that, let's finish the specs, and get momentum for
>>>>>> a Working Group.
>>>>>>
>>>>>> henry
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Henry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It's perhaps the most serious use of PKI on the web after
>>>>>>>>> ecommerce.
>>>>>>>>>
>>>>>>>>>
>>>>
>>>> Yes, but it does not follow that your idea of how to model their
>>>> problem is the right one.
>>>>
>>>
>>>
>>> Fair enough, but I think I have enough now to start working.  Once you
>>> see agents making payments you may change your mind.
>>>
>>> You seem to be resistant to even slight changes in the cert ontology
>>> (which I had thought was a community effort).  This does indeed make me
>>> think that using something else such as the sec ontology and/or making my
>>> own makes more sense.
>>>
>>> We can just raise the domain of cert : key ( foaf : Agent or rdfs :
>>> Resource )  with the group and reach a consensus.
>>>
>>>
>>>>
>>>>
>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is the parent of Agent an owl : Thing?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     Social Web Architect
>>>>>>>>>> http://bblfish.net/
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>>
>>>     Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>     Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>