- From: Irene Polikoff <irene@topquadrant.com>
- Date: Mon, 16 Feb 2015 11:56:04 -0500
- To: "kcoyle@kcoyle.net" <kcoyle@kcoyle.net>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
The way we have been handling these cases is that the organization that has validation rules associates them with the ontology representing the data sources they are using. For example, I may be getting information from source 1 that is using foaf:Person and source 2 that is using example:Employee. I am aggregating this data as my:Author. In my local graph I can either associate constraints I need for the validation with my:Author and say that foaf:Person and example:Employee are subclasses of it. Or I could associate constraints directly with these classes. I do it for each new source I decide to include in my data validation processing. It also depends on how one acquires this data. If, for example, it comes in as a POST request, the constraints to use could be referred to in the request itself. Irene > On Feb 16, 2015, at 11:18 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: > > oops. see below. > >> On 2/16/15 7:15 AM, Jerven Tjalling Bolleman wrote: >> >> >>> On 16/02/15 16:03, Karen Coyle wrote: >>> >>> >>>> On 2/16/15 2:58 AM, Jerven Tjalling Bolleman wrote: >>>> Problem: IRI's are global, shapes are local (or should be) as nicely >>>> illustrated in this example by Karen. >>>> >>>> http://lccn.loc.gov/75300479 >>>> ldom:hasShape ex:bookShape ; >>>> dct:title "Moby Dick" ; >>>> dct:creator <http://id.loc.gov/authorities/names/n79006936> ; >>>> dct:publisher "M. Kennerley" . >>>> >>>> I think Karen is right and that this is a "wrong" assertion. >>>> I believe it should be asserted as something like this. >>>> >>>> http://lccn.loc.gov/75300479 >>>> ldom:hasShape [ a ex:bookShape ; >>>> ldom:context ex:KarensBookShape ; >>>> ldom:dataContext <> ]; >>>> dct:title "Moby Dick" ; >>>> dct:creator <http://id.loc.gov/authorities/names/n79006936> ; >>>> dct:publisher "M. Kennerley" . >>> >>> No, actually, the original example is correct. My point is that my >>> desire to validate data does not translate into the data creator's >>> knowledge of my validation rules. There may be dozens of different >>> validation rules being applied to the same data by different users. >>> Think about making use of LOD data from a variety of sources who are >>> unaware of your use. >> I see your usecase, but I am surprised to read that you think the >> earlier version is better, when you are worried about ontological >> commitment. I am completely confused now. > > Sorry. Too much of a hurry. I read the first as being my original example, which was: > > http://lccn.loc.gov/75300479 > dct:title "Moby Dick" ; > dct:creator <http://id.loc.gov/authorities/names/n79006936> ; > dct:publisher "M. Kennerley" . > > None of the versions with a validation-specific shape or class in the instance data works for me. My use case is in sharing data between loosely (or not at all) connected organizations and data stores. We also must assume that our data, which will be open to the world, will be re-used in ways we cannot anticipate and perhaps by folks with whom we have no communication. > >> >> The first form states that http://lccn.loc.gov/75300479 has a shape and >> this is always true. The second says it has a shape but is only true in >> a certain context. > > Right you are. Of the forms of shapes embedded in instance data, this one is preferable. > >>> >>> I already have many linked data sources that need to be combined for >>> some of my functions. I am not operating within only my own enterprise >>> data. Some of this is data like above; some of it is SKOS data. There >>> are vocabularies and re-usable graphs that are provided globally and >>> used by hundreds of different systems. >> Yes, which is why you want to have many different validation statuses, >> right? As the validation status is independent of the conceptual data, >> validation status is a local truth, not a global truth. >> >> e.g. Everywhere I am older than 18, but not everywhere it is legal for >> me to drink in a bar. The fact that I am older than 18 is a global >> truth. If a bar is allowed to serve me ethanol is a local constraint. >>> >>> And, precisely, shapes must be inferred in some cases. >> And sometimes they must be asserted? or am I reading it to shortly. > > Sometimes they CAN or WILL be asserted, but not always. My data makes use of data from many different sources. In the example above, my Person data comes from the Library of Congress. I have no say over how the LoC codes its data. Some other data may come from Wikipedia. Eventually the publisher data may be linked off of the ISBN database. None of these will carry any information about MY validation rules. > > kc > > >>> >>> kc >>> >>> kc >>> >>> >>>> >>>> But then it could be this as well >>>> >>>> http://lccn.loc.gov/75300479 >>>> a [ rdfs:subClassOf ex:bookShape ; >>>> #subclass or type is both ok for me >>>> ldom:context ex:KarensBookShape ; >>>> ldom:dataContext <> ]; >>>> dct:title "Moby Dick" ; >>>> >>>> i.e. the choice for using the shape or class word does not make a >>>> difference. Also in both cases these would be classes per Peter's >>>> definition. As shape/class membership is asserted and not inferred. >>>> >>>> Side effects of asserting a ldom:dataContext is that such a context >>>> description can then have a cryptographic signature. e.g. >>>> >>>> >>>> http://lccn.loc.gov/75300479 >>>> ldom:hasShape [ a ex:bookShape ; >>>> ldom:context ex:KarensBookShape ; >>>> ldom:dataContext [ ex:tripleSHA512 >>>> "259ab4abea80d95150....066f331334729ba2" ; >>>> ex:pgpsignature ex:signer <mailto:example@example.org> >>>> ec:signature "259ab4abea80d95150....066f331334729ba2" >>>> ] ]; >>>> >>>> And the shape membership can then also be signed. >>>> In other words, introducing a level of indirection between a resource >>>> and a "shape" allows lots of nice features and removes a lot of >>>> objections. >>>> >>>> Regards, >>>> Jerven >>>>> On 16/02/15 11:00, Dimitris Kontokostas wrote: >>>>> >>>>> >>>>> On Sat, Feb 14, 2015 at 8:01 PM, Karen Coyle <kcoyle@kcoyle.net >>>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>>> >>>>> >>>>> >>>>> On 2/14/15 9:37 AM, Peter F. Patel-Schneider wrote: >>>>> >>>>> The question is only sensible if one already assumes RDFS >>>>> or OWL >>>>> >semantics. Outside of RDFS/OWL semantics, resources can >>>>> do all these >>>>> >things without being classes. >>>>> >>>>> OK, so replace RDF classes with "RDF types in RDF and RDFS >>>>> classes in >>>>> RDFS". The point is whether documents will contain triples >>>>> that >>>>> use shapes >>>>> where there are now RDF type or RDFS classes. >>>>> >>>>> >>>>> >>>>> If instance data will use shapes where they now use RDF, how would >>>>> you fulfill the requirements implied in User Story #4 [1] where the >>>>> same node in a graph can serve multiple roles? Or in general how do >>>>> you address re-usability of your data in different contexts? >>>>> >>>>> >>>>> Shapes does not solve this problem, maybe postpone it a bit [1] until >>>>> when/if they get further adopted. In the same way one can use different >>>>> "shapes" at different contexts, one can use different class constraints >>>>> at different contexts. >>>>> >>>>> [1] >>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jan/0198.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> kc >>>>> [1] >>>>> >>>>> https://www.w3.org/2014/data-__shapes/wiki/User_Stories#S4:___Issue_repository >>>>> >>>>> >>>>> >>>>> >>>>> <https://www.w3.org/2014/data-shapes/wiki/User_Stories#S4:_Issue_repository> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Karen Coyle >>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>> m: 1-510-435-8234 >>>>> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dimitris Kontokostas >>>>> Department of Computer Science, University of Leipzig >>>>> Research Group: http://aksw.org >>>>> Homepage:http://aksw.org/DimitrisKontokostas > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 >
Received on Monday, 16 February 2015 16:56:36 UTC