Modelling project relationships

[Ross Gardler]

Suppose I have two projects, A and B

Project A is dependent on project B.

How to I model this relationship in our RDF?

[Stuart A. Yeates]

There isn't in DOAP, FOAF or SIOC (I've just checked).

Popping into the #swig I talked to da...@dajobe.org[1] who recommended
proposing doap:depends to the doap mailing list[2].

We'll need to ponder the intended semantics before proposing this.
What I _think_ we want is "The software outputs of Project A are
runtime dependent on the software outputs Project B other than via a
standard"

cheers
stuart

[1] http://www.dajobe.org/
[3] http://lists.usefulinc.com/mailman/listinfo/doap-interest

[Stuart A. Yeates]

I should have included a link to the #swig logs:

http://chatlogs.planetrdf.com/swig/2007-04-27.html#T16-23-20

I'm snail, dajobe is da...@dajobe.org

cheers
stuart

[Ross Gardler]

On 27/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
>
> On 4/26/07, Ross Gardler <rgar...@apache.org> wrote:
> >
> > Suppose I have two projects, A and B
> >
> > Project A is dependent on project B.
> >
> > How to I model this relationship in our RDF?
>
> There isn't in DOAP, FOAF or SIOC (I've just checked).
>
> Popping into the #swig I talked to da...@dajobe.org[1] who recommended
> proposing doap:depends to the doap mailing list[2].
>
> We'll need to ponder the intended semantics before proposing this.
> What I _think_ we want is "The software outputs of Project A are
> runtime dependent on the software outputs Project B other than via a
> standard"

There are different types of dependency, off the top of my head we have:

- runtime
- compile time
- optional

I'm not sure if it is necessary to model them in this amount of detail
for our current use case (runtime dependency) but it's worth thinking
ahead as far as we can.

Whilst thinking ahead, in some cases this information can be derived
from build configs. If we can I would like to be able to indicate that
these dependencies are defined in, for example, an ivy.xml file or a
maven pom (both are XML config files).

Ross

[Stuart A. Yeates]

danja on #swig pointed me[2] to his currently stalled vocabulary[1].
Which looks very close to what we need. As discussed in the logs,
there's some work that needs doing on the vocab, but no more than we'd
need to do if we were doing it ourselves.

Currently the largest problem with the vocabulary is ambiguity about
the intra-project / inter-project nature of some of the links. danja
seems keen to accept contributions.

Also in the logs is a warning that "that DOAP was not intended to be a
superset of (rpm | deb | ebuild | ...) functionality" which I think we
need to be very careful of. A full semantic description of the
software build process would be very nice, but I think it's outside
the remit of simal.

cheers
stuart

[1] http://chatlogs.planetrdf.com/swig/2007-04-27.html#T17-27-42
[2] http://dannyayers.com:88/xmlns/project/

[Ross Gardler]

On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
>
> danja on #swig pointed me[2] to his currently stalled vocabulary[1].
> Which looks very close to what we need. As discussed in the logs,
> there's some work that needs doing on the vocab, but no more than we'd
> need to do if we were doing it ourselves.
>
> Currently the largest problem with the vocabulary is ambiguity about
> the intra-project / inter-project nature of some of the links. danja
> seems keen to accept contributions.

This seems to have considerable overlap with the more active and more
complete Baetle.

It is worth noting that I have a GSoC student that will be working on
Baetle over at Forrest, so we will have a great deal of support for
that if things go well.

Since this proposed vocabulary does not have what we need we may be
better going with Baetle. What do you think?

> Also in the logs is a warning that "that DOAP was not intended to be a
> superset of (rpm | deb | ebuild | ...) functionality" which I think we
> need to be very careful of. A full semantic description of the
> software build process would be very nice, but I think it's outside
> the remit of simal.

I totally agree. In fact, this is why I asked about being able to link
to external files, such ivy.xml or maven poms to capture this data.
These are XMl files not RDF but we can extract the info from there.

The problem is, not all projects use this kind of dependency management tool.

So, what do people think our best approach is?

Ross

[Ross Gardler]

