- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 26 Jan 2015 08:38:54 +1000
- To: public-data-shapes-wg@w3.org
Peter, you started this discussion by claiming that LDOM cannot handle recursion. If you had done a text search for "recurs" you would have found ldom:violatesConstraints a ldom:Function ; rdfs:subClassOf ldom:Functions ; rdfs:label "violates constraints" ; rdfs:comment "Checks whether a given resource (?arg1) fulfills all constraints defined for a given class (?arg2) or its superclasses. This creates a (possibly recursive) LDOM constraint checker." ; and "The SPARQL query behind the ldom:OrConstraint uses a built-in helper function ldom:violatesConstraints to recursively evaluate the nested shapes." This particular information *was* already there. You seem to be asking for a formal spec, i.e. the end result of the whole WG, *before* we can even start discussing it? Holger On 1/26/15, 12:25 AM, Peter F. Patel-Schneider wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is not just a matter of details. It now appears that there are aspects > of LDOM that are not touched on in the information that has been sent out. > Without comprehensive information on what LDOM is, discussion of it in the > working group is not going to be useful. > > peter > > > On 01/24/2015 06:34 PM, Holger Knublauch wrote: >> The "magic" is in the SPARQL function ldom:violatesConstraints which has >> to be implemented by LDOM-compliant SPARQL engines. It recursively calls >> another LDOM engine with another node and shape as starting points. This >> function can also be used as entry point into the API, and could become >> one of the Use Cases in the requirements document. >> >> Yes, details will become clearer once written up. >> >> Holger >> >> >> On 1/25/2015 12:33, Peter F. Patel-Schneider wrote: I still don't see how >> LDOM can handle this example if it is all supposed to be translatable >> into SPARQL queries. Perhaps a definition of LDOM will make this clear, >> but I don't think that one has been presented as of yet. >> >> peter >> >> >> On 01/24/2015 06:23 PM, Holger Knublauch wrote: >>>>> On 1/25/2015 11:48, Peter F. Patel-Schneider wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> I can't tell whether this does or not, as there appears to be a >>>>>> missing bit after ldom:predicate. >>>>> Ok, the missing bit was a left-over from when I noticed that we >>>>> don't have a better syntax for owl:hasValue. I have meanwhile added >>>>> a new template using ldom:hasValue to improve readability (not that >>>>> it matters for the recursion though): >>>>> >>>>> ex:Polentoni a rdfs:Class ; # or ldom:Shape, or nothing >>>>> ldom:property [ ldom:predicate ex:livesIn ; ldom:hasValue >>>>> ex:NorthernItaly ; ] ; ldom:constraint [ a ldom:ShapeConstraint ; >>>>> ldom:predicate ex:knows ; ldom:all ex:Polentoni ; ] . >>>>> >>>>>> However, I don't think that it could, as least so far as I >>>>>> understand LDOM, as the class definition below appears to require >>>>>> that ex:Polentoni is asserted on some individuals, and the point >>>>>> of the example is that there are no assertions involving >>>>>> ex:Polentoni in the input. >>>>> No, this is a misunderstanding. When ldom:all is used, it will >>>>> simply check whether the instance matches all conditions specified >>>>> by the given class/shape. The rdf:type triple is not restricted by >>>>> the shape, therefore no rdf:type needs to be present on the valid >>>>> instances. >>>>> >>>>>> If LDOM does work by doing recognition, then this should be >>>>>> highlighted. >>>>> I have added a sentence >>>>> >>>>> Note that the matching values do not have to be instances of the >>>>> given shape, i.e. no <code>rdf:type</code> triple is required. >>>>> >>>>> Needless to say the overall specification needs work to clarify >>>>> and better explain these details - some of them are currently well >>>>> hidden in the implementation (Turtle code/SPARQL queries). >>>>> >>>>> HTH and thanks for the example. I hope we agree recursion is >>>>> covered. Holger >>>>> >>>>> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUxPzbAAoJECjN6+QThfjzAPwH/0WFAUqWb5oG46dcSqXBz5/S > sLeNZfxhwZjVzSgFBecNa7PD7HlpHZfqJHcBUWUL/SG7oQdHNPT8WjX0r445QNgF > 8Szl352fEZbN4mm+kyT9fOX4GPh7RjLzcC8jjMkSCVH187RwDOf+4e0RiEvcBXbj > mAXjspJEDpmAJ/h8i9KvRw2YW7+2dp9Lp1XUK7MXNemEVqF8HdagbDPgJmM3yHwH > N4Sucwe0xpSppWoRojYbOlpYaK1zV79AnIAjVa84Xg5CGSskrFPuUikMIF+5jjpa > Py6eFfNBXNMRB+eUvlfzaUxfG6/bs6bZJtFAQ4xkUb2TxkwkWFinvmFHCwYdxNc= > =Vt7w > -----END PGP SIGNATURE-----
Received on Sunday, 25 January 2015 22:39:26 UTC