Inconsistency in base class of opo:SharingSpace and redundancy between opo:declaredBy and opo:declaredOn
Nikola Milikic
Since I was recently experimenting with OPO in a project, I noted some possible inconsistencies and redundancy. The issues are next:
- One opo:OnlinePresence instance you can dedicate to an instance of opo:SharingSpace, e.g. a group of your friends through property opo:intendedFor. The range is opo:SharingSpace, which is a subclass of foaf:Group. But actually, you are not sharing your presence to a group of friends (foaf:Agent), but with their accounts, e.g. only through their accounts your friends can see your presence. So, I think that SharingSpace should actually be a subclass of a sioc:UserGroup, which has_member in range of sioc:UserAccount. Or the property opo:intendedFor should have for its range sioc:UserGroup, if opo:SharingSpace doesn't have any specifics on its own (does it?).
- The other thing that occurred to me is that I think that property opo:declaredBy (with range foaf:Agent) is somehow redundant with opo:declaredOn (with range sioc:UserAccount). They are both describing the one who crated the OnlinePresence. But again, similarly as in previous issue, I think that a user (or more specifically an agent, foaf:Agent) is not declaring directly his OnlinePresence, but rather he is doing it through his account on some Instant Messaging service or Social Network. So, I think that the property opo:declaredOn is more correctly (and only) to be used and a connection with an agent (foaf:Agent), the holder of an account, is already established via foaf:account property (or its inverse property sioc:account_of).
I have already discussed this with Alexandre Passant, and he generally agrees with this and suggested posting the issues here to discuss more.
I would like to hear your comments on this and the implications of potential changes in the ontology design. And the changes might be:
1) to change the base class of opo:SharingSpace to sioc:UserGroup, and
2) to deprecate the use of opo:declaredBy property. Actually, as Alex suggested, name opo:declaredBy is more intuitive than opo:declaredOn (which maybe more implies to a device or similar), so the other solution for this issue is to deprecate the use of opo:declaredOn and to change the range of opo:declaredBy to sioc:UserAccount.
Regards,
Nikola Milikic
Email: nikola....@gmail.com
URL: nikola.milikic.info
Milan Stankovic
- One opo:OnlinePresence instance you can dedicate to an instance of opo:SharingSpace, e.g. a group of your friends through property opo:intendedFor. The range is opo:SharingSpace, which is a subclass of foaf:Group. But actually, you are not sharing your presence to a group of friends (foaf:Agent), but with their accounts, e.g. only through their accounts your friends can see your presence. So, I think that SharingSpace should actually be a subclass of a sioc:UserGroup, which has_member in range of sioc:UserAccount. Or the property opo:intendedFor should have for its range sioc:UserGroup, if opo:SharingSpace doesn't have any specifics on its own (does it?).
- The other thing that occurred to me is that I think that property opo:declaredBy (with range foaf:Agent) is somehow redundant with opo:declaredOn (with range sioc:UserAccount). They are both describing the one who crated the OnlinePresence. But again, similarly as in previous issue, I think that a user (or more specifically an agent, foaf:Agent) is not declaring directly his OnlinePresence, but rather he is doing it through his account on some Instant Messaging service or Social Network. So, I think that the property opo:declaredOn is more correctly (and only) to be used and a connection with an agent (foaf:Agent), the holder of an account, is already established via foaf:account property (or its inverse property sioc:account_of).
--
You received this message because you are subscribed to the Google Groups "Online Presence" group.
To post to this group, send email to online-...@googlegroups.com.
To unsubscribe from this group, send email to online-presen...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/online-presence?hl=en.
Alexandre Passant
On 14 Jul 2010, at 10:46, Milan Stankovic wrote:
> Hi Nikola,
>
> Thanks for starting a discussion, and taking time to think about opo design.
>> - One opo:OnlinePresence instance you can dedicate to an instance of opo:SharingSpace, e.g. a group of your friends through property opo:intendedFor. The range is opo:SharingSpace, which is a subclass of foaf:Group. But actually, you are not sharing your presence to a group of friends (foaf:Agent), but with their accounts, e.g. only through their accounts your friends can see your presence. So, I think that SharingSpace should actually be a subclass of a sioc:UserGroup, which has_member in range of sioc:UserAccount. Or the property opo:intendedFor should have for its range sioc:UserGroup, if opo:SharingSpace doesn't have any specifics on its own (does it?).
> I cannot fully agree with this. From the user study we did last year, we concluded that people have a need to share certain information with certain persons ( they do not want their mother to see a status message meant for their friends) and we did not find a need to specify the exact account ( i.e. our subject did not seem to care what account their mother was using - they just wanted her out).
>
> Since OPO is designed for interoperability and for cases where one presence instance is shared on several networks, i beleive that using Agents to define sharing spaces ( audience ) is more practical then using their ( many) accounts. This is just my first oppinion, i of course remain open for discussion. Play say if you still think UserGroup is better.
Let's think of the following use-case:
During day-time, I do not want to send my personal messages to your professional account (e.g. your Jabber client) but want to send them to your personal account (e.g. Skype).
This is something I cannot do with the current foaf:Agent modelling, since the SharingSpace will be at your Person level, not the account one.
On the other hand, with the proposed change, I will be able to do that.
The trade-off is indeed that if I want to block you completely, I have to specify I want to block all your account - but I guess that's a minimal effort (ideally one SPARQL query to retrieve all your account, and we can imagine that user-interfaces will provide such capabilities), but I'd rather have a solution that provides the aforementioned use-case.
>
> I agree with you that not having a way to include just an account ( and not all the accounts of the agent ) is an issue. IMO we should enable this without eliminating the possibility for agents to be in a sharing space.
>
> ps. Yes opo:SharingSpace does have its own properties that allow to automatically create a sparql query to select the members of the sharing space.
So, can we say that the query is all accounts of person X ? Might allow to (1) make the proposed change so that restriction can be done at the UserAccount level and (2) provide means to define restriction at the foaf:Person level
>
>
>> - The other thing that occurred to me is that I think that property opo:declaredBy (with range foaf:Agent) is somehow redundant with opo:declaredOn (with range sioc:UserAccount). They are both describing the one who crated the OnlinePresence. But again, similarly as in previous issue, I think that a user (or more specifically an agent, foaf:Agent) is not declaring directly his OnlinePresence, but rather he is doing it through his account on some Instant Messaging service or Social Network. So, I think that the property opo:declaredOn is more correctly (and only) to be used and a connection with an agent (foaf:Agent), the holder of an account, is already established via foaf:account property (or its inverse property sioc:account_of).
>
> This is interesting. In general i do not think redundancy is such a big deal - if people can provide you with data in several ways, and you can retrieve it using only one way ( through the use of subclasses and subproperties). But you have a point that this declaredOn is ugly :)
:-)
>
> Let's do as you suggest, but then let's also create an owl2 property chain to define that if an agent hasonlineAccount sioc_user and the presence is declaredBy the user , then infer that agent declares presence.
+1
What would be the name of this property ? opo:declaredByPerson ?
>
> DeclaredBy was designed as a convenience property ( mostly for RDF/XML) , so that you don't have to define agent first and use declaresPresence, but you can start from an OnlinePresence instance and specify the declaringAgent from it. Having in mind how inperfect the real data on the web is ( missing author data in blogs, reserach publications etc) i think that having such convenience properties is not bad. We can call them differently ( maybe intoduce declaringAgent instead of declaredBy, and use declaredBy for the sioc:User as you suggested)?
>
I'm also ok to have declaredBy with sioc:UserAccount.
Regarding the naming, I'd prefer to keep a similar naming (with a By, rather than -ing) for consistency.
We can also have declaredByUser and declaredByPerson.
Any preference ?
Talk soon,
Alex.
--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Nikola Milikic
>> - One opo:OnlinePresence instance you can dedicate to an instance of opo:SharingSpace, e.g. a group of your friends through property opo:intendedFor. The range is opo:SharingSpace, which is a subclass of foaf:Group. But actually, you are not sharing your presence to a group of friends (foaf:Agent), but with their accounts, e.g. only through their accounts your friends can see your presence. So, I think that SharingSpace should actually be a subclass of a sioc:UserGroup, which has_member in range of sioc:UserAccount. Or the property opo:intendedFor should have for its range sioc:UserGroup, if opo:SharingSpace doesn't have any specifics on its own (does it?).Let's think of the following use-case:
> I cannot fully agree with this. From the user study we did last year, we concluded that people have a need to share certain information with certain persons ( they do not want their mother to see a status message meant for their friends) and we did not find a need to specify the exact account ( i.e. our subject did not seem to care what account their mother was using - they just wanted her out).
>
> Since OPO is designed for interoperability and for cases where one presence instance is shared on several networks, i beleive that using Agents to define sharing spaces ( audience ) is more practical then using their ( many) accounts. This is just my first oppinion, i of course remain open for discussion. Play say if you still think UserGroup is better.
During day-time, I do not want to send my personal messages to your professional account (e.g. your Jabber client) but want to send them to your personal account (e.g. Skype).
This is something I cannot do with the current foaf:Agent modelling, since the SharingSpace will be at your Person level, not the account one.
On the other hand, with the proposed change, I will be able to do that.
The trade-off is indeed that if I want to block you completely, I have to specify I want to block all your account - but I guess that's a minimal effort (ideally one SPARQL query to retrieve all your account, and we can imagine that user-interfaces will provide such capabilities), but I'd rather have a solution that provides the aforementioned use-case.
I actually agree on arguments of both of you. I think that you should be able do dedicate a presence to both a group of persons and a group of user accounts. I think that it will be difficult for one GUI to support both grouping of persons and grouping of accounts (or maybe not), but OPO should maybe support both.
For now, it is more probable for one Instant Messenger (IM)/Social Network (SN) provider to use OPO to model his users, their presences, groups... through their user accounts inside that service, so it could maybe benefit from e.g. suggestions regarding to his location, social graph, activities, etc. So, I think that ontology model should support all relevant concepts that can occur inside one system. But more idealistic goal of OPO project is to enable interoperability between different services. And I think that in order to achieve this, we would need to have single IM/SN providers to use OPO in their own systems and have all accounts, presences, groups etc. described using relevant ontologies (FOAF, SIOC, OPO...) and if they decide to open that (or some of that) data for interchange with other systems, than the idea of data portability could emerge and OPO and other ontologies can reach their full potential.
Maybe I went being too abstract in arguments on this and we just need a couple more examples to test both solutions.:)
> Let's do as you suggest, but then let's also create an owl2 property chain to define that if an agent hasonlineAccount sioc_user and the presence is declaredBy the user , then infer that agent declares presence.
+1
What would be the name of this property ? opo:declaredByPerson ?
I agree on this! I like property chains.:).
> DeclaredBy was designed as a convenience property ( mostly for RDF/XML) , so that you don't have to define agent first and use declaresPresence, but you can start from an OnlinePresence instance and specify the declaringAgent from it. Having in mind how inperfect the real data on the web is ( missing author data in blogs, reserach publications etc) i think that having such convenience properties is not bad. We can call them differently ( maybe intoduce declaringAgent instead of declaredBy, and use declaredBy for the sioc:User as you suggested)?I'm also ok to have declaredBy with sioc:UserAccount.
>
Regarding the naming, I'd prefer to keep a similar naming (with a By, rather than -ing) for consistency.
We can also have declaredByUser and declaredByPerson.
Any preference ?
Alex's suggestions are ok, but maybe we could adjust a bit the name of property towards faof:Agent to correspond to the name of the range of that property and call it opo:declaredByAgent. Because, who knows, maybe in a few years time my laundry machine, i.e. agent representing it, will also be able to declare that it is available.:D
Best,
Milan Stankovic
Alex i think your agruments are good, and the use case is important. I would agree with proposal. But, as soon as you think we have a decision, there is a third possibility:) We could just delete the subclassOf foaf:Group and leave SharingSpace as separate class. Using multiple inheritence that is allowed in owl, an insrance could at the same time be a sharingSpace and a Group or a UserGroup. As sharing space serves primarly to provide an URI for the corresponding sparl query/ rule that defiens it, this could be resonable and flexible. But if you find problems with this solution, then it is better to go with UserGroup then Group.
As for the naming we could have declaredByUser and declaredByAgent ( where the later is owl2 property chain). @Nikola - good point for the laundery machine!
Btw: the usecase for presence of washing machines is good. In Paris there are many laundery self services, where knowing the availability of machines is crucial for time saving :) You should speak with sensor people if we can have some system for this - i think there is a market for this.
Alexandre Passant
On 14 Jul 2010, at 12:24, Nikola Milikic wrote:
> Hi,
[snip]
>
> >>
> > DeclaredBy was designed as a convenience property ( mostly for RDF/XML) , so that you don't have to define agent first and use declaresPresence, but you can start from an OnlinePresence instance and specify the declaringAgent from it. Having in mind how inperfect the real data on the web is ( missing author data in blogs, reserach publications etc) i think that having such convenience properties is not bad. We can call them differently ( maybe intoduce declaringAgent instead of declaredBy, and use declaredBy for the sioc:User as you suggested)?
> >
>
> I'm also ok to have declaredBy with sioc:UserAccount.
> Regarding the naming, I'd prefer to keep a similar naming (with a By, rather than -ing) for consistency.
> We can also have declaredByUser and declaredByPerson.
> Any preference ?
>
> Alex's suggestions are ok, but maybe we could adjust a bit the name of property towards faof:Agent to correspond to the name of the range of that property and call it opo:declaredByAgent. Because, who knows, maybe in a few years time my laundry machine, i.e. agent representing it, will also be able to declare that it is available.:D
+1 for opo:declaredByAgent
>
> Best,
> Nikola Milikic
>
> Email: nikola....@gmail.com
> URL: nikola.milikic.info
--