Re: associating RDF nodes with shapes

There is beginning to be a real uptake of JSON-LD by the folks who use 
JSON - folks who previously rejected RDF for their data. There is also a 
(regrettably, IMO) large contingent of RDF+XML users among those who 
normally use XML. I agree with Holger that whatever this group develops 
has to be usable by folks in their favorite serialization. These 
serializations have tools that are heavily used and already embedded in 
applications that will need to be extended to make use of RDF.

kc

On 12/16/14 6:52 PM, Holger Knublauch wrote:
> On 12/17/2014 11:53, Peter F. Patel-Schneider wrote:
>> I believe that it is very fortunate that this working group does not
>> have anything to do with JSON.
>
> Complete disagreement! Fortunately this WG does have a lot to do with
> JSON. The goal of this group is to create something that is
> user-friendly, and JSON is considered a user-friendly syntax for some of
> our largest target audiences. The models created with our language
> should be easy to edit and parse with JSON tools. We get most of the
> parsing for free due to JSON-LD, yet we should explicitly make it a goal
> to be kind to this audience. We should also create some or all of our
> examples in JSON-LD syntax, switchable between Turtle and JSON-LD.
>
> I sincerely hope this WG avoids the ivory tower mistakes done in
> previous failed attempts to create widely adopted semantic web
> languages. Accepting the state of the market and the preferences of
> mainstream developers is one key aspect in this endeavor. An alignment
> with object-oriented techniques will also help greatly with the learning
> curve and interoperability.
>
> Holger
>
>
>> I have followed the troubles involved in updating the JSON RFC, and I
>> fervently hope that this working group does not have the same problems.
>>
>> peter
>>
>>
>> On 12/16/2014 05:46 PM, Irene Polikoff wrote:
>>> OK, I now understand this better. I think it is fine to be
>>> comprehensive in describing all possibilities. I also think that at
>>> some point the group will need to start being ruthless in deciding
>>> what will be supported in the standard.
>>>
>>> Related to this, I was in a customer workshop yesterday where I
>>> briefly described the motivations and charter of this group. The
>>> reply was "this is quite interesting and needed" but also a very
>>> strong caution against trying to cover all the bases and "academic
>>> thinking" resulting in a standard that is too comprehensive, too
>>> difficult for users to understand, for vendors to implement and takes
>>> too long to develop.
>>>
>>> They said that instead they would really like something fairly light
>>> and pragmatic delivered soon with strong tool support. Lots of
>>> interest in JSON as it has pretty much replaced XML as a way to
>>> communicate between systems and a corresponding interest in the
>>> standard defined by the group being able to serve as a kind of "JSON
>>> Schema" language.
>>>
>>> Irene
>>>
>>> -----Original Message-----
>>> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
>>> Sent: Tuesday, December 16, 2014 8:19 PM
>>> To: Irene Polikoff; 'Holger Knublauch'; public-data-shapes-wg@w3.org
>>> Subject: Re: associating RDF nodes with shapes
>>>
>>> The example about bug reports is in 2b.  Nodes that have "Submitted"
>>> as a value for ex:status are evaluated against a particular shape.
>>>
>>> I don't think that we have seen explicit examples of 4 yet.  It would
>>> be used for constraints requiring a property to be transitive or
>>> symmetric, in the "The Model's Broken".
>>>
>>> peter
>>>
>>>
>>> On 12/16/2014 05:08 PM, Irene Polikoff wrote:
>>>> I have not seen examples of nor requirements for 2.b and 4 type of
>>>> scoping, but yes one could possibly scope based on these criteria.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
>>>> Sent: Tuesday, December 16, 2014 7:58 PM
>>>> To: Irene Polikoff; 'Holger Knublauch'; public-data-shapes-wg@w3.org
>>>> Subject: Re: associating RDF nodes with shapes
>>>>
>>>> Yes, at least roughly.
>>>>
>>>> Perhaps a better way of thinking about things is that there are four
>>>> main ways to determine the targets or a constraint.
>>>> 1/ All nodes (or maybe all IRIs) in the graph.
>>>> 2/ All nodes that meet a certain condition, usually either
>>>>       a/ belonging to a particular class or
>>>>       b/ having a (or a particular) value for a particular property.
>>>> 3/ A particular node.
>>>> 4/ All triples with a particular property as predicate.
>>>>
>>>> The structure of the association can be done in several ways:
>>>> 1/ There can be explicit links from individuals or classes or
>>>> properties to constraints, as in SPIN or OSLC Resource Shapes.
>>>> 2/ The association can be part of the constraint itself, as in OWL
>>>> Constraints (Stardog ICV).
>>>> 3/ The association can part of the validation process, as in ShEx.
>>>>
>>>> peter
>>>>
>>>> PS: There are no resources in an RDF graph.  The working group
>>>> should not be talking about running constraints on a resource.
>>>>
>>>>
>>>>
>>>> On 12/16/2014 04:37 PM, Irene Polikoff wrote:
>>>>> Ignoring the question "why" for a moment, I see this document as
>>>>> one that identifies ways to scope constraints and, thus, validation.
>>>>>
>>>>> >From that perspective, the page currently lists three scoping
>>>>> mechanisms:
>>>>>
>>>>> 1. based on the class memberships: as in "run these constraints for
>>>>> members of this class" - constraint is associated with a class 2.
>>>>> based on a specific resource: as in "run these constraints for this
>>>>> resource" - constraint is associated with a resource 3. based on the
>>>>> graph: as in "run these constraints for all triples in a graph" -
>>>>> constraint is associated with a graph
>>>>>
>>>>> There are variations on #3 discussing how exactly this may be
>>>>> specified ranging from a direct association of a graph with some
>>>>> constraints to more of a "late binding" approach where when the
>>>>> validation engine is called graphs and constraints are passed as
>>>>> parameters or validation engine is smart enough to run some logic
>>>>> to determine what it should use to validate what. These are all
>>>>> details, but the bottom line is that the scope is a graph or a
>>>>> group of graphs.
>>>>>
>>>>> "Constraints on the shape of a value" does not seem to fit at all.
>>>>> I think this doesn't belong here.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Holger Knublauch [mailto:holger@topquadrant.com]
>>>>> Sent: Tuesday, December 16, 2014 6:48 PM
>>>>> To: public-data-shapes-wg@w3.org
>>>>> Subject: Re: associating RDF nodes with shapes
>>>>>
>>>>> I am not sure how to proceed here. If you want, you could start a
>>>>> separate page where we try out your structure and we copy it over
>>>>> when we are done. Your draft below is omitting too many details and
>>>>> is very OWL centric to be a direct substitution. I also don't
>>>>> understand your example syntax, e.g. what does this mean:
>>>>>
>>>>> <code>some ex:property ex:value <= constraint</code>
>>>>>
>>>>> The bigger question is: why are we writing this document at all.
>>>>> Shouldn't our goal be to collect Requirements?
>>>>>
>>>>> Holger
>>>>>
>>>>>
>>>>> On 12/17/2014 4:43, Peter F. Patel-Schneider wrote:
>>>>>> I took a close look at the node/shape association page,
>>>>>> https://www.w3.org/2014/data-shapes/wiki/ISSUE-5:_Resource_Shape_Ass
>>>>>> oc
>>>>>> iation
>>>>>>
>>>>>> I would prefer an organization more like the following, as I think
>>>>>> that it presents a clearer picture.
>>>>>>
>>>>>>
>>>>>> Where are Shapes/Constraints Validated
>>>>>>
>>>>>> 1/ A particular node
>>>>>>
>>>>>> A shape/constraint may be validated only on a particular node in an
>>>>>> RDF graph.
>>>>>>
>>>>>> In ShEx this would be done via a validation call that explicitly
>>>>>> contains the node and the shape.
>>>>>>
>>>>>> In OWL constraints this would be done via an axiom of the form
>>>>>>
>>>>>> <code>ex:node in constraint</code>
>>>>>>
>>>>>> 2/ Nodes that are instances of a class
>>>>>>
>>>>>> A shape/constraint may be validated against all members of a class.
>>>>>> The membership determination may be via explicit direct
>>>>>> <code>rdf:type</code> links, via class membership in some
>>>>>> RDF-compatible semantics, or via some intermediate process.
>>>>>>
>>>>>> In SPIN this would be done via a <code>spin:constraint</code> link
>>>>>> from the class to a SPIN constraint.
>>>>>>
>>>>>> In OWL constraints this would be done via an axiom of the form
>>>>>>
>>>>>> <code>ex:Class <= constraint</code>
>>>>>>
>>>>>> 3/ Nodes that have a particular property value
>>>>>>
>>>>>> A shape/constraint may be validated against nodes that have a
>>>>>> particular property value.
>>>>>>
>>>>>> In OWL constraints this would be done via an axiom of the form
>>>>>>
>>>>>> <code>some ex:property ex:value <= constraint</code>
>>>>>>
>>>>>> 4/ All nodes
>>>>>>
>>>>>> A shape/constraint may be validated against all nodes (maybe only
>>>>>> non-literal nodes?).
>>>>>>
>>>>>> In SPIN this would be done via a constraint on rdfs:Resource.
>>>>>>
>>>>>> In OWL constraints this would be done via an axiom of the form
>>>>>>
>>>>>> <code>owl:Thing <= constraint</code>
>>>>>>
>>>>>> In ShEx this would be done by a validation call that explicitly
>>>>>> mentions a shape that all nodes are supposed to match.
>>>>>>
>>>>>> 5/ Triples with a particular predicate
>>>>>>
>>>>>> A shape/constraint may be validated against all triples of a
>>>>>> predicate.
>>>>>>
>>>>>> In OWL constraints this would be done via
>>>>>>
>>>>>> <code>ex:predicate <= constraint</code>
>>>>>>
>>>>>> 5/ Implicit
>>>>>>
>>>>>> The form of a shape/constraint might determine how it is validated.
>>>>>>
>>>>>> This is the general situation for OWL constraints.  An OWL
>>>>>> constraint is just an axiom that is supposed to be true. Some kinds
>>>>>> of OWL constraints can be thought of being one of the types above,
>>>>>> but other kinds of OWL constraints have particular validation
>>>>>> patterns.  For example, an OWL constraint could require that a
>>>>>> property is symmetric or transitive or that the nodes that satisfy
>>>>>> one constraint are precisely the same as those that satisfy another,
>>>>>> as in
>>>>>>
>>>>>> <code>ex:Person and some ex:SSN = ex:USResident and age > 2</code>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 17 December 2014 17:52:41 UTC