swaml:previousByDate/nextByDate (was: Threads?)

2007, April 10 - 19:03 — Benja Fallenstein

Hi Sergio,

That's interesting. Mind elaborating why you did this? Or do you have
a link to an explanation?

I'm interested because when using SIOC for IRC logs, we had to figure
out how to order IRC events that come in the same second; we hacked it
by using the millisecond part of dcterms:created to contain a counter,
so that you'd have the event at 12:03:01 followed by the event at
"12:03:01.001" followed by the event at "12:03:01.002".

Would you consider changing the definition of swaml:previousByDate and
swaml:nextByDate not to be specific to mailing lists?

I'm wondering how it would work if the same message is in more than
one container, though; it seems to me that SIOC allows both modelling
these as two sioc:Posts and modelling them as one, which wouldn't be
good for previousByDate/nextByDate :-/

- Benja

2007/4/10, Sergio Fdez :
>
>
> > I'm confused about this: Does this add information beyond what we know
> > through sioc:reply_of? Or is this just an abbreviation of information
> > that sioc:reply_of already gives us?
>
> I thought the same..., that a thread could be composed using
> sioc:has_reply and sioc:reply_of relationships (that is indeed what
> Buxon does). But if we want to give one more a richer description about
> thread, perhaps TDL [1] would be interesting for us.
>
> BTW, in SWAML we had to add two properties [2] to express chronological
> information between sioc:Post's, but this is another theme.
>
> Regards,
>
> [1] http://www.eyrie.org/~zednenem/2002/web-threads/
> [2] http://swaml.berlios.de/ns/0.2#
>
> --
> __ ___ _ _
> \ \ / (_) |_(_)___ _ _ Sergio Fdez
> \ \/\/ /| | / / / -_) '_| GNU/LiNUX User: #298803
> \_/\_/ |_|_\_\_\___|_| Web: http://www.wikier.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
-~----------~----~----~----~------~----~------~--~---

Developers

2007, May 17 - 08:38 — Wikier

swaml:previousByDate/nextByDate (was: Threads?)

> That's interesting. Mind elaborating why you did this?

In mailing lists always is interesting to know the chronological order
of the messages posted. Classic syntactic exporters (such as pipermail)
already provide long ago this feature.

> I'm interested because when using SIOC for IRC logs, we had to figure
> out how to order IRC events that come in the same second; we hacked it
> by using the millisecond part of dcterms:created to contain a counter,
> so that you'd have the event at 12:03:01 followed by the event at
> "12:03:01.001" followed by the event at "12:03:01.002".

For a mailing list it's much more simple, because it's the mailing list
manager who has made that work. Then we suppose that the messages will
go correctly ordered into the mbox file.

> Would you consider changing the definition of swaml:previousByDate and
> swaml:nextByDate not to be specific to mailing lists?

Sure, but I think that it's already enough generic (both properties have
sioc:Post as rdfs:domain and rdfs:range) if we ignore the comment.
Perhaps we could make more generic those descriptions.

> I'm wondering how it would work if the same message is in more than
> one container, though; it seems to me that SIOC allows both modelling
> these as two sioc:Posts and modelling them as one, which wouldn't be
> good for previousByDate/nextByDate :-/

Interesting question... now SWAML'll give two different URIs for same
message posted in two different mailing lists. It is left much work to
do...

Best regards,

--
__ ___ _ _
\ \ / (_) |_(_)___ _ _ Sergio Fdez
\ \/\/ /| | / / / -_) '_| GNU/LiNUX User: #298803
\_/\_/ |_|_\_\_\___|_| Web: http://www.wikier.org/

2007, May 17 - 08:38 — CaptSolo

swaml:previousByDate/nextByDate (was: Threads?)

On 4/10/07, Sergio Fdez wrote:
>
> > Would you consider changing the definition of swaml:previousByDate and
> > swaml:nextByDate not to be specific to mailing lists?
>
> Sure, but I think that it's already enough generic (both properties have
> sioc:Post as rdfs:domain and rdfs:range) if we ignore the comment.
> Perhaps we could make more generic those descriptions.

Should we include these properties in the SIOC ontology then? If they
apply to different types of sioc:Post(s) then it would make sense.

The only question / problem, which applies to any "linked list"
ordering in general is what happens when data changes - e.g. - what
will happen if you remove one of the messages in this chain?

(a) if you remove a message from the mailing list itself, regenerate
RDF data and put that data in a store that also contains the old
information, you may end up with confusing information - a message
pointing to two different messages as nextByDate. (maybe it's a
non-problem, who knows.)

(b) if you delete information about this message only from the RDF
store, that may break the "next/previous" chain.

Probably these properties are best not included in the original
"dynamic" data, but being created using rules by some application
along the data conversion chain. Such an application would look at the
original "hard" evidence (e.g., date order in dct:created) and
generate next/previous thread information.

> > I'm wondering how it would work if the same message is in more than
> > one container, though; it seems to me that SIOC allows both modelling
> > these as two sioc:Posts and modelling them as one, which wouldn't be
> > good for previousByDate/nextByDate :-/
>
> Interesting question... now SWAML'll give two different URIs for same
> message posted in two different mailing lists. It is left much work to
> do...

