SIOC extensions proposal

2006, September 15 - 11:40 — imitko

Hi All,

The following are some ideas we want to propose for extensions to SIOC
ontology.

Best Regards,
--
Mitko Iliev
Developer Virtuoso Team
OpenLink Software
http://www.openlinksw.com/virtuoso
Cross Platform Web Services Middleware

SIOC extensions

Class sioc:Forum

Suggested additions:

In domain of

sioc:topic - The topic tags can be inferred from the content.

sioc:feed range uri. This occurs once per each type of aggregation
resource containing data from the forum. Examples are RSS feeds, ATOM,
OPML etc. The URI can be used for differentiating the format and
reading the feed itself provides final certainty. We do not create a
separate node for all this information here.

sioc:related_feed range uri / This represents links to related feed
files which do not themselves contain data from the forum. Links in a
blog roll are examples.

sioc:membership_model one of sioc:private, sioc:public, sioc:moderated.
Many social applications such as Yahoo groups have policies for
accepting new members/subscribers. This can represent the model
applicable there.

Subclasses of sioc:Forum

Class sioc:Weblog

In domain of:

Class sioc:Wiki

In domain of:

sioc:markup range string - Name of the markup used, e.g. twiki.

Class sioc:Bookmarks

Class sioc:News_reader

This is intended for an RSS/ATOM aggregator.

In domain of

sioc:links_to range uri

This references the feed URI's which are being aggregated by this
reader.

Class sioc:Newsgroup

This is intended for a NNTP newsgroup, a Yahoo groups type forum etc.

In domain of

sioc:posting one of sioc:public, sioc:moderated, sioc:read_only.

Class sioc:Photo_album

This is intended for both a photo archive site and an individual album,
where album is analogous with a file system directory.

Subcllasses of sioc:Post

Class sioc:Photo

In domain of:

Any attributes from EXIF in the namespace
http://www.w3.org/2003/12/exif/ns .

Further Possibilities

The items discussed so far are typically public. If we extend the
ontology to managing a desktop or user workspace, we can also model
email and file system content. This would be a RDF version of Apple's
Spotlight, so to speak. Acdcess privileges and full text search will
be significant there, ODS will experiment with these things.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Developers

2006, October 6 - 10:35 — Fred

SIOC extensions proposal

Hi imitko,

I think we already had the discussion before (few month ago).
Personally I don't think we have too explicit if the online community
is a Weblog, a Wiki, etc... Each time something create a new "type"
of system we will create a new class? I don't think it is a good
idea. I mean, the SIOC ontology define the content of an online
commmunity. We are interested in the content, and its relation, not
necessarly where it came from (the "type" of service). We use SIOC to
export blog content, wiki content, etc. I use it to export Talk
Digger content, ODS use it to export bookmark content... etc. So,
considering this, I would personally no add such classes, except if
someone tell me why we should.

Salutations,

Fred

> Class sioc:Weblog
>
> In domain of:
>
>
> Class sioc:Wiki
>
> In domain of:
>
> sioc:markup range string - Name of the markup used, e.g. twiki.
>
>
> Class sioc:Bookmarks
>
> Class sioc:News_reader
>
> This is intended for an RSS/ATOM aggregator.
>
>
> In domain of
>
> sioc:links_to range uri
>
> This references the feed URI's which are being aggregated by this
> reader.
>
> Class sioc:Newsgroup
>
> This is intended for a NNTP newsgroup, a Yahoo groups type forum
etc.
>
> In domain of
>
> sioc:posting one of sioc:public, sioc:moderated, sioc:read_only.
>
>
> Class sioc:Photo_album
>
> This is intended for both a photo archive site and an individual
album,
> where album is analogous with a file system directory.
>
> Subcllasses of sioc:Post
>
> Class sioc:Photo
>
> In domain of:
>
> Any attributes from EXIF in the namespace
> http://www.w3.org/2003/12/exif/ns .

2006, October 6 - 10:35 — HarryChen

SIOC extensions proposal

Hi All,

I think imitko did a good job identifying different types of
user-created web content. However, I agree with Frederick that it's
unnecessary to explicitly capture all thees types in SIOC.

Here is my argument why we should keep SIOC simple and relatively small
in size.

(1) It's usually difficult to build applications with large ontologies.
For example, building applications that are driven by SUMO or CYC
ontology are relatively harder than building applications that are
driven by FOAF or SIOC. As a developer, I always feel that large
ontologies are not always helpful in building applications because they
offer too many different ways to represent a simple concept. I'm
overwhelmed by that.

(2) Developing compelling SW applications don't require large
ontologies with comprehensive semantic modeling. In the past, we have
been so focused on building ontologies, and forgotten the need to
develop applications for solving real world problems. Let's stop paying
too much attention to what should go into an ontology and what should
not. Let's agree on a version, even it's imperfect, and build something
useful together.

(3) The Web changes everyday. It's difficult to predict the emergence
of new kinds of web content or anticipate the phasing out of the
existing ones. I think it's a good idea to keep SIOC relative generic,
small and simple, so that we don't limit ourselves to only concepts
that are valid at the present.

- Harry

