Adding to SIOC?

[mmmmmrob]

Hey folks,

We're looking at sioc pretty seriously for a project we're partway
through - changing the underlying model which is very similar to sioc
to use sioc directly.

Couple of quick questions...

If we have things that fit nicely with the concept of sioc:Container
but not the more specific types defined here: http://sioc-project.org/ontology#sec-modules-types
is it preferable to subClass sioc:Container with a class in our
ontology or simply to use sioc:Container directly?

Same questions for sioc:Item, which I guess gets the same answer ;-)

Then, I noticed there was no predicate for ordering items with a
Container other than with next_by_date and previous_by_date. Has the
idea of generic sioc:next and sioc:previous predicates been discussed
before? They would help us with our data very much.

rob

[Alexandre Passant]

Hi,

On Thu, May 15, 2008 at 6:13 PM, mmmmmrob <mmmm...@gmail.com> wrote:
>
> Hey folks,
>
> We're looking at sioc pretty seriously for a project we're partway
> through - changing the underlying model which is very similar to sioc
> to use sioc directly.
>
> Couple of quick questions...
>
> If we have things that fit nicely with the concept of sioc:Container
> but not the more specific types defined here: http://sioc-project.org/ontology#sec-modules-types
> is it preferable to subClass sioc:Container with a class in our
> ontology or simply to use sioc:Container directly?
>
> Same questions for sioc:Item, which I guess gets the same answer ;-)

Indeed, so I'll answer for both, based on the way I'm using SIOC in
order to integrate various existing Web 2.0 services in a corporate
environment.
I'll go for subclassing both elements in a dedicated ontology, in case
your system supports inferencing based on rdfs:subClassOf when
querying data.
Thus, it will let you run queries with different levels of precision,
which could be useful if you add other types of data in the same
system but want to be able to limit queries only to your type of
Container / Item.

Eg: Retrieve all sioc:Post, all myont:XXX, or all sioc:Item (should
retrieve both since they are subclasses of sioc:Item). This will be
more difficult if you directly use sioc:Item, as there is no way to
differentiate sioc:Post from your data when retrieving sioc:Item.
Unless you can de-activate inferencing, or retrieve data that was not
originally a sioc:Item (but became it thanks to inferencing), yet
those aspects depends on the triple store you're using. (Even if
another solution would be to consider the ability to use named graphs
/ provenance)

BTW, do you think your Container / Item types could be integrated in
the SIOC types module ?

>
> Then, I noticed there was no predicate for ordering items with a
> Container other than with next_by_date and previous_by_date. Has the
> idea of generic sioc:next and sioc:previous predicates been discussed
> before? They would help us with our data very much.

I'm not sure, but I think we already discussed it.
Yet, if next_by_date is not what you need, my question will be: how do
you relate two elements with a next property, if that's not by date ?
by ID ?

Alex.

> rob
> >
>

[Uldis Bojars]

On Thu, May 15, 2008 at 7:18 PM, Alexandre Passant <al...@passant.org> wrote:
> On Thu, May 15, 2008 at 6:13 PM, mmmmmrob <mmmm...@gmail.com> wrote:
>>
>> If we have things that fit nicely with the concept of sioc:Container
>> but not the more specific types defined here: http://sioc-project.org/ontology#sec-modules-types
>> is it preferable to subClass sioc:Container with a class in our
>> ontology or simply to use sioc:Container directly?

> I'll go for subclassing both elements in a dedicated ontology, in case

> your system supports inferencing based on rdfs:subClassOf when
> querying data.

[...]

> BTW, do you think your Container / Item types could be integrated in
> the SIOC types module ?

Alex answered this in detail already. And, if you have in mind
subtypes of Container or Item which do not appear in the existing SIOC
Types "palette", consider suggesting to add them to the SIOC Types
module.

>> Then, I noticed there was no predicate for ordering items with a
>> Container other than with next_by_date and previous_by_date. Has the
>> idea of generic sioc:next and sioc:previous predicates been discussed
>> before? They would help us with our data very much.
>
> I'm not sure, but I think we already discussed it.
> Yet, if next_by_date is not what you need, my question will be: how do
> you relate two elements with a next property, if that's not by date ?
> by ID ?

One of SIOC-Dev threads discussing this is at [1]. There may be others.

If the properties you mention are needed then we can add them. In such
case, what about making them a bit more specific (in what they
connect): sioc:next_item / sioc:previous_item?

One thing which bothers me about this is that a "linked list" created
by connecting items with previous/next properties is quite volatile -
what if some item in the middle disappears?. You may then "bridge" the
gap and say, e.g. [ item3 --sioc:next-> item5 ] (if item4 was
removed), but other systems which may have consumed previous
information may end up with item3 having two values of the sioc:next
property.

What are details of your use case and would these concerns worry you?
What do other participants of SIOC-Dev think?

P.S. Another idea (which does not exclude the previous) is to create a
new property of a Container which tells / suggests how (by value of
which property) should the container be sorted.

[1] http://groups.google.com/group/sioc-dev/browse_thread/thread/403060c5b7080507/

