[oslc-core] Comments on OSLC Links Guidance Draft

[Dave]

Hi Ian,

Thanks for your comments and sorry for the delayed response.

My responses are inline below...


On Mon, Mar 8, 2010 at 9:23 AM, Ian Green1 <ian.green at uk.ibm.com> wrote:
> I'd like to understand the objectives & scope of the OSLC Core Guidance on
> linking.  I'm aware of pressure from my own workgroup (RM) that we need
> answers to some basic questions, and wonder if OSLC Core might be able to
> give an indication as to how far we might get in 2.0/2.1?
>
> Here are some basic questions:
>        - what relationships do we want to bake into OSLC?  A set of
> relationships that have a broadly understood meaning that can support
> integration scenarios.  For example, what does "implementedBy" mean?  The
> RM team made a start on this last year: see [3].  Currently, OSLC does not
> define any such types and so interoperation around links can only work
> outside of current specs.

My feeling is that specifying and/or cataloging the different
link-types used in resource of one service to resource of another
service is something that is critical to ALM, integrations and
traceability but not something that we are ready to bake into the OSLC
Core Spec. I've got a couple of questions of my own on this topic:

- Could the work that the RM team has done so far become the basis for
OSLC Core WG guidance on link-types?

- Could the different types of links that are available be found by
examining the Resource Shapes supported by various services involved
in an ALM scenario?


> - How does a consumer discover links?  Is this for all links, or
> only those "known" to a certain authority?

Query is the way to discover links and currently, we don't have a
cross-service query as part of OSLC.


> - Does OSLC say anything about links to resources that do not
> support OSLC-defined protocols?

OSLC tries to avoid specifying a protocol and simply relies on HTTP
and the normal rules of the web. OSLC services can manage resources
that are not "defined" by OSLC specs, e.g. opaque files file JARs or
presentation files.


>        - How to ensure that the OSLC protocols can be implemented in a
> robust manner.  For example, so that referential integrity can be
> maintained.

This seems out of scope for the OSLC Core Spec but not out of scope
for OSLC Service specifications. Some specifications might have
special requirements for what happens when related resources managed
by the resources are deleted or how changes are "cascaded."


> Do we know which of these issues are in scope for 2.0 guidance?

I think Link Types might be something we should consider for guidance
very soon. We don't want individual OSLC specifications or
implementations defining their own link-types.


> I've got some more detailled comments on the current draft:
>
> Quite a bit of discussion has been had in the past on link resources, as
> described at [1].  One concern with this style is that there is "step
> change" in complexity - from "simple" to "complex" link.
>
> I see "link" as a low-level building block.  Really, we are interested in
> something bigger - "relationship" might be the word for that.  A link (a
> URI-valued property) is unidirectional and we know that this does not meet
> even our most basic integration scenarios.  For example, we need
> navigability and discovery in both directions.  The C/ALM 2009 practice of
> making two links, one in each direction is known to be unsatisfactory:
>        - referential integrity
>        - needs two elements in the volcabulary ("implementedBy" and
> "implements") (worse for n-ary relations)
>        - unclear ownership

Let me make sure I understand what you are saying. We have simple and
complex links with, someday soon, some catalog of link-types. But, to
enable referential integrity we also need a Relationship Resource that
is conceptually similar to a relationship table in the RDBMS world?

I don't think we are ready to specify how referential integrity can be
ensured across OSLC services yet, but is there something we can do now
to support it? Or, at least not prevent it?


> I'm afraid that I don't understand the example of a complex link (the RDF
> is not well-formed).   Is the intention that the Podcast resource
> describes the relationship between the Entry and the uploaded podcast (the
> thing at .../uploads/962357642)?
>
> This could be made to valid RDF as follows:
>
> <oslc_blog:podcastLink>
>   <rdf:Description rdf:about=”http://example.com/uploads/962357642”>
>         <rdf:type>http://open-services.net/xmlns/example#Podcast
> </rdf:type>
>         <dc:title>Podcast: JUnit versus TestNG for Java unit
> testing</dc:title>
>         <oslc:contentType>auddio/mpeg</oslc:contentType>
>      </rdf:Description>
>   </oslc_blog:PodcastLink>
>
> Interpreting this as "link properties" is not what I understand by link
> properties - what we have here is a link to some uploaded data, and some
> assertions about that uploaded data.  Is that what is intended?  Link
> properties are properties of the relationship, not of the things that are
> related.

Yes, that is what is intended. The blog entry links to the podcast
media and the link has some properties that describe the podcast media
resource. How would you represent this?

I believe that example needs to be updated to line-up with the RDF/XML
rules in the Core Spec, which have changed.


> A link property MUST have a resource that one can assert to have some
> property - this means that the link MUST be an RDF resource - it has to
> have a URI.    I've seen two ways of doing this:
>
>        - make the link into a resource (a la the first drafts of the AM
> and RM specs.  This was not met with universal acceptance and was
> retracted, subject to debate.)  Something like:
>                <oslc:Link>
>                        <rdf:subject/>
>                        <rdf:predicate/>
>                        <rdf:object/>
>                        <rdf:type type of the link/>
>                        other properties here
>                </>
>
>        - address the triple by "presenting" it (those are my words - see
> Martin's blog on this [2]).  This is the SPARQL Update approach.

I think the objection to this was that links should not be promoted to
the level of resources. If you need to make a link into a resource
(for two-way linking, referential integrity or whatever) then you
really have a new resource type, a  "relationship" or something that
is perhaps OSLC domain specific.

Thanks,
- Dave