SOrry forgot the link to Baetle - http://code.google.com/p/baetle/

Ross

[Stuart A. Yeates]

On 4/29/07, Ross Gardler <rgar...@apache.org> wrote:
>
> On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
> >
> > danja on #swig pointed me[2] to his currently stalled vocabulary[1].
> > Which looks very close to what we need. As discussed in the logs,
> > there's some work that needs doing on the vocab, but no more than we'd
> > need to do if we were doing it ourselves.
> >
> > Currently the largest problem with the vocabulary is ambiguity about
> > the intra-project / inter-project nature of some of the links. danja
> > seems keen to accept contributions.
>
> This seems to have considerable overlap with the more active and more
> complete Baetle.
>
> It is worth noting that I have a GSoC student that will be working on
> Baetle over at Forrest, so we will have a great deal of support for
> that if things go well.
>
> Since this proposed vocabulary does not have what we need we may be
> better going with Baetle. What do you think?

Baetle is new to me, and it is slightly worrying that #swig didn't
point me towards it.

> > Also in the logs is a warning that "that DOAP was not intended to be a
> > superset of (rpm | deb | ebuild | ...) functionality" which I think we
> > need to be very careful of. A full semantic description of the
> > software build process would be very nice, but I think it's outside
> > the remit of simal.
>
> I totally agree. In fact, this is why I asked about being able to link
> to external files, such ivy.xml or maven poms to capture this data.
> These are XMl files not RDF but we can extract the info from there.
>
> The problem is, not all projects use this kind of dependency management tool.
>
> So, what do people think our best approach is?

None of the projects mentioned so far represent the project dependency
that we need, so we're going to have to do at least some of the heavy
lifting ourselves. The question is where the most appropriate place
for that heavy lifting to be done. Currently I'm thinking that adding
a dependsOn property to DOAP is the best option. Something like:

...
<rdf:Property rdf:about="http://usefulinc.com/ns/doap#DependsOn">
<rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />

<rdfs:label xml:lang="en">Depends on</rdfs:label>
<rdfs:label xml:lang="fr">?</rdfs:label>
<rdfs:label xml:lang="es">?</rdfs:label>
<rdfs:comment xml:lang="en">A project which this project depends
upon</rdfs:comment>
<rdfs:comment xml:lang="fr">?</rdfs:comment>
<rdfs:comment xml:lang="es">?</rdfs:comment>

<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
<rdfs:domain rdf:resource="http://usefulinc.com/ns/doap#Project" />
<rdfs:range rdf:resource="http://usefulinc.com/ns/doap#Project" />
</rdf:Property>
...

