- From: Jerven Tjalling Bolleman <jerven.bolleman@isb-sib.ch>
- Date: Mon, 16 Feb 2015 17:38:15 +0100
- To: public-data-shapes-wg@w3.org
On 16/02/15 17:18, Karen Coyle 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. OK, good I still think it can use some tuning to get it "right" but good to know I am thinking towards the right direction for your usecase. > >>> >>> 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. Completely agree! Your usecase is similar to my ones when we do data integration on demand. > > 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 >>>> >>> >> > -- ------------------------------------------------------------------- Jerven Bolleman Jerven.Bolleman@isb-sib.ch SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85 CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58 1211 Geneve 4, Switzerland www.isb-sib.ch - www.uniprot.org Follow us at https://twitter.com/#!/uniprot -------------------------------------------------------------------
Received on Monday, 16 February 2015 16:38:42 UTC