Ontology suggestions needed

Hi all -

Thanks for all your recent comments both on and offlist.

A few more ontology suggestions we need your help with.

(1)

We have sioc:topic which can link Sites, Forums, Posts etc. to resources
that are topics of those documents or containers... (Also,
unfortunately we did not use foaf:topic as the domain is a Document,
which some of the SIOC classes are not). We can also use dc:subject for
free text. But what if we want to say that a particular Post describes
a book or is about two books, perhaps something like sioc:about or
sioc:describes is needed.

(2)

We plan to add Category and Tag classes to the sioc:types module to help
with classifying the above sioc:topics for import/export. Suggestions
welcome.

(3)

We want to add has_part/part_of as subproperties of the corresponding
DCMI terms (hasPart/isPartOf AFAIR).

(4)

I am of the opinion that a Community is NOT a subclass of Space. A
Space is where data resides, but a community extends beyond mere data.

(5)

We still need a way to recommend to people looking at the SIOC Types
module what kind of vocabularies can be used for Items contained in
particular Container subclasses. For example, to say that in a
sioct:AddressBook - that you could use JohnsAddressBook (of type
sioct:AddressBook) container_of John (of type foaf:Person or foaf:Agent)
- without having to define millions of subproperties of container_of to
link things, because these are only suggestions (someone may choose to
put something else into their AddressBook). Ideas needed :-) This is
related to an idea we had for a Related Ontologies ontology [1].

[1] http://wiki.sioc-project.org/index.php/SuggestedOntologiesOntology

At the moment we'll just have something like:

rdfs:label="Address Book">
Describes a collection of personal or organisational
addresses.



rdfs:label="Describes a single person, group or organisation."/>

That seeAlso could be replaced by something more descriptive like...



rdf:resource="http://rdfs.org/sioc/ns#container_of"/>


or:



rdf:resource="http://rdfs.org/sioc/ns#has_container"/>


Something similar could exist for properties that you want to use to
relate to classes ("useAsProperty" with a suggestedDomain and a
suggestedRange).

Thanks, looking forward to hearing from you,

John.

--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.breslin@deri.org

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

Ontology suggestions needed

Hi John.

I am not sure what happened to my previous attempt at replying to
this..
Google Groups seems to have a hickup.

On May 28, 5:57 pm, John Breslin wrote:
> (1)
>
> We have sioc:topic which can link Sites, Forums, Posts etc. to resources
> that are topics of those documents or containers... (Also,
> unfortunately we did not use foaf:topic as the domain is a Document,
> which some of the SIOC classes are not). We can also use dc:subject for
> free text. But what if we want to say that a particular Post describes
> a book or is about two books, perhaps something like sioc:about or
> sioc:describes is needed.

For a novice this seems to be exactly the rdfs:seeAlso relation, but
that is used in a lot of different contexts.

This seems to be the relation:
"the conversation of which this resource is a part of, speaks about
these resources"

After looking at my thesaurus, I like these names:
sioc:describes
sioc:mentions / mentioning / mention_of

It might be interesting to see if/how this relationhsip has been named
by the SKOS project.
It might look into it if I have the time.

> (2)
>
> We plan to add Category and Tag classes to the sioc:types module to help
> with classifying the above sioc:topics for import/export. Suggestions
> welcome.

Will it be a problem to define new topic classes on the fly? People
from the Arts or Humanities,
and librarians might have their own complex "classification elements".

Will it be possible to define that one category is a sub-category of
another one?
Maybe this is still to advanced for treatment inside of SIOC, and
people wanting this
expressive power should be using SKOS.

> (5)
> related to an idea we had for a Related Ontologies ontology [1].
>
> [1]http://wiki.sioc-project.org/index.php/SuggestedOntologiesOntology

I like the SuggestedOntologiesOntology, but it needs a better name ;)

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

Ontology suggestions needed

Hi,

On 5/29/07, Benjamin Heitmann wrote:
>
> >
> > We have sioc:topic which can link Sites, Forums, Posts etc. to resources
> > that are topics of those documents or containers... (Also,
> > unfortunately we did not use foaf:topic as the domain is a Document,
> > which some of the SIOC classes are not). We can also use dc:subject for
> > free text. But what if we want to say that a particular Post describes
> > a book or is about two books, perhaps something like sioc:about or
> > sioc:describes is needed.
>
> For a novice this seems to be exactly the rdfs:seeAlso relation, but
> that is used in a lot of different contexts.
>
> This seems to be the relation:
> "the conversation of which this resource is a part of, speaks about
> these resources"
>
> After looking at my thesaurus, I like these names:
> sioc:describes
> sioc:mentions / mentioning / mention_of

+1
I think that's useful to make a difference between what the post "is
about" (eg sioc:mentions / sioc:about) and what the post describes in
the post itself (RDFa or other RDF-ization system), i.e sioc:describes
/ defines / embeds.
Actually we could keep sioc:topic property to link to any RDF
resource, and then 2 subproperties to make the difference between the"
describe" and "mentions" views.

Eg about the book.
Blogging about a book already described somewhere

x a sioc:Post .
x sioc:about
x rdfs:seeAlso

Blogging about a book I describe in my own post

x a sioc:Post .
x sioc:about
x rdfs:seeAlso

And of course, both can be used in the same post, eg when I'm adding
informations in RDF about a book already described somewhere.

> >
> > We plan to add Category and Tag classes to the sioc:types module to help
> > with classifying the above sioc:topics for import/export. Suggestions
> > welcome.
At the moment, we're using dc:subject for tags, and even for
categories in some blog engines (that's what I did with DC exporter).
So, first, it could be nice to have SIOC properties for this - as
simple as sioc:category and sioc:tag - with a super-property (since
some bloggers will define RDF as a tag, other as categories, it would
be easier to retrieve all posts with a single property in the SPARQL
query)
Then, what's a tag or a category ? We can define that's just text,
which is actually enough in most cases imho. Yet, if we want to create
links (equivalence, specification) between tags or categories in a
simple way, then SKOS would be the best choise. In that case, Richard
Newman's tag ontology [1] is already used - cf revyu.com - and so its
Tag object could be used in SIOC - most of other properties it defines
(who created the tag, when ... can be retrieved from SIOC-ed posts).

Regards,

Alex.

[1] http://www.holygoat.co.uk/projects/tags/

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

Ontology suggestions needed

On 5/29/07, Alexandre Passant wrote:
> > > free text. But what if we want to say that a particular Post describes
> > > a book or is about two books, perhaps something like sioc:about or
> > > sioc:describes is needed.
[...]
> +1
> I think that's useful to make a difference between what the post "is
> about" (eg sioc:mentions / sioc:about) and what the post describes in
> the post itself (RDFa or other RDF-ization system), i.e sioc:describes
> / defines / embeds.

There are 3 types of information to record:

a) a post is about a book, project, etc. - candidates: sioc:mentions;
sioc:about; sioc:is_about; sioc:describes, ...

b) a post contains something - some data rendered to RDF, e.g., a post
contains a Review (note: this also may imply the post is about a book
that it contains a review about - but that's another store) -
candidates sioc:part_of / sioc:has_part; or dcterms:isPartOf /
:hasPart

c) a post is categorised in a category / tag - we are using sioc:topic
for that to point to URI(s), complemented with dc:subject to describe
text only tags (this is somewhat redundant as rdfs:label of object of
sioc:topic contains the text representation too)

---

My choice for (a) would be sioc:is_about.

Some other alternatives (apart from other versions how to name it in
SIOC) is to use sioc:topic (see a response to the next part of Alex's
text) or use a property from another vocabulary if there is something
that fits very well.

As for SIOC and why i suggest name other than sioc:describes for (a).
Notice that Alex mentioned sioc:describes as a property for (b) while
John suggested to use it for (a). If the meaning of a name is vague
even for us we better choose something more precise.

Reason against sioc:is_about can be that it is similar to rdf:about
(which exists in the RDF/XML serialisation only, i think).

---

For (b) - a benefit of defining properties in SIOC and subclassing
from relevant DCTERMS properties is that we can define more precise
meaning of these properties in the context of SIOC, and change them
when necessary.

---

> x a sioc:Post .
> x sioc:about
> x rdfs:seeAlso

You can _almost_ do this with existing WordPress SIOC plugin
installation. Try adding type="application/rdf+xml" to a hyperlink
inside a blog post. This hyperlink will be extracted from the blog
post and appended to the generated RDF as: [ x rdfs:seeAlso
....url.... ].

> At the moment, we're using dc:subject for tags, and even for
> categories in some blog engines (that's what I did with DC exporter).
> So, first, it could be nice to have SIOC properties for this - as
> simple as sioc:category and sioc:tag - with a super-property (since
> some bloggers will define RDF as a tag, other as categories, it would
> be easier to retrieve all posts with a single property in the SPARQL
> query)

Above you also suggested using sioc:topic for things what a post is
about. That would mean using the same sioc:topic for (a) and (c) -
unless choosing new properties like sioc:category and sioc:tag.

First, there is an alternate way to differentiate between tags and
categories - by SIOC Types classes (Category and Tag) as John
described above, e.g.:

post1 sioc:topic tag1 .
tag1 a sioc_t:Tag .
tag1 rdfs:label "some label" .

This has the benefit that you can ask for both tags and categories (so
all the information in case (c)) with a single query - to accomplish
same w. 2 properties (tag and category) you'd need reasoning in place.
As the same time you can query for only tags or categories by adding
filter on the type of sioc_t:Tag object.

It does not prevent you from using SKOS either. tag1 can be a
sioc_t:Tag and a concept in a SKOS taxonomy at the same time.

I hope that someone w. more knowledge of querying and reasoning will
additional detail to this.

---

That is all well until we start using sioc:topic for something else,
e.g., case (a). I'd suggest we keep (a) and (c) in separate properties
they are two distinct cases.

Then we either need to find a new property for (a) or (more painful)
use sioc:topic for it and find another property for tags and
categories. Using sioc:topic for both will make it harder selecting
posts of particular topic/category or finding what categories a post
has.

> Then, what's a tag or a category ? We can define that's just text,
> which is actually enough in most cases imho. Yet, if we want to create
> links (equivalence, specification) between tags or categories in a
> simple way, then SKOS would be the best choise. In that case, Richard

SKOS will help to define taxonomies of categories, but we will need a
URI for tags/categories anyway. What about a universal way to model it
with sioc:topic pointing to a resource which has rdfs:label with the
text of a tag/category?

In most cases tags/categories have a URL on the web, which is
associated with them. Can someone model how would that look together
w. SKOS?

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

Ontology suggestions needed

Hi,

On 5/30/07, Uldis Bojars wrote:
>
>
> There are 3 types of information to record:
>
> a) a post is about a book, project, etc. - candidates: sioc:mentions;
> sioc:about; sioc:is_about; sioc:describes, ...
>
> b) a post contains something - some data rendered to RDF, e.g., a post
> contains a Review (note: this also may imply the post is about a book
> that it contains a review about - but that's another store) -
> candidates sioc:part_of / sioc:has_part; or dcterms:isPartOf /
> :hasPart
>
> c) a post is categorised in a category / tag - we are using sioc:topic
> for that to point to URI(s), complemented with dc:subject to describe
> text only tags (this is somewhat redundant as rdfs:label of object of
> sioc:topic contains the text representation too)

Right, and a) + b) should be mapped with a top-property to make
queries easier ("find all posts that deal with this URI, whatever it's
just mentionning it or defining it")

> > At the moment, we're using dc:subject for tags, and even for
> > categories in some blog engines (that's what I did with DC exporter).
> > So, first, it could be nice to have SIOC properties for this - as
> > simple as sioc:category and sioc:tag - with a super-property (since
> > some bloggers will define RDF as a tag, other as categories, it would
> > be easier to retrieve all posts with a single property in the SPARQL
> > query)
>
> Above you also suggested using sioc:topic for things what a post is
> about. That would mean using the same sioc:topic for (a) and (c) -
> unless choosing new properties like sioc:category and sioc:tag.

I was not clear, sorry.
My idea was to use topic for things a post is about, indeed, but only
for a / b, as I don't consider Tag / Category (even if SKOS concepts)
as "things" but only as URI created to be deferencable, without any
specific properties that gives sense and meaning, as, eg, a
geoname:Feature, a foaf:Person ...

> First, there is an alternate way to differentiate between tags and
> categories - by SIOC Types classes (Category and Tag) as John
> described above, e.g.:
>
> post1 sioc:topic tag1 .
> tag1 a sioc_t:Tag .
> tag1 rdfs:label "some label" .
>
> This has the benefit that you can ask for both tags and categories (so
> all the information in case (c)) with a single query - to accomplish
> same w. 2 properties (tag and category) you'd need reasoning in place.
> As the same time you can query for only tags or categories by adding
> filter on the type of sioc_t:Tag object.
Good idea !

>
> Then we either need to find a new property for (a) or (more painful)
> use sioc:topic for it and find another property for tags and
> categories. Using sioc:topic for both will make it harder selecting
> posts of particular topic/category or finding what categories a post
> has.

Regarding the DC specs we have, about dc:subject:

"Typically, the topic will be represented using keywords, key phrases,
or classification codes. Recommended best practice is to use a
controlled vocabulary. To describe the spatial or temporal topic of
the resource, use the Coverage element."

There's no range in this property, so I think we can use both plain
text or SKOS classification. Thus, we can keep using ds:subject for
tags and categories even if they are SKOS concepts.

And then, keep sioc:topic for "real ressources", with 2 sub-properties
to distinguish a) and b).

DC also have:
* dct:references
"The described resource references, cites, or otherwise points to the
referenced resource."

* dct:hasPart
"The described resource includes the referenced resource either
physically or logically."

that can be respectively used for a) and b)
If so, we'll have to check if sios:topic can be a super-property of both.

>
> SKOS will help to define taxonomies of categories, but we will need a
> URI for tags/categories anyway. What about a universal way to model it
> with sioc:topic pointing to a resource which has rdfs:label with the
> text of a tag/category?
>
> In most cases tags/categories have a URL on the web, which is
> associated with them. Can someone model how would that look together
> w. SKOS?
>

Taken from [1]:

---

ex:post tags:taggedWithTag tag:great , tag:interesting .

# Label the tags -- once is enough.
tag:great a tags:Tag ;
tags:tagName "great" .
tag:interesting a tags:Tag ;
tags:tagName "interesting" .

Remembering that tags are resources, so we can use the raw URIs if we wish:

ex:post tags:taggedWithTag
,
.

---

BTW, one thing we'll have to check is how this ontology can be related to SIOC

Best,

Alex.

[1] http://www.holygoat.co.uk/projects/tags/

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

Ontology suggestions needed

> Will it be possible to define that one category is a sub-category of
> another one?
> Maybe this is still to advanced for treatment inside of SIOC, and
> people wanting this
> expressive power should be using SKOS.

Yes, this would have to be done by SKOS - the structure would be defined
in SKOS, but the presence of a Tag or Category could be done in SIOC Types.

> I like the SuggestedOntologiesOntology, but it needs a better name ;)

Yep :-) Related Ontologies is probably good, or even something simpler
like "Use Me With"...

I'm not sure we'll get to implement this ontology before the submission
deadline, but if people on the list are interested, maybe my previous
post is a good starting point - I'll update it on the wiki page.

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

Ontology suggestions needed

> We have sioc:topic which can link Sites, Forums, Posts etc. to resources
> that are topics of those documents or containers... (Also,
> unfortunately we did not use foaf:topic as the domain is a Document,
> which some of the SIOC classes are not). We can also use dc:subject for
> free text. But what if we want to say that a particular Post describes
> a book or is about two books, perhaps something like sioc:about or
> sioc:describes is needed.

+1 about the comments made by Alexandre Passant.

> We plan to add Category and Tag classes to the sioc:types module to help
> with classifying the above sioc:topics for import/export. Suggestions
> welcome.

In our opinion, it is not necessary to create a new class Category for
the different topics. We think that we can rely on the SKOS ontology,
therefore the range of the property for the topic or subject of a post
should be skos:concept. This allows us to reuse different lexical
resources, such us thesauri, classifications or folksonomies.

> We want to add has_part/part_of as subproperties of the corresponding
> DCMI terms (hasPart/isPartOf AFAIR).

I think that we've to take only one way: if we want generic or specific
properties. The first option matches with the properties already defined
in DC, but if we want to choice the second one we'll have to give a good
description about the meaning of these relationships.

> I am of the opinion that a Community is NOT a subclass of Space. A
> Space is where data resides, but a community extends beyond mere data.

Completely agreed. Therefore we should give a clear description about
the role that this class plays in SIOC. We think that community have two
different senses and we have to choose one of them and refine it:

1) sioc:Community as collective: a collective is a collection of agents
as sioc:Users are. By this definition, sioc:Usergroup is a subclass of
sioc:Community.

2) sioc:Community as organization: an organization is a social system
where some agents or actors are involved in, and play different roles in
different situations.

Also, the organization has a structure and several resources for
organization purposes and activity.

Best regards,

--
Sergio Fernández - sergio.fernandez@fundacionctic.org
R&D Deparment
CTIC Foundation - www.fundacionctic.org
Phone: +34 984 29 12 12
Fax: +34 984 39 06 12
Edificio Centros Tecnológicos
Parque Científico Tecnológico
33203 Cabueñes - Gijón - Asturias - Spain

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

Ontology suggestions needed

Hi John,

I don't have any specific suggestions (no time to look closely) but
here's a meta-level point for your consideration on property naming.

timbl has been advocating the use of role nouns and only using one
direction of predicate (I think largely prompted by experiences with
Tabulator), i.e. instead of:

x has_parent y .
y parent_of x .

simply:

x parent y .

(replacing has_parent)

and in the background -

_:po owl:inverseOf parent .
_:po rdfs:label "Parent Of" .

It may be the case this style would be a natural fit with some of the
SIOC properties.
(I honestly don't know, but suspect it's worth considering ;-)

See also:
http://esw.w3.org/topic/RoleNoun
http://www.w3.org/2006/Talks/1019-tab-tbl/#(11)
http://dig.csail.mit.edu/breadcrumbs/node/72

Cheers,
Danny.

--

http://dannyayers.com

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