I'm not sure about the range, which I may have set too restrictively.
Leaving out the range would allow us to also say that that project
depends on a standard. I don't think I can specify a range that of
either a DOAP project or an apache standard without creating a
circular dependency (which seems like a bad thing) or adding the new
property to the apache extensions (which seems like a bad thing since
this RDF isn't being used by apache).

cheers
stuart

[Ross Gardler]

On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:

...

> Baetle is new to me, and it is slightly worrying that #swig didn't
> point me towards it.

One of the reasons I am not keen on IRC is because the information you
get is dependent on who happens to be there at the time you ask the
question. It's great for some types of request, but really bad for
others (and when I go to IRC it its my time).

Then again, it could be that Baetle is not useful. All I know about it
is the stuff on their website. Simal doesn't need it right now, so we
can afford to wait to see what happens with the Forrest plugins.

> None of the projects mentioned so far represent the project dependency
> that we need, so we're going to have to do at least some of the heavy
> lifting ourselves. The question is where the most appropriate place
> for that heavy lifting to be done. Currently I'm thinking that adding
> a dependsOn property to DOAP is the best option.

Do you want to sound this out on the DOAP list? I'm pretty new to
RDF/XML so I doubt I could have a sensible conversation, but if you
don't have the time I'll do my best.

> Something like:
>
> ...
> <rdf:Property rdf:about="http://usefulinc.com/ns/doap#DependsOn">
> <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
>
> <rdfs:label xml:lang="en">Depends on</rdfs:label>
> <rdfs:label xml:lang="fr">?</rdfs:label>
> <rdfs:label xml:lang="es">?</rdfs:label>
> <rdfs:comment xml:lang="en">A project which this project depends
> upon</rdfs:comment>
> <rdfs:comment xml:lang="fr">?</rdfs:comment>
> <rdfs:comment xml:lang="es">?</rdfs:comment>
>
> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
> <rdfs:domain rdf:resource="http://usefulinc.com/ns/doap#Project" />
> <rdfs:range rdf:resource="http://usefulinc.com/ns/doap#Project" />
> </rdf:Property>
> ...
>

I think I understand all that, but I can't comment on it being the
right thing to do or not. I'll bow to your greater knowledge of
RDF/XML.

> I'm not sure about the range, which I may have set too restrictively.

Well, I had no idea of what domain and range were, so for those who
are clueless like me I found [1] useful.

> Leaving out the range would allow us to also say that that project
> depends on a standard.

That would be good, but...

> I don't think I can specify a range that of
> either a DOAP project or an apache standard without creating a
> circular dependency (which seems like a bad thing) or adding the new
> property to the apache extensions (which seems like a bad thing since
> this RDF isn't being used by apache).

I'll float this on the relevant apache list and report back, maybe
they'd be interested in adopting this.

Ross

[1] http://bat710.univ-lyon1.fr/~champin/rdf-tutorial/node15.html

[Ross Gardler]

On 29/04/07, Ross Gardler <rgar...@apache.org> wrote:

> On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:

...

> > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#DependsOn">

> > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> >
> > <rdfs:label xml:lang="en">Depends on</rdfs:label>
> > <rdfs:label xml:lang="fr">?</rdfs:label>
> > <rdfs:label xml:lang="es">?</rdfs:label>
> > <rdfs:comment xml:lang="en">A project which this project depends
> > upon</rdfs:comment>
> > <rdfs:comment xml:lang="fr">?</rdfs:comment>
> > <rdfs:comment xml:lang="es">?</rdfs:comment>
> >
> > <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
> > <rdfs:domain rdf:resource="http://usefulinc.com/ns/doap#Project" />
> > <rdfs:range rdf:resource="http://usefulinc.com/ns/doap#Project" />
> > </rdf:Property>
> > ...
> >

...

> > I don't think I can specify a range that of
> > either a DOAP project or an apache standard without creating a
> > circular dependency (which seems like a bad thing) or adding the new
> > property to the apache extensions (which seems like a bad thing since
> > this RDF isn't being used by apache).
>
> I'll float this on the relevant apache list and report back, maybe
> they'd be interested in adopting this.

I just went off to do that, in the process I thought I ought to look
at how the ASF define their standards implementation. They do this:

<asfext:implements>
<asfext:Standard>
<asfext:title>Extensible Stylesheet Language - Formatting
Objects (XSL-FO 1.1)</asfext:title>
<asfext:body>W3C</asfext:body>
<asfext:id>XSL 1.1</asfext:id>
<asfext:url rdf:resource="http://www.w3.org/TR/xsl11/"/>
</asfext:Standard>
</asfext:implements>

What is to stop us doing something similar, like:

<simalext:dependsOn>
<doap:Project rdf:resource="http://foo.org/bar#"/>
</simalext>

Or, if we don't know the Project resource URI:

<simalext:dependsOn>
<doap:Project>
...
</doap:Project
</simalext>

Forgive me if this makes no sense at all, I'm learning RDF/XML as I go
and figured a brainstorming suggestion may help me learn.

Ross

[Ross Gardler]

OK, I'm doing more background reading on this, and it appears that the
above is exactly what you are suggesting - is that right? In
particular, is the second example I give possible?

Ross

[Stuart A. Yeates]

On 4/29/07, Ross Gardler <rgar...@apache.org> wrote:
>
> On 29/04/07, Ross Gardler <rgar...@apache.org> wrote:
> > On 29/04/07, Ross Gardler <rgar...@apache.org> wrote:
> > > On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
> >
> > ...
> >
> > > > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#DependsOn">
> > > > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />

Assuming you actually meant to say:

<doap:Project rdf:resource="http://example.net/bar#">
<simalext:dependsOn>
<doap:Project rdf:resource="http://example.com/foo#"/>
</simalext>
<doap:Project>

and

<doap:Project rdf:resource="http://example.net/bar#">

<simalext:dependsOn>
<doap:Project>
...
</doap:Project
</simalext>

<doap:Project>

The two changes I've made are (a) I've provided both a domain and and
range (necessary for any well formed relationship) and (b) move to
proper use of the example domain (in the other sense) names.

The unresolved question is whether we use a "simalext," "apacheext" or
"doap" namespace.

cheers
stuart

[Ross Gardler]

On 30/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:

> The unresolved question is whether we use a "simalext," "apacheext" or
> "doap" namespace.

OK, so I'm getting the hang of RDF/XML slowly.

You take it to the DOAP list, I'll take it to the Apache list and
we'll see who wants it.

In the meantime we can put this into a simalext namespace so that we
can start encoding this, right?

I'll create an issue anyway. Our code should be in SVN very soon, as
you will know if you are following the issue tracker messages.

Ross

[Ross Gardler]

On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:

...

> ...
> <rdf:Property rdf:about="http://usefulinc.com/ns/doap#DependsOn">
> <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
>
> <rdfs:label xml:lang="en">Depends on</rdfs:label>
> <rdfs:label xml:lang="fr">?</rdfs:label>
> <rdfs:label xml:lang="es">?</rdfs:label>
> <rdfs:comment xml:lang="en">A project which this project depends
> upon</rdfs:comment>
> <rdfs:comment xml:lang="fr">?</rdfs:comment>
> <rdfs:comment xml:lang="es">?</rdfs:comment>
>
> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
> <rdfs:domain rdf:resource="http://usefulinc.com/ns/doap#Project" />
> <rdfs:range rdf:resource="http://usefulinc.com/ns/doap#Project" />
> </rdf:Property>
> ...

OK, so here is a different use case. I think it may be similar enough
to the "depends on" relationship to be encoded in the same element:

I have two projects, A and B. Project A is related to project B. The
relationship could be one of a subset of types, for example
"dependsOn", "potentialCollaborator", "collaborator".

What should our schema look like for this?

Ross

[Ross Gardler]

Any thoughts on this?

Ross

[Stuart A. Yeates]

There are essentially two options here:

1) we go for a generic unidirectional "dependency relationship"

2) we enumerate a set of unidirectional relationships.

(1) has the problem that it's vague and doesn't do everything we want

(2) would almost certainly require us to create and maintain our own
namespace, We'd have to describe in detail the relationships and debug
those descriptions. If we make the descriptions reusable, we run into
problems in that we start to recreate a build dependency system. If we
make the descriptions overly specific to simal we preclude reuse and
run into problems if simal evolves. (1) has been already been done for
personal relationships and can be found at:
http://vocab.org/relationship/

cheers
stuart

[Ross Gardler]

On 12/05/07, Stuart A. Yeates <sye...@gmail.com> wrote:
>
> On 5/11/07, Ross Gardler <rgar...@apache.org> wrote:
> >
> > On 02/05/07, Ross Gardler <rgar...@apache.org> wrote:
> > > On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
...

> > > OK, so here is a different use case. I think it may be similar enough

> > > to the "depends on" relationship to be encoded in the same element:
> > >
> > > I have two projects, A and B. Project A is related to project B. The
> > > relationship could be one of a subset of types, for example
> > > "dependsOn", "potentialCollaborator", "collaborator".
> > >
> > > What should our schema look like for this?

...

> There are essentially two options here:
>
> 1) we go for a generic unidirectional "dependency relationship"
>
> 2) we enumerate a set of unidirectional relationships.
>
> (1) has the problem that it's vague and doesn't do everything we want

