[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=60496#comment-60496 ] 

James Amsden commented on OSLCCORE-18:
--------------------------------------

I don't have any problem with servers creating efficient resource representations. What concerns me is when we standardize on a particular resource representation because we think its the best for a specific purpose, and it turns out to be less ideal for future usages we didn't anticipate. 

Servers should be free to send any representation of a resource they want, inlined or not, as long is it is a valid RDF representation. Clients should not depend on any particular representation (using XML DOM or XPath instead of RDF to parse the resources). This keeps things open and decoupled. 

Efficient representations for a particular use sounds like something that goes in implementation and usage guidance, not a standard. So I think oslc:representation might be a good thing to continue to avoid.

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