Print

Print
To clarify, the WG is not discussing the "in the same graph" option. It is all about whether shapes and data graphs are in the same *Dataset*, so that they can query each other at runtime. Scenarios like union graphs are definitely important and the operations would receive named graphs are arguments.

Holger


On 4/15/15 3:42 AM, Tom Johnson wrote:
[log in to unmask]" type="cite">
My take is very similar to Corey's.

I would add that I'm not entirely sure I understand what is meant by "in the same Graph".  Surely one of the key advantages of using RDF is the ease with which graphs are merged?  I would certainly want Shapes tools to be able to work with arbitrary graph unions--not just so I can apply different Shapes to the same RDF Source, but so i can validate data pulled from multiple Sources against a set of constraints.  

Genreally, my assumption is that a Shapes tool would want to construct one or more (temporary) Graphs of the triples relevant to a given operation.  The language and interfaces should be flexible about how to specify which triples are included.

- Tom

On Tue, Apr 14, 2015 at 10:07 AM, Corey A Harper <[log in to unmask]> wrote:
Hi Karen, et al.,

I definitely share your concerns. I imagine a lot of use cases that I'll have where I'm processing RDF Sources in almost a stream-reader format -- they won't all be part of a graph, let alone sharing a graph with the shapes I want to validate against. 

I see the point about relying "on being able to access triples from the shape graph when validating the data graph" (from the link in your original mesage).  

I would think that connecting data to shape could just as easily be a function of referring to the shape in the same way a JSON-LD doc refers to its context, or even just having a parse / validate routine in an application that takes both instance data and a constraining shape as arguments.

Thanks for trying to keep our interests represented in the W3C work!

-Corey



On Tue, Apr 14, 2015 at 10:51 AM, Karen Coyle <[log in to unmask]> wrote:
All,

There is a thread on the W3C Shapes list that I think is of interest, but that I need some help with. It starts here:

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0509.html

The question is: Should the constraint language (shapes) and the instance data be in the same graph? The discussion goes in various directions, but what I want to hear from those of you who have workflows in place is whether you could agree to a requirement that they must be in the same graph.

If I'm understanding the discussion it seems that a separation of constraints and instance data will be possible, but there seem to be advantages to having them in the same graph. My concern is that the "in the same graph" solution works well for well-contained enterprise data but will be less suitable to the kind of aggregation use case that we encounter in cultural heritage work.

Thanks,
kc

--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600



--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
[log in to unmask]



--
-Tom Johnson