Re: Domain of :key

On 1 April 2013 21:16, Henry Story <henry.story@bblfish.net> wrote:

>
> On 1 Apr 2013, at 21:15, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
>
> On 1 April 2013 20:57, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 1 Apr 2013, at 20:49, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
>>
>> >
>> > On Mon 2013-Apr-01, at 14:12, Dominik Tomaszuk <ddooss@wp.pl> wrote:
>> >
>> >> In which point rdf:Resource is better than owl:Thing? I do some
>> ontology state-of-the-art and I don't see too much ontologies with uses
>> rdfs:Resource in rdfs:domain or rdfs:range. My conclusion to these
>> aproaches is that rdfs:Resource is used in low-level ontologies and cert
>> ont isn't in that level. Probably better consensus is owl:Thing.
>> >> Of course, I don't change my mind and I still think that foaf:Agent is
>> better.
>> >
>> > I'd contend that the cert ont _is_ (or at least, could easily be and
>> arguably should be) a low-level ontology: it exists to describe keys and
>> certificates. I don't see a sensible reason why the domain of the things
>> keys and certificates described by it are associated with shouldn't be as
>> broad as possible unless there's a good reason not to — and I'm at this
>> point not entirely understanding what that reason might be.
>>
>> Because there is a specific relation of agents to keys, such that the
>> agent is in control of the key.
>> This is what WebID needs.
>>
>> If you need another relation from a anything to a key, there are many
>> functions
>>
>> - rdfs:seeAlso
>> - rdfs:member
>> - xxx:signedWith
>> - xxx:encryptedWith
>> - xyz:myOwnerHasKey
>> - xdw:ILikeThisKeyButITsNotMine
>> - etc...
>>
>>
>> >
>> > I don't have a strong feeling on owl:Thing versus rdfs:Resource, except
>> that it's not particularly clear what benefit is derived from restricting
>> it to owl:Thing.
>> >
>> > There's a school of thought evident in this thread that one solution is
>> to define another ontology which is identical to the cert ontology except
>> for the domain of the things keys and certificates can be associated with.
>> I don't buy that — it breaks interop. While semweb is, as Kingsley says,
>> "fork friendly", there is still a cost associated with that (and in this
>> case it's divisiveness).
>>
>> The school of thought is that we have a use case for the relation we have
>> defined. It has been clearly
>> defined and we find it useful. You have not defined the use case for your
>> relation, or at least you
>> have only been handwaving in the direction.
>>
>> We may find that you don't need a new relation at all but that you can
>> compose it with other existing ones..
>>
>
>
> You've been given many use cases.  You are trying to dismiss arguments by
> labeling them 'handwavy'.
>
> I'll repeat one.  Facebook integration.  You dont have much of a social
> system if you design it to exclude facebook.
>
>
> We have not excluded Facebook here at all.
>
>
> The correct way is to include BOTH facebook and WebID not pick a winner.
> I say this is a bug, the onus is on you to come up with a convincing
> argument for exclusion.
>
>
> Well given that we have not excluded facebook I don't see that you have a
> point.
>

You may think so, but the last time I checked facebook were not using foaf
: Agent


>
>
>
>>
>>
>> >
>> > M.
>> >
>> > --
>> > Mo McRoberts - Analyst - BBC Archive Development,
>> > Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
>> > MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
>> > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
>> >
>> >
>> >
>> > -----------------------------
>> > http://www.bbc.co.uk
>> > This e-mail (and any attachments) is confidential and
>> > may contain personal views which are not the views of the BBC unless
>> specifically stated.
>> > If you have received it in
>> > error, please delete it from your system.
>> > Do not use, copy or disclose the
>> > information in any way nor act in reliance on it and notify the sender
>> > immediately.
>> > Please note that the BBC monitors e-mails
>> > sent or received.
>> > Further communication will signify your consent to
>> > this.
>> > -----------------------------
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>