Issue #1: - subclass sioc:Community from sioc:Container

2007, April 2 - 09:54 — CaptSolo

Issue #1: subclass sioc:Community from ...

Proposal: subclass sioc:Cummunity from sioc:Container

Consequences: property names sioc:has_part / sioc:part_of can be reused.

Decision: ...

Discussion:
> - subclass sioc:Community from sioc:Container (or sioc:Space?) or
> make it use the same has_container / container_of properties as
> Container does (or "bump" its has_part and part_of properties one
> level up to sioc:Container).

> the idea of sioc:Community was to act as a container for any kind of resources which are parts of a community.

Now there is a nice hierarchy of things in SIOC:
[ sioc:Space -> sioc:Container -> ... -> sioc:Item -> (contents &
parts of item) ]

sioc:Community should be able to fit into one of these categories.
Since it is a container [for any kind of resources] it can be either
sioc:Container or sioc:Space.

Main question is - what things can be a part of a Container or Space?
sioc:Community can contain any resource (URI).

Uldis

[ http://captsolo.net/info/ ]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Developers

2007, April 2 - 09:54 — Cloud

Issue #1: - subclass sioc:Community from sioc:Container

I don't think Community should be subclassed from Space or Container. I
think a Community can be a collection of Spaces, Sites, Containers, etc.
so it is something bigger than all of them...

But looking forward to other opinions.

I understand that has_part might be a nice term for describing parts in
a Post however :) Maybe just removing the domain will fix that...

2007, April 2 - 09:54 — Benja Fallenstein

Issue #1: - subclass sioc:Community from sioc:Container

2007/3/15, John Breslin :
> I don't think Community should be subclassed from Space or Container. I
> think a Community can be a collection of Spaces, Sites, Containers, etc.
> so it is something bigger than all of them...

I don't really see these as conflicting -- a Container is a subclass
of Resource, and yet it contains things of type Resource :-)

(I don't really have an opinion on Uldis' issue.)

- Benja

2007, April 2 - 09:54 — CaptSolo

Issue #1: - subclass sioc:Community from sioc:Container

On 3/15/07, John Breslin wrote:
>
> I don't think Community should be subclassed from Space or Container. I
> think a Community can be a collection of Spaces, Sites, Containers, etc.
> so it is something bigger than all of them...
>
> But looking forward to other opinions.

That depends on what a "Space" is. And what do we need a "Space" for.

Alex writes:
> * Maybe I missed something about Container / Space, but I can't see
> what - still in this scope - what brings to the model ? Or maybe a top
> class besides Forum / Site is enought if we want to say "A space that
> contains Web 2.0 things" ?

Currently the only subclass of sioc:Space is a sioc:Site.

If you look at a Community and Site they are very similar, with the
main difference that a Community can contain any resources, and that a
Site assumes that all its contents is located on a single site.

Maybe we need to allow anything to be a part of a sioc:Space.

Question 1: if we allow containers to be parents (= to contain) of
other containers how is sioc:Space different from a sioc:Container
(which contains all these other containers)?

> I understand that has_part might be a nice term for describing parts in
> a Post however :) Maybe just removing the domain will fix that...

Uldis

[ http://captsolo.net/info/ ]

2007, April 2 - 09:54 — Cloud

Issue #1: - subclass sioc:Community from sioc:Container

It's partially my fault for not clearly defining it in the spec.

Space is a place where data is stored. At the moment we just have
Sites, but could also be desktops, flash drives, fileshares, etc.

In my head at least :) a Community is a grouping of SIOC things related
to a particular community. Could be Sites, Users, foaf:People,
Documents, Posts, Containers, etc...

2007, April 2 - 09:54 — CaptSolo

Issue #1: - subclass sioc:Community from sioc:Container

On 3/15/07, John Breslin wrote:
>
> Space is a place where data is stored. At the moment we just have
> Sites, but could also be desktops, flash drives, fileshares, etc.
>
> In my head at least :) a Community is a grouping of SIOC things related
> to a particular community. Could be Sites, Users, foaf:People,
> Documents, Posts, Containers, etc...

