[oslc-core] Comments on OSLC Links Guidance Draft

[Ian Green1]

Hello OSLC Core team
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.

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

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

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

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

thanks
        -ian
----

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


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.



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.


[1] http://open-services.net/bin/view/Main/OSLCCoreLinksDRAFT
[2] Apologies, this is an IBM-only page.  
http://w3.ibm.com/connections/blogs/03a1f6ee-f8ec-43a2-acd8-09001ad0ebb5/entry/partial_update_fatal_flaw_and_recovery?lang=en
[3] http://open-services.net/bin/view/Main/RmDiscussionLinkTypes


best wishes,
    -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU