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: Re: [oslc-core] Re: Blank nodes & deprecation of LocalResource. Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources


Hi Jim,

There's the potential confusion about the meaning "inline" versus "in graph".

From an OSLC point of view, I think we need to distinguish between a resource that is described in the same graph versus another graph that the client has to GET. For the latter, a client must support doing a subsequent GET for that referenced resource. For the former, clients should be able to accept blank nodes, or URIs of any value (whether they contain a hash fragment based on a common URI root, or uses a different URI altogether. From that aspect, I don't find the term "inline" particularly helpful from a client aspect. Turtle can express in-graph references for both blank nodes and URIs.

Best regards,
David




From:        "Jim Amsden" <jamsden@us.ibm.com>
To:        Martin P Pain/UK/IBM@IBMGB
Cc:        OASIS <oslc-core@lists.oasis-open.org>
Date:        2015-09-28 17:16
Subject:        [oslc-core] Re: Blank nodes & deprecation of LocalResource. Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
Sent by:        <oslc-core@lists.oasis-open.org>




Martin,
You are correct re: RDF abstract syntax and blank nodes - I realized that right after pressing send. I was thinking more about common use than RDF abstract syntax rules.


As far as I can see, you are correct, Turtle doesn't support inlined resources except for blank nodes:
[12] object ::= iri| BlankNode| collection| blankNodePropertyList| literal



What are the implications for OSLC? I suppose a resource that has a URI could still be included inline in Turtle using a blank node if instructed to do so by a particular resource shape. The client wouldn't know what that URI is, which is at odds with HATEOAS, but would work. However is this semantically correct? Is a blank node in some resource representation required to be a blank node in the RDF repository - i.e., do blank nodes need to be consistent between the persistent data and any representation of that data?


If so, then it appears that Turtle couldn't support inlined resources. That would seem to be a problem.


If we removed oslc:LocalResource, then there would be no way of ensuring the resources are inline in Turtle? And the resource couldn't be local in one representation and a referencable URI in another?




Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575





From:        
Martin P Pain <martinpain@uk.ibm.com>
To:        
Jim Amsden/Raleigh/IBM@IBMUS
Cc:        
OASIS <oslc-core@lists.oasis-open.org>
Date:        
09/28/2015 10:19 AM
Subject:        
Blank nodes & deprecation of LocalResource. Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources




Blank nodes are part of the "RDF abstract syntax" (mathematical/conceptual structure), not just RDF/XML. (Even if that distinction was made retrospectively, I don't know).
However, "Blank node identifiers" are just part of RDF/XML (and are only local to a representation, or store) - as the abstract concept of blank nodes is precisely that they have no identifier.

This is the definition of blank nodes in the abstract syntax, and it is followed by a note referring to "blank node identifiers":
http://www.w3.org/TR/rdf11-concepts/#section-blank-nodes(although the link from that note to the definition of "concrete RDF syntaxes" conveniently doesn't mention RDF/XML... which is only mentioned once in the entire spec).

But I agree that they tend to be used as a syntactical mechanism in the concrete syntaxes, rather than used for their "existential statement" intentions. Therefore I agree we should discourage them. It's a shame Turtle doesn't seem to be able to nest a resource without making it a blank node (please correct me if I'm wrong).


So... does that mean we don't want to encourage shapes to use oslc:LocalResource, as it requires resources to be blank nodes? So we could deprecate that in favour of oslc:AnyResource with a oslc:representation of oslc:Inline. And therefore the suggestion that we remove LocalResource from the shapes in the spec could still stand.


Arthur, Nick & Jim, any thoughts on whether we should make either of those changes?

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel


E-mail:martinpain@uk.ibm.com
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 
IBM





IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU




From:        
"Jim Amsden" <jamsden@us.ibm.com>
To:        
OASIS <oslc-core@lists.oasis-open.org>
Date:        
25/09/2015 19:25
Subject:        
Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
Sent by:        
<oslc-core@lists.oasis-open.org>




I agree with Arthur on the use of blank nodes. But I think blank nodes have nothing to do with RDF or its meaning - rather they are syntactical mechanism to deal with URIs in an RDF/XML resource representation for which the creator is either not interested in, does not know, or doesn't care about assigning a unique URI to an object. That flies in the face of web best practices.  


Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575





From:        
Arthur Ryman <arthur.ryman@gmail.com>
To:        
Martin P Pain <martinpain@uk.ibm.com>
Cc:        
Jim Amsden/Raleigh/IBM@IBMUS, OASIS <oslc-core@lists.oasis-open.org>
Date:        
09/25/2015 12:09 PM
Subject:        
Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
Sent by:        
<oslc-core@lists.oasis-open.org>




Martin,

My responses are inlined below:
Agreed. Agreed, for two reasons.:

1) rdfs:range defines an inference rule which lets you infer a type triple when the given property used as the predicate of a triple. In contrast Shapes define constraints, so oslc:valueType defines a check on the value of any RDF node that is the object of a triple whose predicate is the given property. This distinction between inference rules and constraints is the source of a lot of confusion in developers coming from an OO background, which is basically all of us. The W3C chartered the Data Shapes WG to define what most developers wanted, namely a way to describe and check constraints in RDF data.

2) The effect that developers want from rdfs:range can be achieved by using oslc:valueType with a value of oslc:Resource, oslc:LocalResource, or oslc:AnyResource and oslc:range, i.e. if the value of a property is non-literal then you can provide information about the value's rdf:type using oslc:range.

oslc:valueType is primarily used to constrain the syntactic type of an RDF node, i.e. IRI, blank node, or literal. In the case of literal, we decided to be prescriptive and restrict the choice to a small number of XSD types, which are enumerated in the spec.
I do disagree based on the way people use RDF in practice, i.e. as not being very strongly typed. Multiple values for oslc:valueType are primarily useful for literal types. The meaning of having multiple values is that the node must match at least one of them. RDF is intrinsically permissive. So this boils down to a policy decision for OSLC, i.e. to impose strong typing or not. The tradeoff is ease-of-implementation (with one type) versus flexibility. Perhaps this could be handled with a SHOULD requirement, i.e. state that properties SHOULD use just one type of RDF node.
Personally, I think OSLC should actively discourage the use of blank nodes, because they are not used correctly. In RDF, the meaning of a blank node is as a placeholder when the IRI of a resource is not known. The interpretation of triples is in terms of existentially statements, e.g. Somebody likes Martin. However, developers use blank nodes when they want the RDF to be compact or they don't realize that they could use hash IRIs to identify parts of a resource.

When you POST a resource, the server in effect copies it into a new resource. The server is free to coin new IRIs, including fragment IRIs. This behaviour should be described in the API spec for the POST service.

Yes, there can be different Shapes for POST vs GET. The Creation Factory should link to a shape used for POST. The Query Capability or the resource itself should like to its GET shape.

-- Arthur


I withdraw my suggestion from that email to deprecate oslc:Resource and oslc:LocalResource. However I'd like to see examples (which hopefully already exist) of when requiring or prohibiting blank nodes is useful, so we can be confident of what should be in the shapes in the spec.

Thanks,
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel


E-mail:martinpain@uk.ibm.com
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 
IBM







IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU




From:        
Arthur Ryman <arthur.ryman@gmail.com>
To:        
Jim Amsden <jamsden@us.ibm.com>
Cc:        
OASIS <oslc-core@lists.oasis-open.org>
Date:        
24/09/2015 23:14
Subject:        
Re: [oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
Sent by:        
<oslc-core@lists.oasis-open.org>




Jim,

Still catching up after vacation. Your comments contain some misinterpretations. I've replied in other several places. Is this still an issue. fyi, I tried to clarify the meaning of these vocabulary terms in the W3C submission. Please refer to
http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueType.

-- Arthur

On Wed, Sep 2, 2015 at 5:12 PM, Jim Amsden <
jamsden@us.ibm.com> wrote:
I'm trying to understand the point of ResourceShape  valueType and representation properties.

oslc:valueType description is: "A URI that indicates the value type, for example XML Schema or RDF URIs for literal value types, and OSLC-specified for others.  If this property is omitted, then the value type is unconstrained."  That is defining the type of the property, not its representation in a resource, and covers what would be captured in the RDFS/OWL range property of the property.

The description for property oslc:representation is "Should be
http://open-services.net/ns/core#Reference, http://open-services.net/ns/core#Inlineor http://open-services.net/ns/core#Either". This is addressing whether the representation of the referenced object must or may be in the same resource representation as the subject of that property. This is probably included in order to limit the number of GETs required to do discovery. Its a resource representation optimization that has no semantic meaning.

Later on in the ResourceShape vocabulary, there is a comment: "<!-- ********** Property: oslc:valueType allowed values ********** -->" which is followed by the enumeration types for Resource, LocalResource and AnyResource. This seems completely orthogonal to the definition of oslc:valueType and its common use to specify expected type of the value of a property, and appears to overlap with the values for oslc:representation.

In particular, oslc:valueType of LocalResource could only have oslc:representation oslc:Inline, and all instances of oslc:representation Inline in the OSLC2 specification have oslc:valueType LocalResource.

What seems to have happened is that oslc:valueType got somewhat overloaded. If the valueType is a resource, then it can have a representation. No other value type can have a representation. A resource shape might specify multiple valueTypes for a property, one that is the property's type (i.e., the object of its range property), the other is a tag indicating how the property value (that is a resource) should be represented in an HTTP resource - inlined (blank node or relative URI) or as a (potentially) external GETtable resource in its own right.

But this overlaps with oslc:representation which says the same thing. So I think valueTypes of Resource, LocalResource or AnyResource are redundant and unnecessary (but can't be removed). The value of a property should simply have a  type, and if its type is a non-primitive resource, then that value should have a representation that MUST or MAY be in the same resource as the subject URI.

Given the description above, we should be able to decouple resources from their particular representation. That is, a ServiceProvider resource representation would expect its Service instances to be inlined in that representation. But this shouldn't mean the Service can't be an LDPC in its own right, and certainly a GET on a Service URI would return a resource representation in which the Service is inlined!.

So I don't think there's a problem here. We should:

1. deprecate the use of oslc:Resource, LocalResource and AnyResource since they are redundant with oslc:representation. Any value of oslc:representation applies to any resource, so that doesn't need to be stated. oslc:representation for a LocalResource has to be Inline. Clients can't make any assumptions about the representation for AnyResource. So again, all values of oslc:representation apply.

2. add oslc:representation back into the OSLC3 specifications (it was removed and doesn't appear in any of the shape .ttl files or generated tables)

3. Treat oslc:representation as a means of specifying what should be included in resource representations that reference properties, but does not constrain where servers actually manage those resources. That is, the value of a property with oslc:representation oslc:Inline could be a blank node, relative (or hash) URI, or a URI to a resource that that can also be the URI of a GET request, even though it would be accessed inline in any other referencing resource representation.

As a result, get on a ServiceProvider would include the publisher and services inline, but each Service could also be the URI of an LDPC in an OPTIONS, HEAD, or GET method that provides Link headers for discovery.







Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575




From:        
Martin P Pain <martinpain@uk.ibm.com>
To:        
OASIS <oslc-core@lists.oasis-open.org>
Date:        
09/02/2015 10:14 AM
Subject:        
[oslc-core] Dialog discovery: triple and Link header for discovery of dialogs won't be on same resources
Sent by:        
<oslc-core@lists.oasis-open.org>




We have three mechanisms of discovering dialogs:

Link headers & Prefer headers:
http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/jra-editing/specs/dialogs.html#discovery_link
and oslc:selectionDialog/oslc:creationDislog triples in oslc:Service resources:
http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/jra-editing/specs/discovery.html#dialogs

I had previously expected that these headers and these triples would be on the same resources, but they cannot be.


The triples are on oslc:Service resources, but
OSLC v2 requires that these resources be "Local Resources", which it defines to mean blank nodes (although I need to raise a separate issue to clarify whether the intention was to allow for hash URIs or not). "Local Resources" cannot have headers of their own, so oslc:Service resources cannot have Link header. (If they have hash URIs, technically they can have their own Link headers, but I don't suggest we go down that route.)

The Link and Prefer headers will be on LDPs themselves. (Although currently I don't think we have a good way of finding those LDPCs).

Is everyone else ok with the fact that these headers and triples will be on different resources?
I just wanted to make sure we're clear what the situation is and are ok with it.


(This might make more sense in the context of my previous email and the wiki page it links to, where I'm thinking about how a server with one or more LDP containers makes those containers and their capabilities discoverable using OSLC).
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel


E-mail:martinpain@uk.ibm.com
Find me on:
LinkedIn: http://www.linkedin.com/profile/view?id=99869908 and within IBM on: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891 
IBM









IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

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




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





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




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


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