Re: shapes-ISSUE-18 (S35 examples): S35 needs to state what constraints are required

I have some problems with the informal specification in this added material.



 > Let X be  the URI of an access control list information resource.

Information resources can in general be accessed by multiple URIs.  What 
happens then?

 > Its RDF graph must contain X as a resource node.

"Resource node" is not a term defined by RDF.  I think that just "node" is fine.

 > X must have type acc:AccessContextList.

I assume here that you mean that X must be linked to acc:AccessContextList by 
an rdf:type triple.

 > X must have a string-valued dcterms:title property and a string-valued
dcterms:description property.

I assume that you mean "... value for ..." instead.

 > In addition, the graph may contain zero or
more other resource nodes (URIs) of type acc:AccessContext.

As above.

 > Each of these other nodes must have a string-valued dcterms:title property 
and a string-valued dcterms:description property.

As above.

 > The graph may contain other triples."



You seem to be implying that the working group should define an API that takes 
a URI and then somehow coerces this to an RDF graph.  This may or may not be a 
good idea, but it has nothing to do with disconnected graphs.  If you think 
that this should be a requirement then I suggest changing the title of S35.

You also seem to be implying that the working group should define a mechanism 
that somehow gives the constraints access to the URI that was used to access 
the RDF graph.   This may or may not be a good idea, but it has nothing to do 
with disconnected graphs.  If you think that this should be a requirement then 
I suggest changing the title of S35.


The last bits of this requirement can be easily done in SPIN and OWL 
constraints.  The OWL constraints would probably be

SubClassOf(acc:AccessContext ObjectExactCardinality(dcterms:title xsd:string))
SubClassOf(acc:AccessContext ObjectExactCardinality(dcterms:description 
xsd:string))

This constraints work whether or not there is a connection from X to the 
acc:AccessContext nodes.


I am now even more puzzled about the intent of S35.



peter



On 01/08/2015 01:08 PM, Arthur Ryman wrote:
> I added the following text to the wiki:
>
> Some of the proposed solutions (Resource Shapes, ShEx, SPIN) appear to
> have an implicit assumption that the only RDF graphs of interest to this
> workgroup are like programming language data structures in the sense that
> there is a distinguished root node which is the subject of triples that
> define either literal properties or links to other subjects, which may in
> turn have literal properties or links to further subjects, or so forth.
> The implication is that all the nodes of interest are connected to the
> root node. Therefore, these proposals are incapable of describing
> disconnected graphs. The point of this user story is to provide evidence
> that disconnected graphs are of interest. It also attempts to make the
> point that the output of this workgroup should be applicable to general
> RDF graphs and not just some subset of graphs that follows some popular
> design pattern.
> The example is taken from a specification related to access control. A
> conformant access control service must host an access control list
> resource that supports HTTP GET requests. The response to an HTTP GET
> request have a response body whose content type is application/ld+json,
> i.e. JSON-LD. An example is given below. In this example, there is a
> distinguished root node, i.e. the node of type acc:AccessContextList, but
> it is not connected to the other nodes of interest, i.e. the nodes of type
> acc:AccessContext.
> An informal specification for valid RDF graphs is as follows: "Let X be
> the URI of an access control list information resource. Its RDF graph must
> must contain X as a resource node. X must have type acc:AccessContextList.
> X must have a string-valued dcterms:title property and a string-valued
> dcterms:description property. In addition, the graph may contain zero or
> more other resource nodes (URIs) of type acc:AccessContext. Each of these
> other nodes must have a string-valued dcterms:title property and a
> string-valued dcterms:description property. The graph may contain other
> triples."
> This user story does not propose that a shape language must be able to
> distinguish between connected and disconnected graphs.
> _________________________________________________________
> Arthur Ryman, PhD
> Distinguished Engineer | Master Inventor | Academy of Technology
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
>
>
> "RDF Data Shapes Working Group Issue Tracker" <sysbot+tracker@w3.org>
> wrote on 12/18/2014 11:01:08 PM:
>
>> From: "RDF Data Shapes Working Group Issue Tracker"
> <sysbot+tracker@w3.org>
>> To: public-data-shapes-wg@w3.org
>> Date: 12/18/2014 11:01 PM
>> Subject: shapes-ISSUE-18 (S35 examples): S35 needs to state what
>> constraints are required
>>
>> shapes-ISSUE-18 (S35 examples): S35 needs to state what constraints
>> are required
>>
>> http://www.w3.org/2014/data-shapes/track/issues/18
>>
>> Raised by: Peter Patel-Schneider
>> On product:
>>
>> S35 https://www.w3.org/2014/data-shapes/wiki/
>> User_Stories#S35:_Describe_disconnected_graphs talks about
>> constraints over disconnected graphs.  However, it does not state
>> why disconnected graphs are different from connected graphs?  Are
>> the constraints supposed to recognize disconnected graphs?  Or are
>> the constraints just supposed to work on disconnected graphs, and
>> what differences in constraint handling are required for disconnected
> graphs.
>>
>> SPIN and OWL constraints don't care whether a graph is connected or
>> disconnected.
>>
>>
>>
>
>

Received on Friday, 9 January 2015 01:11:30 UTC