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

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

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

Martin Pain commented on OSLCCORE-35:
-------------------------------------

1. Is the word "relative" in your description of LocalResource is taken from the second paragraph of section 2.14 of http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-ID-xml-base? (Where it says "The rdf:ID attribute on a node element ... can be used instead of rdf:about and gives a relative RDF URI reference equivalent to # concatenated with the rdf:ID attribute value".) If so, then I don't think you've captured the meaning of that sentence in your description. Are you treating that sentence as meaning "rdf:ID ... gives a relative RDF URI reference. What that means is that it is equivalent to # concatenated with the rdf:ID attribute value"? I interpret it as saying  "rdf:ID ... gives an RDF URI reference that is equivalent to # concatenated with the rdf:ID attribute value, which is then interpreted relative to the base URI of the context." That is, I interpret it not as defining what a "relative URI" is, but rather it is building a URI by concatenation then resolving the result as a relative URI. Therefore there are other types of relative URIs that cannot be achieved with rdf:ID.

Therefore I still suggest that using the term "relative URI" in the LocalResource description does not accurately refer to the use of rdf:ID.

A better description (although unfortunately longer) might be something like "The value is a resource available only inside the resource being defined. i.e. a Blank Node or a URI with a fragment identifier for a resource in the current document."

2. This might be splitting hairs, but I also think that allowing it to be hash URI relative to an xml:base specified within the document is not in the spirit of what is intended here. My interpretation is that if you take the URI for this LocalResource and perform a GET on it, then you should be requesting exactly the same document as the one in which you found the URI for that LocalResource - at exactly the same URI. That is, the URI for the LocalResource should be a relative URI specifying a fragment identifier on the current request URI/within the current document. (xml:base can be specified on any element, so it might not just be setting the base URI for the document as a whole).

So, to iterate on my suggested description:  "The value is an RDF resource available only inside the HTTP resource being defined. i.e. a Blank Node or a URI with a fragment identifier appended to (or resolved relative to) the current request URI."
We could remove the bit in brackets in that suggestion if the added length reduces clarity rather than adding  clarity - those words don't add anything to the meaning.

> 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 os 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
(v6.2.2#6258)