New: SIOC & Related Ontologies

2006, October 6 - 10:35 — CaptSolo

Another part that needs improvement in the SIOC specification is a
description of its relations with and usage together with other
ontologies.

http://esw.w3.org/topic/SIOC/RelatedOntologies

We have created a new wiki page to describe this. Please contribute
your views.

This document may get quite lengthy and detailed - therefore we may
consider having it as a separate document that is a part of the member
submission. Then we can fill it with more information (figures,
examples?) how to use them together.

Section of the specification "External Classes and Properties" has some
of the information that can be used as a basis of this description.

Best,
Uldis

--~--~---------~--~----~------------~-------~--~----~
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 — Axel Polleres

New: SIOC & Related Ontologies

Hi Uldis, all,

I tried to give it a go, being clear about that there are more experts
in this list on the treated voacbularies and standards, I tried to
outline relations to foaf, rss, dublin core, skos briefly.

http://esw.w3.org/topic/SIOC/RelatedOntologies

1) The main thing for this first attempt is that I found quite some
issues which I think should be clarified before finalizing this
document: I mentioned issues in bold text and in the last column of the
the concluding table on the wiki page.

2) I think this document/section should evolve in parallel with

http://rdfs.org/sioc/mappings

On the wiki page I already sketched some mappings which IMO are missing
and/or should be discussed.

opinions and corrections welcome,
this definitly needs much refinement before it can go as part of the
submission,

axel

p.s.: in the spec you also mention ontologies such as the KWeb portal
ontology, the deri-swportal ontology, andreas' dblp ontology, etc.,etc.
shall we treat these (IMO, only briefly, since these are all proprietary
developments which were so far only used within a quite limited context.)

Uldis Bojars wrote:
> Another part that needs improvement in the SIOC specification is a
> description of its relations with and usage together with other
> ontologies.
>
> http://esw.w3.org/topic/SIOC/RelatedOntologies
>
> We have created a new wiki page to describe this. Please contribute
> your views.
>
> This document may get quite lengthy and detailed - therefore we may
> consider having it as a separate document that is a part of the member
> submission. Then we can fill it with more information (figures,
> examples?) how to use them together.
>
> Section of the specification "External Classes and Properties" has some
> of the information that can be used as a basis of this description.
>
> Best,
> Uldis
>
>
> >
>

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, October 20 - 19:35 — CaptSolo

New: SIOC & Related Ontologies

> I tried to give it a go, being clear about that there are more experts
> in this list on the treated voacbularies and standards, I tried to
> outline relations to foaf, rss, dublin core, skos briefly.
>
> http://esw.w3.org/topic/SIOC/RelatedOntologies

Related ontologies document is now reformatted according to the format
of W3C submission and available at:

http://sparql.captsolo.net/spec/related.html

You can continue to contribute changes to the wiki page - I will update
the document accordingly.

About the issues mentioned in the document:

(1) Issue1: For instance sioc:avatar could have
http://dublincore.org/2006/08/28/dctype.rdf#Image as a type.

We can do this (use it as a range of sioc:avatar). I have not seen it
used much, but maybe I was looking in the wrong place.

There is also foaf:Image class that an avatar can be a type of.

(2) Issue2: This mapping does not yet appear in the mappings, but it
should

What particular mapping do you mean by that?

(3) Issue3: The SIOC document mentions that sioc:first_name is
deprecated and foaf:first_name property should be used instead. Note
that this can only be done via the detour of either specifying the
identifier of the foaf:person behind the user or using a blank node,
since the domain of foaf:firstName (btw a typo in the ontology, it is
firstName, not first_name in the foaf spec) is foaf:Person. This
applies equally to the suggested deprecation of sioc:last_name.

There should not be a problem. A foaf:Person and its properties are
used to describe the personal information of a user and, of course, it
can have foaf:firstName property.

Thanks, a typo corrected.

We need to point to the related ontologies document from the
specification and/or mention these first/last name properties in the
"External classes and properties" section of the specification.

(4) Issue3: Besides, SIOC's email and email_sha1 properties seem to be
redundant and equally expressible via blanks or a foaf:Person behind
the account. Maybe not, if the user is a bot.

