OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (OSLCCORE-35) v2 Resource Shape vocab: oslc:Inline incorreclty mentions blank nodes

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

Arthur Ryman commented on OSLCCORE-35:

Guys, some history. When these terms were coined the prevailing wisdom was that we should not expose users to RDF terminology, like blank node. So oslc:LocalResource was a euphemism for blank node. Similarly, oslc:Resource was a euphemism for IRI. oslc:AnyResource is either IRI or blank node. In RDF, IRI are opaque identifiers so you really should not talk about fragments since it's not meaningful from an RDF viewpoint. The three types of RDF node are simply IRI, blank node, and literal.

In practice, many designers started using blank nodes when they should have used IRI composed by appending a suitable fragment to the base IRI of the resource. Blank nodes in RDF are used for existential statements. In OSLC resources, it's much better to avoid blank nodes since then those nodes can be referenced from outside the resource.

The purpose of oslc:representation was to distinguish between links to external resources versus parts of the current research. e.g. if a change request linked to a test case, you would not expect that the test case be present in the change request graph. However, if a table linked to a row then you'd expect the row to be in the same graph as the table.

I recommend that you use the W3C Member Submission which cleans up the original OSLC Appendix where Resource Shapes was first published. See http://www.w3.org/Submission/2014/SUBM-shapes-20140211/

> v2 Resource Shape vocab: oslc:Inline incorreclty mentions blank nodes
> ---------------------------------------------------------------------
>                 Key: OSLCCORE-35
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-35
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Martin Pain
>            Assignee: James Amsden
> In the v2 vocabulary (we don't version the vocabulary, so we're not removing anything), the oslc:Inline resource (used as a value for an oslc:representation property) says:
> "An inline (RDF blank node) representation."
> I believe this is wrong, as oslc:Inline is used with oslc:Resource, which says "Resource: value is a resource at a specified URI (i.e. a URI Reference)." A value cannot be both a URI Reference and a blank node.
> The member submission of Resource Shapes to the W3C describes oslc:Inline differently, and I believe that this description correctly matches the intention: http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#representation "oslc:Inline: The representation of the object resource MUST be present in the representation of the described resource."
> I suggest we change the description of oslc:Inline in the vocab to match the one from the member submission.
> This issue would probably be more correctly addressed by the v2 "maintenance mode" working group at open-services.net, but as there has been no activity there for a long time, and as we are modifying the vocab for v3 as part of this TC's work, I'm raising it here.
> (The description of oslc:Resource [the alternative to oslc:Inline] in the v2 vocab file also makes no sense: "A URI Reference representation to a resource", but I'm also not sure about the one in the member submission either: "The representaton of the object resource MUST NOT be present in the representation of the described resource." - I interpreted it more as "the representation of the object resource MUST be available by performing a GET on the object URI, irrespective of whether it is also inlined in the subject's representation". The member submission's interpretation might be more appropriate when describing the allowed body of a POST, whereas mine might make more sense when describing what gets returned from a GET.)

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]