[OASIS Issue Tracker] (OSLCCORE-18) link-guidance.html final editing issues

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59642#comment-59642 ] 

Martin Pain  commented on OSLCCORE-18:
--------------------------------------

Reading through the latest versin of the document from jra-editing, and these are my comments:

A. §2.1 Link: "when... you don't want to inline any summary of the target". My understanding is that anchors shoudn't be used to inline values of the target. RDF already allows you to do that, by including another triple whose subject is the target (that is, object) of this link (triple). Anchors should only be used to describe the relationship itself.

B. §2.1 Link: "In OSLC, you express a link as a property with OSLC value-type of Resource and OSLC representation of Reference. For example..." I know this is referring to the values that we used (at least in v2) in the resource tables. Are we still using them in v3? Are they also the terms used in resource shapes? We ought to be more clear about why this information is useful to the reader. I'm not sure it is. And the following example doesn't relate to this sentence at all, but to links in general. Simplest fix: remove this sentence. Alternatively, start the sentence with "In OSLC resource tables, a link is expressed as...", and move it after the example.

C. § "Don't make assumptions about the target of links". Should this be §2.1.1? Also "Store link information in one place" §2.1.2?

D. § "Store link information in one place". This is a little ambiguous as there are (or could be) two issues in play here:
1: Reverse links
2: Duplicated triples.
Reverse links have very much been identified as an anti-pattern. That is, A ex:affects B and B ex:isAffectedBy A. The "isAffectedBy" predicate should not exist (and therefore not be used). (Or at least only one of them should exist, sometimes a "...By" link might be correct to be the only direction that exists).
Duplicated triples have the same problem as any redundancy, and should be avoided when not needed, but in my mind are the right way to go when you need redundancy. e.g. a request to A might return "A ex:affects B", and a request to B might return "A ex:affects B". If they are on different servers then B's representation might get out of date, but the client should be able to tell that this is from a non-definitive source as the subject's URI has a different host/port than the request URI.
The word "storing" suggests the latter to me - which resource is it returned from (presuming a resource-based storage mechanism such as a document database), but the test appears to talk only about which is the subject of the triple. We should probably address both, strongly speaking against inverse properties, and suggesting that any redundancy of triples is treated with care.

E. Anchor section looks good to me (after your edits).

F. §3: "When you link to a target resource that has a dcterms:title value and you inline that dcterms:title in the subject resource, in the RDF data model this means that you have just given the object resource two titles." Is this really true? My understanding is that if two triples match exactly then they are the same triple. I can't cite a source for that off the top of my head, but neither does this document cite a source. I presume (like with most of my comments here) it's something we've inherited from v2.
In RDF terms I see no difference between example 6 and example 7 - I expect them to result in exactly the same triples. (Indeed when we move this to Turtle, I think there will be no difference between those two examples).
As already stated, we should suggest care when introducing redundancy, but sometimes it is needed, and it should be done in the correct RDF way, and to me the anti-pattern is duplicating that information in different triples, i.e. in triples on an anchor.

G. I didn't see anything in the latest version about point 4 in this ticket's description.

> link-guidance.html final editing issues
> ---------------------------------------
>
>                 Key: OSLCCORE-18
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-18
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: James Amsden
>            Assignee: James Amsden
>            Priority: Minor
>
> 1. Anchor: a link plus information that annotates or labels that link for use when a relationship must be annotated with property-values.
> Anchors are done through reification using an ref:Statement with subject, predicate and object and rdf:ID for the assertion being annotated, and any additional properties required. 
> Additional guidance should discuss that properties on links possibly indicate missing classes in the vocabulary and associative objects could be used to model the link properties more directly.
> 2. Examples should be in Turtle and, there is no OSLC Core JSON format (Turtle only)
> 3. Anti-pattern in section 3 referes to OSLC query syntax which isn’t supported
> 4. Include guidance on storing the link information in one place and utilizing queries to traverse the link in both directions. i.e., no inverse properties or bi-directional links.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)