Uldis

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

[cdr]

id like to be able to use SIOC+DC exclusively for email

i dont realy care about all the headers, otherwise id make a real schema up

body maps to #content, in-reply-to maps to #reply-of, etc

but how do i say a post is 'directed to' 'has intended recipient'?

i cant find anything. otherwise everything i need fits in fine...

[Rob Styles]

Alex,

Thanks for that - we had considered the points you raise already and had much discussion on it. We don't currently have inferencing in our queries, so in the short term using sioc:Container and sioc:Item would be better for us, and possibly assigning a second type also to allow us to discriminate. That's not good longer term or in the open-world though. So I think we'll subclass.

On the question of ordering, I think next_item and previous_item wuld be good additions. Sioc already has the linked-list problem to debate and address as it has the next and previous by date predicates - I don't have any good ideas for solving that unfortunately.

The use case we have is for a collection of items where the order is assigned explicitly by the community, time and other attributes are not relevant to the sorting of the list, only the explicit order as arranged by someone sorting the list manually - An analogous situation would be the order of tracks on a music album.

rob

[Thomas Schandl]

On 5/15/08, Uldis Bojars <capt...@gmail.com> wrote:

One thing which bothers me about this is that a "linked list" created
by connecting items with previous/next properties is quite volatile -
what if some item in the middle disappears?. You may then "bridge" the
gap and say, e.g. [ item3 --sioc:next-> item5 ] (if item4 was
removed), but other systems which may have consumed previous
information may end up with item3 having two values of the sioc:next
property.

Uldis, we recently talked about adding a post_status property and a list of "status attributes". Having a status "deleted" could be helpful in the case at hand.

Regards,
Thomas

[mmmmmrob]

Are there any more thoughts on a generic next and previous property?
Our use case involves explicit ordering of items, so we'd really like
it.

I'd like to suggest something like this:

<rdf:Property rdf:about="http://rdfs.org/sioc/spec/next">
<rdfs:label xml:lang="en">Next</rdfs:label>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/
XMLSchema#string">The next item or container within an explicitly
ordered container.</rdfs:comment>
<rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Container"/>
<rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Item"/>
<rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Container"/>
<rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Item"/>
</rdf:Property>
<rdf:Property rdf:about="http://purl.org/vocab/resourcelist/
schema#previous">
<rdfs:label xml:lang="en">Previous</rdfs:label>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/
XMLSchema#string">The previous item or container within an explicitly
ordered container.</rdfs:comment>
<rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Container"/>
<rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Item"/>
<rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Container"/>
<rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Item"/>
</rdf:Property>

This would allow us to describe what we're working with using sioc.

Can anyone think of a better way to do this? Or a reason not to add
this to sioc?

cheers

rob

[Simon Reinhardt]

On May 19, 1:10 pm, mmmmmrob <mmmmm...@gmail.com> wrote:
>                 <rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Container"/>
>                 <rdfs:range rdf:resource="http://rdfs.org/sioc/spec/Item"/>
>                 <rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Container"/>
>                 <rdfs:domain rdf:resource="http://rdfs.org/sioc/spec/Item"/>

This would mean that everything in domain and range is *both* a
Container and an Item. Not what you want I assume. Rather you could
do:

<rdfs:range>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:resource="http://rdfs.org/sioc/spec/Container"/>
<owl:Class rdf:resource="http://rdfs.org/sioc/spec/Item"/>
</owl:unionOf>
</owl:Class>
</rdfs:range>

Simon

[Rob Styles]

ah, that is what I meant yes. I seem to have made the mistake on some other work too.

Could you point me at the spec where it says that two domains means the resource must be both?

rob

[Thomas Schandl]

On 5/19/08, Rob Styles <mmmm...@gmail.com> wrote:

Could you point me at the spec where it says that two domains means the resource must be both?

See RDF Schema explanations for range/domain:
http://www.w3.org/TR/rdf-schema/#ch_range

In the case of sioc:Item and sioc:Container it would be especially bad if a resource is an instance of both, because these two classes are disjoint (using owl:disjointWith).

Regards,
Thomas

[Rob Styles]

thomas++ thanks for the answer. I have another ontology I have to go change :-|

rob

[mmmmmrob]

Does anyone have any thoughts on the suggestion to add generic
previous and next properties?

If they don't go into sioc I'll publish them in the ontology we're
writing to extend sioc for academic reading lists.

rob

On May 19, 3:18 pm, "Rob Styles" <mmmmm...@gmail.com> wrote:
> thomas++ thanks for the answer. I have another ontology I have to go change
> :-|
>
> rob
>

> On Mon, May 19, 2008 at 3:16 PM, Thomas Schandl <tom.scha...@gmail.com>
> wrote:

[John Breslin]

Hi Rob -

Uldis and I don't have a problem with it - we always leave out the
domain and range if the OWL thing isn't workable...

We're at Sem Tech though so won't get to do it this week - Uldis, is
next or next_item / previous or previous_item what we proposed when
discussing it on the way over here?

As regards note, is this more than a dc:description associated with a
Container?

Thanks!

John.
--

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