email and email_sha1 properties are not needed in many cases but they
are there for a reason. it allows to keep the information that a user
account (sioc:User) is associated with a particular email address. a
person (foaf:Person) may have a number of different email addresses and
by only using foaf:mbox you may use this link.

Suggestion: add a description to sioc:email and sioc:email_sha1
properties telling when and why to use them.

(5) Issue4: Complementary/alternatively to Issue1, sioc:avatar could
also reuse or at least foaf:depiction in order to link to user images.

Again, same as in (4) we should keep the link between a particular user
account (sioc:User) and its avatar - that is why there's a sioc:avatar
property.

We could subclass it from foaf:depiction, BUT i am not sure if the
definition of foaf:depiction includes avatars who often would not
contain a picture of a person (hence would not depict him/her), but
would rather be a representation of this person or user account.

(6) Issue5: The subclassing of rss:item is not mentioned so far, but I
thought it could be useful. To be discussed.

What would that give us?

There are properties that are common to sioc:Post and rss:item (Dublin
Core properties), so it may make sense. At the same time a sioc:Post
will not have all the properties of an rss:item, e.g. rss:title.

Another thing to do is create mappings and/or mapping services that
convert information between SIOC and other popular formats. A sioc:Post
will not contain all the fields that rss:item is required to have
according to the specification, but it most certainly can be converted
to RSS 1.0.

More issues were added by Alex recently:

(7) Issue: As someone mentionned on sioc-dev, we can't be sure to infer
the good foaf:User if a sioc:User is share by more than one user. But
in this case, maybe we must use a foaf:Group and add in the specs a
owl:maxCardinality = 1 restriction to account_of (i.e. 1 account = 1
Agent). BTW, we might think about some other cardinality restrictions,
if needed.

Changed the range of account_of to foaf:Agent in the specification (as
was decided earlier).

About the cardinality constraints let's keep the discussion in the
existing thread "SIOC properties cardinality" that Alex started.

The question of a sioc:User being shared by more than one user is more
of a theoretical case and also borders with how much information do we
have about who is writing the content anyway.

That is all about the issues.

ToDo: add examples to the document.

Best regards + have a nice weekend,
Uldis Bojars

2006, October 20 - 19:35 — terraces

New: SIOC & Related Ontologies

On 10/13/06, Uldis Bojars wrote:
>
>
> ToDo: add examples to the document.
I've added one example for each related ontology + the complete sample
sioc:Post at the end

I've also added a section mentionning links from sioc to any ontology
using sioc:topic. I'm not sure it's directly concerned with this
document as it's not "related" ontologies, but can be useful to keep
it in mind at least.

Best

Alex.

>
> Best regards + have a nice weekend,
> Uldis Bojars
>
>
> >
>

2006, October 20 - 19:35 — Axel Polleres

New: SIOC & Related Ontologies

Uldis Bojars wrote:
>>I tried to give it a go, being clear about that there are more experts
>>in this list on the treated voacbularies and standards, I tried to
>>outline relations to foaf, rss, dublin core, skos briefly.
>>
>>http://esw.w3.org/topic/SIOC/RelatedOntologies
>
> Related ontologies document is now reformatted according to the format
> of W3C submission and available at:
>
> http://sparql.captsolo.net/spec/related.html
>
> You can continue to contribute changes to the wiki page - I will update
> the document accordingly.
>
> About the issues mentioned in the document:
>
> (1) Issue1: For instance sioc:avatar could have
> http://dublincore.org/2006/08/28/dctype.rdf#Image as a type.
>
> We can do this (use it as a range of sioc:avatar). I have not seen it
> used much, but maybe I was looking in the wrong place.

Me neither, it was just a suggestion...

> There is also foaf:Image class that an avatar can be a type of.

... maybe foaf:Image is better.

See also the table entry:
sioc:avatar could subclass foaf:depiction (which has domain OWL:thing)
which would restrict the range, or use dcmi:Image as range, Notably
there is a difference with foaf:img which has a foaf:person as its range.

> (2) Issue2: This mapping does not yet appear in the mappings, but it
> should
>
> What particular mapping do you mean by that?

The original senctence here was:
"Furthermore, foaf:name is subclassed by sioc:name to denote the name of
a particular sioc:User or sioc:Usergroup."

must have been lost due to changes by Alexandre.
I meant to say that this mapping doesn't appear in
http://rdfs.org/sioc/mappings