Frederick Giasson wrote:
> Hi imitko,
>
> I think we already had the discussion before (few month ago).
> Personally I don't think we have too explicit if the online community
> is a Weblog, a Wiki, etc... Each time something create a new "type"
> of system we will create a new class? I don't think it is a good
> idea. I mean, the SIOC ontology define the content of an online
> commmunity. We are interested in the content, and its relation, not
> necessarly where it came from (the "type" of service). We use SIOC to
> export blog content, wiki content, etc. I use it to export Talk
> Digger content, ODS use it to export bookmark content... etc. So,
> considering this, I would personally no add such classes, except if
> someone tell me why we should.
>
>
> Salutations,
>
> Fred
>
>
> > Class sioc:Weblog
> >
> > In domain of:
> >
> >
> > Class sioc:Wiki
> >
> > In domain of:
> >
> > sioc:markup range string - Name of the markup used, e.g. twiki.
> >
> >
> > Class sioc:Bookmarks
> >
> > Class sioc:News_reader
> >
> > This is intended for an RSS/ATOM aggregator.
> >
> >
> > In domain of
> >
> > sioc:links_to range uri
> >
> > This references the feed URI's which are being aggregated by this
> > reader.
> >
> > Class sioc:Newsgroup
> >
> > This is intended for a NNTP newsgroup, a Yahoo groups type forum
> etc.
> >
> > In domain of
> >
> > sioc:posting one of sioc:public, sioc:moderated, sioc:read_only.
> >
> >
> > Class sioc:Photo_album
> >
> > This is intended for both a photo archive site and an individual
> album,
> > where album is analogous with a file system directory.
> >
> > Subcllasses of sioc:Post
> >
> > Class sioc:Photo
> >
> > In domain of:
> >
> > Any attributes from EXIF in the namespace
> > http://www.w3.org/2003/12/exif/ns .

2006, October 6 - 10:35 — HarryChen

SIOC extensions proposal

Hi All,

I think imitko did a good job identifying different types of
user-created web content. However, I agree with Frederick that it's
unnecessary to explicitly capture all thees types in SIOC.

Here is my argument why we should keep SIOC simple and relatively small
in size.

- Harry

2006, October 6 - 10:35 — terraces

SIOC extensions proposal

Hi,

I also agree with you re. not creating something too complex for SIOC core.

Yet, for some needs it could be nice to know if the retrieved post
come from a wiki page, a forum ...
What I currently do in a project, and can be done now with the "Type"
module, is to subclass Post with various types:
- BlogPost
- WikiPage
- ForumPost
- Mail
...

I doesn't deal with the forum aspect, but might be enough for most
needs I think. It also complexify the ontology, but as it's a module
dedicated to type of Posts, it may be more appropriate.

Alex.

On 9/30/06, HarryChen wrote:
>
> Hi All,
>
> I think imitko did a good job identifying different types of
> user-created web content. However, I agree with Frederick that it's
> unnecessary to explicitly capture all thees types in SIOC.
>
> Here is my argument why we should keep SIOC simple and relatively small
> in size.
>
> (1) It's usually difficult to build applications with large ontologies.
> For example, building applications that are driven by SUMO or CYC
> ontology are relatively harder than building applications that are
> driven by FOAF or SIOC. As a developer, I always feel that large
> ontologies are not always helpful in building applications because they
> offer too many different ways to represent a simple concept. I'm
> overwhelmed by that.
>
> (2) Developing compelling SW applications don't require large
> ontologies with comprehensive semantic modeling. In the past, we have
> been so focused on building ontologies, and forgotten the need to
> develop applications for solving real world problems. Let's stop paying
> too much attention to what should go into an ontology and what should
> not. Let's agree on a version, even it's imperfect, and build something
> useful together.
>
> (3) The Web changes everyday. It's difficult to predict the emergence
> of new kinds of web content or anticipate the phasing out of the
> existing ones. I think it's a good idea to keep SIOC relative generic,
> small and simple, so that we don't limit ourselves to only concepts
> that are valid at the present.
>
> - Harry
>
> Frederick Giasson wrote:
> > Hi imitko,
> >
> > I think we already had the discussion before (few month ago).
> > Personally I don't think we have too explicit if the online community
> > is a Weblog, a Wiki, etc... Each time something create a new "type"
> > of system we will create a new class? I don't think it is a good
> > idea. I mean, the SIOC ontology define the content of an online
> > commmunity. We are interested in the content, and its relation, not
> > necessarly where it came from (the "type" of service). We use SIOC to
> > export blog content, wiki content, etc. I use it to export Talk
> > Digger content, ODS use it to export bookmark content... etc. So,
> > considering this, I would personally no add such classes, except if
> > someone tell me why we should.
> >
> >
> > Salutations,
> >
> > Fred
> >
> >
> > > Class sioc:Weblog
> > >
> > > In domain of:
> > >
> > >
> > > Class sioc:Wiki
> > >
> > > In domain of:
> > >
> > > sioc:markup range string - Name of the markup used, e.g. twiki.
> > >
> > >
> > > Class sioc:Bookmarks
> > >
> > > Class sioc:News_reader
> > >
> > > This is intended for an RSS/ATOM aggregator.
> > >
> > >
> > > In domain of
> > >
> > > sioc:links_to range uri
> > >
> > > This references the feed URI's which are being aggregated by this
> > > reader.
> > >
> > > Class sioc:Newsgroup
> > >
> > > This is intended for a NNTP newsgroup, a Yahoo groups type forum
> > etc.
> > >
> > > In domain of
> > >
> > > sioc:posting one of sioc:public, sioc:moderated, sioc:read_only.
> > >
> > >
> > > Class sioc:Photo_album
> > >
> > > This is intended for both a photo archive site and an individual
> > album,
> > > where album is analogous with a file system directory.
> > >
> > > Subcllasses of sioc:Post
> > >
> > > Class sioc:Photo
> > >
> > > In domain of:
> > >
> > > Any attributes from EXIF in the namespace
> > > http://www.w3.org/2003/12/exif/ns .
>
>
> >
>

SIOC extensions proposal

SIOC extensions proposal

SIOC extensions proposal

SIOC extensions proposal

SIOC extensions proposal

Primary links

Syndicate

User login