Holger, the issue raised by Richard which starts the thread (and which
we'll presumably vote on) does say "same graph." Are you saying that he
misspoke? As for same dataset, I'm not sure what that means in RDF.
kc
On 4/14/15 12:07 PM, Holger Knublauch wrote:
> 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:
>> 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]
>> <mailto:[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]
>> <mailto:[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] <mailto:[log in to unmask]> http://kcoyle.net
>> m: 1-510-435-8234 <tel:1-510-435-8234>
>> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-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 <tel:212.998.2479>
>> [log in to unmask] <mailto:[log in to unmask]>
>>
>>
>>
>>
>> --
>> -Tom Johnson
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|