> (3) Issue3: The SIOC document mentions that sioc:first_name is
> deprecated and foaf:first_name property should be used instead. Note
> that this can only be done via the detour of either specifying the
> identifier of the foaf:person behind the user or using a blank node,
> since the domain of foaf:firstName (btw a typo in the ontology, it is
> firstName, not first_name in the foaf spec) is foaf:Person. This
> applies equally to the suggested deprecation of sioc:last_name.
>
> There should not be a problem. A foaf:Person and its properties are
> used to describe the personal information of a user and, of course, it
> can have foaf:firstName property.

My point is, HOW to use foaf:first_name. And the issue proposes 2 ways
to do it, maybe better to add an example than an "issue", but wanted to
clraify whether these two make sense. The point is that you cannot use
foaf:first_name directly on sioc:User as the domain, but need a person
in between.

> Thanks, a typo corrected.
>
> We need to point to the related ontologies document from the
> specification and/or mention these first/last name properties in the
> "External classes and properties" section of the specification.

something like that, yes.

> (4) Issue3: Besides, SIOC's email and email_sha1 properties seem to be
> redundant and equally expressible via blanks or a foaf:Person behind
> the account. Maybe not, if the user is a bot.
>
> email and email_sha1 properties are not needed in many cases but they
> are there for a reason. it allows to keep the information that a user
> account (sioc:User) is associated with a particular email address. a
> person (foaf:Person) may have a number of different email addresses and
> by only using foaf:mbox you may use this link.
>
> Suggestion: add a description to sioc:email and sioc:email_sha1
> properties telling when and why to use them.

We discussed this issue also in this thread:

----------------------------------------------
Subject: Re: Updated example in SIOC specification
From: Axel Polleres
Date: Thu, 28 Sep 2006 11:34:20 +0200
To: sioc-dev@googlegroups.com
----------------------------------------------

> (5) Issue4: Complementary/alternatively to Issue1, sioc:avatar could
> also reuse or at least foaf:depiction in order to link to user images.
>
> Again, same as in (4) we should keep the link between a particular user
> account (sioc:User) and its avatar - that is why there's a sioc:avatar
> property.
>
> We could subclass it from foaf:depiction, BUT i am not sure if the
> definition of foaf:depiction includes avatars who often would not
> contain a picture of a person (hence would not depict him/her), but
> would rather be a representation of this person or user account.

We'd need to make
foaf:Image a range of avatar (owuld be implicit by the subclassing)
there is no restrictions on WHAT a foaf:Image depicts, so wouldn't be a
problem. Question is whther changes in that are to be expected from foaf.

> (6) Issue5: The subclassing of rss:item is not mentioned so far, but I
> thought it could be useful. To be discussed.
>
> What would that give us?
>
> There are properties that are common to sioc:Post and rss:item (Dublin
> Core properties), so it may make sense. At the same time a sioc:Post
> will not have all the properties of an rss:item, e.g. rss:title.

but these can be inherited... see no problem here.

> Another thing to do is create mappings and/or mapping services that
> convert information between SIOC and other popular formats. A sioc:Post
> will not contain all the fields that rss:item is required to have
> according to the specification, but it most certainly can be converted
> to RSS 1.0.

which fields are REQUIRED there?

> More issues were added by Alex recently:
>
> (7) Issue: As someone mentionned on sioc-dev, we can't be sure to infer
> the good foaf:User if a sioc:User is share by more than one user. But
> in this case, maybe we must use a foaf:Group and add in the specs a
> owl:maxCardinality = 1 restriction to account_of (i.e. 1 account = 1
> Agent). BTW, we might think about some other cardinality restrictions,
> if needed.
>
> Changed the range of account_of to foaf:Agent in the specification (as
> was decided earlier).
>
> About the cardinality constraints let's keep the discussion in the
> existing thread "SIOC properties cardinality" that Alex started.

ok.

> The question of a sioc:User being shared by more than one user is more
> of a theoretical case and also borders with how much information do we
> have about who is writing the content anyway.

yes.

> That is all about the issues.
>
> ToDo: add examples to the document.
>
> Best regards + have a nice weekend,
> Uldis Bojars
>
>
> >
>

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, October 20 - 19:35 — terraces

New: SIOC & Related Ontologies

On 10/15/06, Axel Polleres wrote:
>
> Uldis Bojars wrote:

> >
> > (1) Issue1: For instance sioc:avatar could have
> > http://dublincore.org/2006/08/28/dctype.rdf#Image as a type.
> >
> > We can do this (use it as a range of sioc:avatar). I have not seen it
> > used much, but maybe I was looking in the wrong place.
>
> Me neither, it was just a suggestion...
>
> > There is also foaf:Image class that an avatar can be a type of.
>
> ... maybe foaf:Image is better.
>
> See also the table entry:
> sioc:avatar could subclass foaf:depiction (which has domain OWL:thing)
> which would restrict the range, or use dcmi:Image as range, Notably
> there is a difference with foaf:img which has a foaf:person as its range.
>

+1 for subclassing sioc:avatar from foaf:depiction, so we'll get
foaf:image as a range, and the domain is OK + description "The
foaf:depiction property is a relationship between a thing and an
foaf:Image that depicts it"
As Axel mentionned is in answer, the only problem if is foaf:depiction
evolves, but we could change the mappings in this case.

> > (2) Issue2: This mapping does not yet appear in the mappings, but it
> > should
> >
> > What particular mapping do you mean by that?
>
> The original senctence here was:
> "Furthermore, foaf:name is subclassed by sioc:name to denote the name of
> a particular sioc:User or sioc:Usergroup."
>
> must have been lost due to changes by Alexandre.
> I meant to say that this mapping doesn't appear in
> http://rdfs.org/sioc/mappings

Your sentence is still there but indeed, I added some text between it
and the issue, sorry for that

> > Another thing to do is create mappings and/or mapping services that
> > convert information between SIOC and other popular formats. A sioc:Post
> > will not contain all the fields that rss:item is required to have
> > according to the specification, but it most certainly can be converted
> > to RSS 1.0.
>
> which fields are REQUIRED there?
>

I wrote a post + query about RSS 2 SIOC [1], and have planned to do
queries for SIOC 2 RSS1.0 + Content module.
I think we could have:
- sioc:Forum => rss:channel
- siocForum/dc:title => rss:channel/rss:title
- sioc:Forum/dc:title => rss:channel/rss:title
- sioc:Forum/rdf:about => rss:channel/rss:link
- sioc:Forum/dc:description => rss:channel/rss:description
- sioc:Forum/sioc:container_of => create rss:channel/rss:items list
- sioc:Post => rss:item
- sioc:Post/dc:title => rss:item/rss:title
- sioc:Post/rdf:about => rss:item/rss:link
- sioc:Post/sioc:content => rss:item/rss:description
- sioc:Post/content:encoded => rss:item/content:encoded