And so is not appropriate.

> (2) would almost certainly require us to create and maintain our own
> namespace, We'd have to describe in detail the relationships and debug
> those descriptions. If we make the descriptions reusable, we run into
> problems in that we start to recreate a build dependency system. If we
> make the descriptions overly specific to simal we preclude reuse and
> run into problems if simal evolves.

Can you expand on "we start to recreate a build dependency system".
I'm not really following this. If someone consumes our RDF and is
unable to parse the extension we create they simply ignore them don't
they?

I agree with you observation about "overly specific to simal".
However, I think the kinds of relationships we wish to maintain are
fairly standard, so that shouldn't be a problem.

> (1) has been already been done for
> personal relationships and can be found at:
> http://vocab.org/relationship/

Now I'm confused. That vocab looks more like an implementation of (2)
to me. It enumerates all possible dependency types. Was that a typo or
am I missing something.

Ross

[Stuart A. Yeates]

On 5/12/07, Ross Gardler <rgar...@apache.org> wrote:
>
> On 12/05/07, Stuart A. Yeates <sye...@gmail.com> wrote:
> >
> > On 5/11/07, Ross Gardler <rgar...@apache.org> wrote:
> > >
> > > On 02/05/07, Ross Gardler <rgar...@apache.org> wrote:
> > > > On 29/04/07, Stuart A. Yeates <sye...@gmail.com> wrote:
> ...
>
> > > > OK, so here is a different use case. I think it may be similar enough
> > > > to the "depends on" relationship to be encoded in the same element:
> > > >
> > > > I have two projects, A and B. Project A is related to project B. The
> > > > relationship could be one of a subset of types, for example
> > > > "dependsOn", "potentialCollaborator", "collaborator".
> > > >
> > > > What should our schema look like for this?
>
> ...
>
> > There are essentially two options here:
> >
> > 1) we go for a generic unidirectional "dependency relationship"
> >
> > 2) we enumerate a set of unidirectional relationships.
> >
> > (1) has the problem that it's vague and doesn't do everything we want
>
> And so is not appropriate.