Makes practical sense. These messages may also get different reply
threads in different mailing lists (depends if all mailing lists are
copied in the reply), etc. But it can also be interesting to see how
to express the fact that this is the same message (in different
mailing lists). Do you currently do that somehow?

Uldis

[ http://sioc-project.org/ ]

2007, May 17 - 08:38 — Diego Berrueta

swaml:previousByDate/nextByDate (was: Threads?)

Hi, Uldis, all. Please read my comments inline:

El jue, 10-05-2007 a las 17:27 +0100, Uldis Bojars escribió:
> The only question / problem, which applies to any "linked list"
> ordering in general is what happens when data changes - e.g. - what
> will happen if you remove one of the messages in this chain?
>
> (a) if you remove a message from the mailing list itself, regenerate
> RDF data and put that data in a store that also contains the old
> information, you may end up with confusing information - a message
> pointing to two different messages as nextByDate. (maybe it's a
> non-problem, who knows.)
>
> (b) if you delete information about this message only from the RDF
> store, that may break the "next/previous" chain.

Maybe you can prove me wrong, but in this scenario, I think the same
thing would happen to the "has_reply/reply_of" chain, so actually the
addition of "next_by_date/previous_by_date" properties doesn't introduce
a new issue in the ontology.

By the way, from my point of view, "next/previous" shouldn't be declared
as a transitive property. In fact, if there was a need to have
transitive properties for temporal relationships (I think there isn't),
my proposal would be to call them "follows/precedes".

> Makes practical sense. These messages may also get different reply
> threads in different mailing lists (depends if all mailing lists are
> copied in the reply), etc. But it can also be interesting to see how
> to express the fact that this is the same message (in different
> mailing lists). Do you currently do that somehow?

That's a good point, and SWAML isn't addressing this issue at the
moment. At a first glance, I believe cross-posted messages must have the
same identity (i.e.: they must be the same instance, or have an
owl:sameAs relationship). However, I recognize that the problem requires
a deeper study.

Regards,

--
Diego Berrueta
Fundación CTIC

2007, May 17 - 08:38 — CaptSolo

swaml:previousByDate/nextByDate (was: Threads?)

Hi Diego,

Thanks for comments.

On 5/10/07, Diego Berrueta wrote:

> Maybe you can prove me wrong, but in this scenario, I think the same
> thing would happen to the "has_reply/reply_of" chain, so actually the
> addition of "next_by_date/previous_by_date" properties doesn't introduce
> a new issue in the ontology.

True, it's a generic issue (or non-issue).
Alexandre proposed transitive properties as a potential solution.

> By the way, from my point of view, "next/previous" shouldn't be declared
> as a transitive property. In fact, if there was a need to have
> transitive properties for temporal relationships (I think there isn't),
> my proposal would be to call them "follows/precedes".

Could you discuss with Alexandre the motivation for / against
transitivity. If there are doubts it is better to leave it out and add
at a later stage, if needed.

One reason against transitivity is the literal meaning of
"next_by_date" - as only one item can be _the_next_ item after the
current one. Is there enough motivation for transitivity to make a
name / meaning change to follows[_by_date] / precedes[_by_date] ?

> That's a good point, and SWAML isn't addressing this issue at the
> moment. At a first glance, I believe cross-posted messages must have the
> same identity (i.e.: they must be the same instance, or have an
> owl:sameAs relationship). However, I recognize that the problem requires
> a deeper study.

We thought about this in SIOC before, but at the moment I can't recall
what was the idea.

owl:sameAs seems a bit too strict as a person might reply to the
message in one mailing list without replying to it in the other list
where the original message was cross-posted. Then you may want to add
a sioc:has_reply relationship only to one of these instances of the
original message (if you wish to be precise).

Best,
Uldis

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

2007, May 17 - 08:38 — Diego Berrueta

swaml:previousByDate/nextByDate (was: Threads?)

El jue, 10-05-2007 a las 22:13 +0100, Uldis Bojars escribió:
> Could you discuss with Alexandre the motivation for / against
> transitivity. If there are doubts it is better to leave it out and add
> at a later stage, if needed.
>
> One reason against transitivity is the literal meaning of
> "next_by_date" - as only one item can be _the_next_ item after the
> current one.

In addition to this reason, I'd like to propose another one: computing
if a Post "follows_by_date" another Post can be done in O(1) time by
simply comparing the date of the Posts, so it is really cheap. However,
adding a transitive relationship to make explicit this information
requires to add O(n^2) triples, where "n" is the number of Posts. Even
if most of these triples are inferred by a reasoner, this is a huge
amount of memory!

On the other hand, given a collection of Posts without "next_by_date"
relationships, computing if a Post is the "next_by_date" of another one
requires O(n) time, because you have to check that no other Post was
posted between the other ones (Of course, this would be cheaper if Posts
were sorted, but this is not the case in RDF stores). At the same,
adding a non-transitive "next_by_date" relationship requires just O(n)
triples, which is an affordable amount of memory in order to make this
query time-efficient.

> owl:sameAs seems a bit too strict as a person might reply to the
> message in one mailing list without replying to it in the other list
> where the original message was cross-posted. Then you may want to add
> a sioc:has_reply relationship only to one of these instances of the
> original message (if you wish to be precise).

In my opinion, such precission isn't required in most scenarios. The
important information here is that you are replying to a message.
Furthermore, both messages (the original one and the reply) will have
links to the Forums they were posted to.

Regarding this, if we share the same instance of Post for the copies of
a cross-posted message in several Forums, then
"next_by_date"/"previous_by_date" should not be [inverse] functional
properties, because the same instance would be a member of several
sequences.

As I said before, I still have some doubts about this issue. I don't
like the idea to introduce a new property (say sioc:cross_posted) to
link different instances of Post that are "almost the same, but not
actually the same because they were posted in different Forums".
However, I agree that we should be careful and not to rush into making
them the same instance without being aware of the consequences.

Any thoughts?

Best regards,

P.S.: I'm glad to announce that Sergio will report great news for SWAML
as soon as he comes back from Seville ;-)

--
Diego Berrueta
R&D Department - CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Científico Tecnológico Gijón-Asturias-Spain
www.fundacionctic.org

2007, May 17 - 08:38 — terraces

swaml:previousByDate/nextByDate (was: Threads?)

Hi,

On 5/10/07, Uldis Bojars wrote:
>
> Hi Diego,
>
> > By the way, from my point of view, "next/previous" shouldn't be declared
> > as a transitive property. In fact, if there was a need to have
> > transitive properties for temporal relationships (I think there isn't),
> > my proposal would be to call them "follows/precedes".
>
> Could you discuss with Alexandre the motivation for / against
> transitivity. If there are doubts it is better to leave it out and add
> at a later stage, if needed.

I mentionned transitivity for nextByDate property because I think that
makes sense since the notion of "by date" involves a chronological
aspect. (so there's a transitivity regarding more recent / older
items). The main advantage is using a reasoner + OWL capabilities when
available, rather than a query with dc:date > xx to find all more
recent mails.
Yet, indeed, that's not that much useful, but I think that's cleaner.

If defining a generic next / previous property (that do not involve
chronological aspect), there is yet no particular reason to use
transitivity (since there can be different semantics in the 'next'
meaning depending the platform / user)

> One reason against transitivity is the literal meaning of
> "next_by_date" - as only one item can be _the_next_ item after the
> current one. Is there enough motivation for transitivity to make a
> name / meaning change to follows[_by_date] / precedes[_by_date] ?
Indeed, if by next_by_date you mention *the* next item, there must be
another name for 'any item after the current one re. date'.
But if transitivity is not needed at the moment, let's use
next_by_date, and we might find a way to deal with it - or not -
later.

Best,

Alex.

2007, May 17 - 08:38 — terraces

swaml:previousByDate/nextByDate (was: Threads?)

Hi,

On 5/10/07, Uldis Bojars wrote:
>
> On 4/10/07, Sergio Fdez wrote:
> >
> > > Would you consider changing the definition of swaml:previousByDate and
> > > swaml:nextByDate not to be specific to mailing lists?
> >
> > Sure, but I think that it's already enough generic (both properties have
> > sioc:Post as rdfs:domain and rdfs:range) if we ignore the comment.
> > Perhaps we could make more generic those descriptions.
>
> Should we include these properties in the SIOC ontology then? If they
> apply to different types of sioc:Post(s) then it would make sense.
+1
It can also apply to IRC conversations, instant messaging ...

> The only question / problem, which applies to any "linked list"
> ordering in general is what happens when data changes - e.g. - what
> will happen if you remove one of the messages in this chain?
Actually, I think that defining these properties as transitive (and
also as inverses) would help, at least theorically.

> (a) if you remove a message from the mailing list itself, regenerate
> RDF data and put that data in a store that also contains the old
> information, you may end up with confusing information - a message
> pointing to two different messages as nextByDate. (maybe it's a
> non-problem, who knows.)
If nextByDate is defined as a transitive property, getting more than
one message related with nextByDate won't be a problem (BTW, in this
case using a store that differentiates original / inferred statements
would help).
The problem is more related to RDF data stores maintenance, since the
"nextByDate post" exists in the store but not in the original souce.
Cannot it be solved by using context / named graphs to add information
in the store ?

>
> (b) if you delete information about this message only from the RDF
> store, that may break the "next/previous" chain.
>
> Probably these properties are best not included in the original
> "dynamic" data, but being created using rules by some application
> along the data conversion chain. Such an application would look at the
> original "hard" evidence (e.g., date order in dct:created) and
> generate next/previous thread information.

Even if they are included in the original data, it shouldn't break
with a reasoner.
Let's say we have
a sioc:nextByDate b
b sioc:nextByDate c
=> a sioc:nextByDate c
Removing b (a sioc:Post) shouldn't break the chain, as we'll still
have a sioc:nextByDate c.
Yet, we must take care of removing both original statements, but I
think a "clean" remove of b from the store can make it (by removing
all properties associated to b)

Best,

Alex.

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

swaml:previousByDate/nextByDate (was: Threads?)

Primary links

Syndicate

User login