I'm just wondering if a RSS feed could have more that one channel in
it. (even if I didn't see any restriction in the specs), as it's
needed for creating RSS feeds from SIOC data crawled from different
sioc:forums.

If we all agree with the previous translation mappings, I'll wrote a
translation query, then it could be nice to have a translation service
(in both directions) on sioc-project.org.

> > More issues were added by Alex recently:
> >
> > (7) Issue: As someone mentionned on sioc-dev, we can't be sure to infer
> > the good foaf:User if a sioc:User is share by more than one user. But
> > in this case, maybe we must use a foaf:Group and add in the specs a
> > owl:maxCardinality = 1 restriction to account_of (i.e. 1 account = 1
> > Agent). BTW, we might think about some other cardinality restrictions,
> > if needed.
> >
> > Changed the range of account_of to foaf:Agent in the specification (as
> > was decided earlier).
Thanks

Best,

Alex.

> > That is all about the issues.
> >
> > ToDo: add examples to the document.
> >
> > Best regards + have a nice weekend,
> > Uldis Bojars
> >
> >
> > >
> >
>
>
> --
> Dr. Axel Polleres
> email: axel@polleres.net url: http://www.polleres.net/
>
>
>
> >
>

2006, October 20 - 19:35 — terraces

New: SIOC & Related Ontologies

Sorry, forgot the RSS / SIOC URL:

[1] http://apassant.net/blog/2006/10/05/119-from-rss-to-sioc-using-sparql

On 10/15/06, Alexandre Passant wrote:
> On 10/15/06, Axel Polleres wrote:
> >
> > Uldis Bojars wrote:
>
> > >
> > > (1) Issue1: For instance sioc:avatar could have
> > > http://dublincore.org/2006/08/28/dctype.rdf#Image as a type.
> > >
> > > We can do this (use it as a range of sioc:avatar). I have not seen it
> > > used much, but maybe I was looking in the wrong place.
> >
> > Me neither, it was just a suggestion...
> >
> > > There is also foaf:Image class that an avatar can be a type of.
> >
> > ... maybe foaf:Image is better.
> >
> > See also the table entry:
> > sioc:avatar could subclass foaf:depiction (which has domain OWL:thing)
> > which would restrict the range, or use dcmi:Image as range, Notably
> > there is a difference with foaf:img which has a foaf:person as its range.
> >
>
> +1 for subclassing sioc:avatar from foaf:depiction, so we'll get
> foaf:image as a range, and the domain is OK + description "The
> foaf:depiction property is a relationship between a thing and an
> foaf:Image that depicts it"
> As Axel mentionned is in answer, the only problem if is foaf:depiction
> evolves, but we could change the mappings in this case.
>
> > > (2) Issue2: This mapping does not yet appear in the mappings, but it
> > > should
> > >
> > > What particular mapping do you mean by that?
> >
> > The original senctence here was:
> > "Furthermore, foaf:name is subclassed by sioc:name to denote the name of
> > a particular sioc:User or sioc:Usergroup."
> >
> > must have been lost due to changes by Alexandre.
> > I meant to say that this mapping doesn't appear in
> > http://rdfs.org/sioc/mappings
>
> Your sentence is still there but indeed, I added some text between it
> and the issue, sorry for that
>
> > > Another thing to do is create mappings and/or mapping services that
> > > convert information between SIOC and other popular formats. A sioc:Post
> > > will not contain all the fields that rss:item is required to have
> > > according to the specification, but it most certainly can be converted
> > > to RSS 1.0.
> >
> > which fields are REQUIRED there?
> >
>
> I wrote a post + query about RSS 2 SIOC [1], and have planned to do
> queries for SIOC 2 RSS1.0 + Content module.
> I think we could have:
> - sioc:Forum => rss:channel
> - siocForum/dc:title => rss:channel/rss:title
> - sioc:Forum/dc:title => rss:channel/rss:title
> - sioc:Forum/rdf:about => rss:channel/rss:link
> - sioc:Forum/dc:description => rss:channel/rss:description
> - sioc:Forum/sioc:container_of => create rss:channel/rss:items list
> - sioc:Post => rss:item
> - sioc:Post/dc:title => rss:item/rss:title
> - sioc:Post/rdf:about => rss:item/rss:link
> - sioc:Post/sioc:content => rss:item/rss:description
> - sioc:Post/content:encoded => rss:item/content:encoded
>
> I'm just wondering if a RSS feed could have more that one channel in
> it. (even if I didn't see any restriction in the specs), as it's
> needed for creating RSS feeds from SIOC data crawled from different
> sioc:forums.
>
> If we all agree with the previous translation mappings, I'll wrote a
> translation query, then it could be nice to have a translation service
> (in both directions) on sioc-project.org.
>
> > > More issues were added by Alex recently:
> > >
> > > (7) Issue: As someone mentionned on sioc-dev, we can't be sure to infer
> > > the good foaf:User if a sioc:User is share by more than one user. But
> > > in this case, maybe we must use a foaf:Group and add in the specs a
> > > owl:maxCardinality = 1 restriction to account_of (i.e. 1 account = 1
> > > Agent). BTW, we might think about some other cardinality restrictions,
> > > if needed.
> > >
> > > Changed the range of account_of to foaf:Agent in the specification (as
> > > was decided earlier).
> Thanks
>
> Best,
>
> Alex.
>
> > > That is all about the issues.
> > >
> > > ToDo: add examples to the document.
> > >
> > > Best regards + have a nice weekend,
> > > Uldis Bojars
> > >
> > >
> > > >
> > >
> >
> >
> > --
> > Dr. Axel Polleres
> > email: axel@polleres.net url: http://www.polleres.net/
> >
> >
> >
> > > >
> >
>

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

New: SIOC & Related Ontologies

Primary links

Syndicate

User login