Hi Uldis,

Thank you very much for this thoughtful response to my comments.
Actually, we are in violent agreement on the notion that there is this
opportunity for "explosive growth" in the database. At the moment,
using a bit of arm waving, I am willing to set that argument aside
and, as you thoughtfully query, ask what it is that drives the need
for making everything in some universe of discourse a first class
"citizen" (a "subject", in my vernacular).

This will not be the most thoughtful response I can give, since, at
this time, I have a tiny hole in a busy schedule and I'd like to maybe
just tease open the door into my set of arguments I might pose in
favor of my earlier statements.

Consider the simple "concept map" -- an enormously powerful
constructivist tool used everywhere on this planet in education, and
even now in the construction of ontologies. There, you have nodes and
labeled arcs. Nodes, in my vernacular, are first class citizens,
whereas labeled arcs are not the same. Drop a node in as a reification
of that relationship and now you have another subject about which you
can converse. The query is this: under which use cases would you ever
care to converse about relationships?

A knee-jerk response to that question is: "almost always." Which use
case defines "almost always"? It goes like this. Stan Ulam, one of
the famous mathematicians in the middle of the previous century
(imagine saying that and meaning just a few years back!) was once
asked what he thought about AI (artificial intelligence). His
response, in massive paraphrase, went like this: as soon as they (AI)
figure out how to represent "as" (as in "seeing as"), they will arrive
(whatever that means). We already are good at "isA", but not at "asA".
His story went like this: when we talk about some scene, say, a driver
and passenger cruising past us, we speak of two persons, one *as* a
driver and one *as* a passenger. We are speaking of them in relation
to their "roles".

Now, the ontologists doing OWL have devised two ways to use OWL, one
being the traditional "slot value" approach, and the other being the
"roles" approach. In some problems, they can get away with the
slot-value approach, but in others, they are required to reify the
relationship into a role statement and then use that. That is to say,
they had a situation where a simple triple would not suffice. That
happens when you need to talk about the relationship itself. You need
to say something to the effect that this relationship happened "at
this time", or "on the occasion of" or "was caused by", or something
else. Consider "owl:sameAs". When you think about it, someone invoking
"owl:sameAs" is performing a fiat judgment. Really, "owl:sameAs"
should be reified into an instance onto which one can append reasons
for making the claim. How else will anyone else, not to forget the
computers that interpret the ontologies, be able to explain anything?

The KISS principle is a good one. No argument there. The question
becomes one that speaks in terms of just where it is that you are
simplifying things. You can get by with the slot-value idea (the nodes
and labeled arcs approach) and that is simple. But, does it always
suffice? I believe not. I also believe that as the nature of complex
situations grow in your networked communities, so will the nature of
the means by which you must represent that complexity. When you say
that X blogged Y, what does X mean? What does Y mean? In what way did
X blog Y? Did X answer a question, argue pro or con about a statement
made by Y? What, indeed, did X actually say? What subject(s) did X
raise in the blog? How are those subjects related to other events?

Gordon Pask launched something called Conversation Theory (makes great
google fodder), in which he spoke about several important concepts.
One concept is the speaker's model of the listener. You don't talk
quantum mechanics to a toddler simply because your model of the
toddler strongly suggests the little snapper won't have a clue what
you are saying. Another is your model of your universe, that from
which you draw as you converse. Another is the listener's model of the
speaker, and, of course, the listener's model of the universe. And
then, there is another concept: entailment meshes. Everything we say
carries entailments. The punch line of this paragraph entails my
earlier statements.

By that, I am saying (perhaps claiming) that the SIOC charter appears
to entail a need to be ready to model (represent) very complex
situations. I would go so far as to suggest that, if that charter is
taken seriously, then the ability to model really complex situations
is the primary use case. I will then follow with the suggestion that
role modeling will almost always be required if one takes modeling
seriously. That is to say, nodes with labeled arcs probably will not
suffice.