Maybe. It's certainly not appropriate by itself.

> > (2) would almost certainly require us to create and maintain our own
> > namespace, We'd have to describe in detail the relationships and debug
> > those descriptions. If we make the descriptions reusable, we run into
> > problems in that we start to recreate a build dependency system. If we
> > make the descriptions overly specific to simal we preclude reuse and
> > run into problems if simal evolves.
>
> Can you expand on "we start to recreate a build dependency system".
> I'm not really following this. If someone consumes our RDF and is
> unable to parse the extension we create they simply ignore them don't
> they?

The point I was trying to make (not very successfully, perhaps), was
that enumerating a subset of an effectively infinite set is a slippery
slope.

> I agree with you observation about "overly specific to simal".
> However, I think the kinds of relationships we wish to maintain are
> fairly standard, so that shouldn't be a problem.

I think we need to work from specific examples here. Looking at a
specific example we can say "there's another way to represent this" or
"no there's not." I'm pretty confident on the "dependsOn", but
"potentialCollaborator" and "collaborator" are still a little
uncertain for me.

The best (most obvious to the widest range of people) example I can
think of for dependsOn is the example of the linux kernel and gcc.
Linux is dependsOn gcc rather than the C language standard because it
only reliably compiles with the compiler and uses a few details of the
compiler that are out of scope of the standard. The relationship is
transitive, because something that dependsOn the kernel most also
depend on gcc. The relationship is unidirectional, because gcc does
not dependsOn kernel.

In the context of JISC projects, a demonstrator project dependsOn the
software it is demonstrating.

For collaborators, I'm thinking of projects like KDE and Gnome, who're
taking different approaches to do the same thing. Despite maintaining
their own identities, they're working to promote interoperability
through things like freedesktop.org.

For potentialCollaborators, I'm really not sure about, but I'm
guessing that these are what we're trying to infer...

> > (1) has been already been done for
> > personal relationships and can be found at:
> > http://vocab.org/relationship/
>
> Now I'm confused. That vocab looks more like an implementation of (2)
> to me. It enumerates all possible dependency types. Was that a typo or
> am I missing something.

You are correct, for (1) substitute (2).

cheers
stuart