We may want to ask Kingsley to give some comments and help clarify the
meaning and use cases for sioc:Space. He was the one who first talked
about a need for the concept of data spaces.

There is a potential to improve this model. Ask a question what
sub/super-classes we need and do we really need them.

As sioc:Space stands now I can hardly see why sioc:Site is a subclass
of sioc:Space. The idea of Space is cool, but the definition which you
just quoted is too restrictive (in my opinion). How important it is to
the concept of Space that things are physically together? What would
we gain by dropping this restriction? If sioc:Item and sioc:Container
are very generic, what is the generic class at the level of sioc:Site?

Let's see what can be a part of each of them:
sioc:Space - ( ??? )
sioc:Site - Usergroups, Forums, Containers, (anything else?)
sioc:Community - Sites, Users, foaf:People, Documents, Posts, Containers, etc..

Suggestion:
- to make sioc:Space a generic class which other classes can specialise
- subclass sioc:Site, sioc:Community, ... from it and add their
specific properties
- if sioc:Space is not a good candicate for a generic class, add a
new generic class

Guys, please add your opinions.

Uldis

[ http://captsolo.net/info/ ]

2007, April 2 - 09:54 — Richard Cyganiak

Issue #1: - subclass sioc:Community from sioc:Container

On 15 Mar 2007, at 18:46, Uldis Bojars wrote:
> Let's see what can be a part of each of them:
> sioc:Space - ( ??? )
> sioc:Site - Usergroups, Forums, Containers, (anything else?)
> sioc:Community - Sites, Users, foaf:People, Documents, Posts,
> Containers, etc..
>
> Suggestion:
> - to make sioc:Space a generic class which other classes can
> specialise
> - subclass sioc:Site, sioc:Community, ... from it and add their
> specific properties
> - if sioc:Space is not a good candicate for a generic class, add a
> new generic class
>
> Guys, please add your opinions.

(I haven't read the whole thread)

I think that this kind of upper-level ontology modelling is not
helpful. Whatever you come up with, some people will disagree with it.

A community is not a container! It's a network! No, it's a
conversation! A site is a product, not a space! No, it's a
project! Or is it a document?

Requiring people to buy into an upper-level ontology if they want to
use SIOC would make SIOC less re-usable and doesn't seem to add much
to SIOC's core mission of describing online communities.

So my 0.02 would be to avoid these contrived artificial concepts and
keep it simple. Stick to terms from everyday language. If you need a
generic superclass, use rdfs:Resource.

Richard

>
> Uldis
>
> [ http://captsolo.net/info/ ]
>
> >
>

2007, April 2 - 09:54 — Cloud

What's a Space (Was subclass sioc:Community from sioc:Container)

> We may want to ask Kingsley to give some comments and help clarify the
> meaning and use cases for sioc:Space. He was the one who first talked
> about a need for the concept of data spaces.
>
>
I know the conversation has moved on since this but here were some ideas
from a message to Kingsley / Uldis:

> Actually when I was thinking about superclassing Space over Site I
meant that Space is a more generic place where data is stored, over a Site.

> Space could be desktop, a fileshare, a mobile phone flash drive,
whatever. But to be more semantically correct, I think you still need a
Site and maybe other subtypes to say where things are stored...

> Yes, things are becoming more transparent, and it doesn't matter to
the end user where the data is stored, but there will still be a need to
define this... For (1) some people may see the fact that data is stored
on a Site or not as a boon or a problem [for certain scenarios, a
centralised site-based system may be advantageous, for others, the
distribution of data across peers' desktops may be preferred] and (2)
backwards compatability. You can still say whatever you want, that
Containers are on Spaces or Sites (or Desktops if that was added)...

2007, April 2 - 09:54 — CaptSolo

Issue #1: - subclass sioc:Community from sioc:Container

On 3/15/07, Uldis Bojars wrote:
> On 3/15/07, John Breslin wrote:
> >
> > Space is a place where data is stored. At the moment we just have
> > Sites, but could also be desktops, flash drives, fileshares, etc.
> >
> > In my head at least :) a Community is a grouping of SIOC things related
> > to a particular community. Could be Sites, Users, foaf:People,
> > Documents, Posts, Containers, etc...
>
> We may want to ask Kingsley to give some comments and help clarify the
> meaning and use cases for sioc:Space. He was the one who first talked
> about a need for the concept of data spaces.

Had a conversation about this on #sioc [1] and we agreed that both
sioc:Community and sioc:Site can be subclasses of sioc:Space (provided
that sioc:Space can contain anything, not only sioc:Containers and
sioc:Items).

[1] http://tuukka.iki.fi/tmp/sioc-2007-03-15#20:28:23

If this is a case then we may also want to keep sioc:has_part /
sioc:part_of to indicate things that are parts of a dataspace. As for
describing parts of Posts / Items some new property names were
proposed: has_segment, has_enclosure, has_component.

P.S. One confusion which I can expect with this is - if both are
dataspaces, can a Site be a part of a Community according to this
model. That is - can a dataspace be a part of another dataspace. (I
don't see why not.)

Uldis

[ http://captsolo.net/info/ ]

2007, April 2 - 09:54 — Cloud

Issue #1: - subclass sioc:Community from sioc:Container

> Had a conversation about this on #sioc [1] and we agreed that both
> sioc:Community and sioc:Site can be subclasses of sioc:Space (provided
> that sioc:Space can contain anything, not only sioc:Containers and
> sioc:Items).
>
>
Sounds okay, but as Richard pointed out ("Whatever you come up with,
some people will disagree with it."), I have some worries :) - in short,
that a Community = People + Spaces.

As I mentioned, I think a Community is more than a Space (if a Space is
where data is stored), because the data that a Community forms is of
course residing somewhere, but also the Community is more than the data
if you include People in the notion of a Community (and they could have
profiles residing on a Space, but not sure if it is the same thing)...

Having said that, if people are happy for Community to be a type of
Space, I can live with it.

Either way, the range of space_of could be opened up to allow any
resource to fit into a Space.

As regards properties, part_of / has_part would seem to fit better for
Post than Community.

J.
--

2007, April 2 - 09:54 — CaptSolo

Issue #1: - subclass sioc:Community from sioc:Container

On 3/16/07, John Breslin wrote:

> Sounds okay, but as Richard pointed out ("Whatever you come up with,
> some people will disagree with it."), I have some worries :) - in short,
> that a Community = People + Spaces.

> As I mentioned, I think a Community is more than a Space (if a Space is
> where data is stored), because the data that a Community forms is of
> course residing somewhere, but also the Community is more than the data
> if you include People in the notion of a Community (and they could have
> profiles residing on a Space, but not sure if it is the same thing)...

What falls within a Space depends on its definition. Kingsley said on
IRC the Community does (after some discussion).

Site and a Community are similar in structure (as I see them). Site is
more constrained, but it can also contain groups of people (though it
has a separate property for this) and both can contain Items directly
(e.g., as your home drive can cotain files and directories). If one is
not a Space the other is probably not either.

> Either way, the range of space_of could be opened up to allow any
> resource to fit into a Space.

What concerns me - a name "space_of" is quite specific. For sioc:Forum
we have a sioc:has_container / sioc:container_of and that can be used
with sioc:Container as well. We had a generic property names
previously, but this name is very tied to the name of the class.

Will we be using sioc:has_space with a sioc:Site instead of host_of / has_host?

> As regards properties, part_of / has_part would seem to fit better for
> Post than Community.

Uldis

[ http://captsolo.net/info/ ]

2007, April 2 - 09:54 — Cloud

Issue #1: - subclass sioc:Community from sioc:Container

> Site and a Community are similar in structure (as I see them). Site is
> more constrained, but it can also contain groups of people (though it
> has a separate property for this) and both can contain Items directly
> (e.g., as your home drive can cotain files and directories). If one is
> not a Space the other is probably not either.
>

If you're happy, as I said I won't complain (for a change :)).

> What concerns me - a name "space_of" is quite specific. For sioc:Forum
> we have a sioc:has_container / sioc:container_of and that can be used
> with sioc:Container as well. We had a generic property names
> previously, but this name is very tied to the name of the class.

So we need a new property to say what a Space consists of? (eek -
constituent_of!) If we can come up with something better than
space_of, let's go for it. Previously, all our property names were not
tied to the class name, but this has become impossible recently
(thinking of trying to find property names to link to Usergroup,
Service, etc.). And I think it will continue to be hard to find
independent property names, so can't use that legacy use as a reason any
more (much and all as I preferred it).

> Will we be using sioc:has_space with a sioc:Site instead of host_of /
has_host?

At the moment, host_of is subclassed from space_of - I don't think we
should drop the host properties as a lot of use is already being made of
them...

2007, April 2 - 09:54 — CaptSolo

Issue #1: - subclass sioc:Community from sioc:Container

Updated the ontology with changes for this issue:

1) Community made a subclass of Space
2) removed range/domain constraints on sioc:has_space/space_of so that
any resource can be a part of a data Space (without automatically
becoming a Container)
3) removed range/domain from sioc:has_part/part_of which will be used
to point to resources that are parts of an Item/Post

Also changed descriptions of the classes and properties mentioned above.

Still needed to do / decide:

- need a better description for sioc:Space, one which allows
non-containers to be a part of it. anyone has a good definition?

- add range/domain to sioc:has_part/part_of to reflect the fact that
it is to be used with sioc:Item(s). left this out for a moment to
allow to change existing data (Alex's SIOC community exporter) that
use them together with a sioc:Community.

On 3/16/07, John Breslin wrote:
>
> So we need a new property to say what a Space consists of? (eek -
> constituent_of!) If we can come up with something better than
> space_of, let's go for it. Previously, all our property names were not

Let's see how has_space / space_of will look for a community:

com1 a sioc:Community .
com1 sioc:space_of person_A .
com1 sioc:space_of site_X .

person_A a foaf:Person .
site_X a sioc:Site .

You can imagine using the reverse property has_space with a person and
a site in this example. If all are happy with it we can leave them as
is.

> tied to the class name, but this has become impossible recently
> (thinking of trying to find property names to link to Usergroup,
> Service, etc.). And I think it will continue to be hard to find
> independent property names, so can't use that legacy use as a reason any
> more (much and all as I preferred it).

Having a generic meaning for terms is a good thing. It can allow for a
wider (and possibly unexpected) use than originally planned. E.g.,
rss:item is an example of a description that allows for a wider use of
this class - anything can be an rss:item.

Coming up with good names is becoming harder, and possibly we can
leave has_space/space_of as is. But if we are thinking about names,
our efforts are best spent keeping the descriptions general enough and
not restricting them without necessity.

An example in SIOC where a description is maybe too specific is
sioc:Post which says "An article or message posted to a Forum.".

This is understood by people that there _must_ be a sioc:Forum even
when they don't need it. I think it was bblfish who said on #sioc that
a sioc:Post would fit for describing bugzilla error report comments
(see his post on SIOC-Dev) but that he does not need a sioc:Forum (and
hence asking if sioc:Post can be used).

> > Will we be using sioc:has_space with a sioc:Site instead of host_of /
> has_host?
>
> At the moment, host_of is subclassed from space_of - I don't think we
> should drop the host properties as a lot of use is already being made of
> them...

OK.

Uldis

[ http://captsolo.net/info/ ]

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

What's a Space (Was subclass sioc:Community from sioc:Container)

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Issue #1: - subclass sioc:Community from sioc:Container

Primary links

Syndicate

User login