Strongish claims. I know that. The devil makes me say things like
that. Your mileage might vary, but that's how I see the nature of
modeling communities; communities are organisms. Communities respond
to feedback, they experience loss of memory (decay), in short, they
are complex adaptive systems, and they ought to be modeled as such. I
mean no disrespect to the many really great minds who think up ways to
simplify the tools that facilitate human social intercourse, but I
tend to think that the romantic and reductionist passions in us tend
to win out more often than is best for the stated mission. Strongest
claim: nothing short of holistic thinking should be applied to
modeling, representing, and facilitating social intercourse.

Jack

On 7/26/06, Uldis Bojars wrote:
>
> Hi Jack,
>
> Thanks for comments. True, expressing relationships as first-class
> citizens has to be considered. See this question mentioned in an
> earlier SIOC-Dev post [1].
>
> [1]
> http://groups.google.com/group/sioc-dev/browse_frm/thread/a9f1247d9bbf71f6/
>
> But when you express properties as objects the result is an explosive
> growth of the dataset and it makes queries more complex. It is a
> tradeoff between expressivity and complexity and so far we have aimed
> at reducing complexity in SIOC ("make it as simple as possible, but not
> simpler" :).
>
> There may be cases when relationships as first calls citizens are
> desireable or necessary. SIOC shall allow to express (most of) the
> information contained within a community site. Hence the question is -
> what is the use case for using relationships as first class objects -
> what significant information is there that can not be expressed by SIOC
> as is now?
>
> What would be your suggestions where it is needed?
> And how do you approach this question in your work?
>
> Best,
> Uldis
>
> [ http://captsolo.net/info/ ]
>
> Jack Park wrote:
> > If you construct properties for links (relationships) between
> > entities, e.g. communities, do you not throw away the opportunity to
> > make those relationships first-class citizens? After all, are not
> > those relationships also subjects for discussion/debate/annotation?
> >
> > Properties that help identify subjects are absolutely necessary.
> > Properties that define relationships (links) will need to be capable
> > of being scoped (annotated, decorated, whatever you want to call it)
> > with metadata that describes the nature of the specific instance of
> > the relationship represented. That's a subject-mapping posture. It
> > would nice to think that SKOS might also support relationships as
> > first-class (subjects).
> >
> > Just a half-EURO comment.
> > Jack
> >
> > On 7/19/06, John Breslin wrote:
> > >
> > > So to update where we're at :)
> > >
> > > > 1) Add sioc:Community
> > > > + properties sioc:has_part and sioc:part_of pointing to and from it.
> > >
> > > I think this has been agreed on.
> > >
> > > > 2) sioc:Comment
> > >
> > > This would need to be moved to a types module, to keep the core SIOC
> > > ontology simple. We can then add other subtypes of Post later like
> > > Sticky, Announcement, etc.
> > >
> > > > 3) Properties linking Site to Usergroup
> > >
> > > has_group / group_of seems to be the consensus recommendation.
> > >
> > > > 4) Property linking Site to Sub-Sites
> > >
> > > I read the reasons for not having this on the list, and agreed with them
> > > at the time that we could just use sioc:Community. But the more I
> > > thought about it last night, the more I thought this property might
> > > actually be required. Let's say that there's a site for Semantic Web at
> > > rdfs.org which has an associated community for SIOC at the subsite or
> > > subsection rdfs.org/sioc. If we say Community "SW" has_part Site
> > > "rdfs.org", Community "SIOC" has_part "rdfs.org/sioc" and then that
> > > Community "SW" has_part Community "SIOC", then there's nothing to say
> > > that the Site "rdfs.org" and Site "rdfs.org/sioc" are related (since
> > > Community "SW" will probably have other Sites like "planetrdf.com" etc.
> > > But adding the link between the sites further describes what parts of
> > > the community are related to each other...
> > >
> > > > 5) Subtypes of Forums ?
> > >
> > > Again, can be added to the types module at a later date.
> > >
> > > > 6) subscriber_of / has_subscriber
> > >
> > > I think this is okay.
> > >
> > > > 7) has_sibling -> sibling
> > >
> > > Would like this too :)
> > >
> > > J.
> > > --
> > >
>
>
> >
>

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