- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sat, 20 Dec 2014 16:32:12 -0800
- To: kcoyle@kcoyle.net, public-data-shapes-wg@w3.org
A requirement for a URI for non-literal resources? Is there a story that needs them? peter On 12/20/2014 09:11 AM, Karen Coyle wrote: > I was using that facetiously (which doesn't come across well in email, I know.) > > But, rather than picking at nits, can we agree that we have a requirement, or > no? And if no, what would be the reason? > > kc > > On 12/20/14 8:24 AM, Peter F. Patel-Schneider wrote: >> No, we definitely do not have any story that is even vaguely related to >> this issue. >> >> Story S1 >> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S1:_The_model.27s_Broken.21 >> >> is instead about missing information in an RDF graph that defines an >> ontology. >> >> peter >> >> >> On 12/20/2014 07:51 AM, Karen Coyle wrote: >>> As we are here defining requirements that meet actual needs, don't we >>> now have >>> a requirement to include in the shapes or validation solution the >>> ability to >>> define an object type that excludes literal values? (Assuming others >>> also find >>> this requirement compelling.) Later we can determine whether/how that >>> can be >>> done. If it cannot be done with RDF, then I would hope that actual >>> user needs >>> are taken into account in RDF development, which I assume is not >>> frozen at >>> this point in time. If it cannot be done with RDF now or ever, then we >>> are >>> back to "The Model's Broken!" which is already one of our stories. >>> >>> kc >>> >>> On 12/20/14 7:12 AM, Peter F. Patel-Schneider wrote: >>>> >>>> >>>> On 12/19/2014 11:36 PM, Holger Knublauch wrote: >>>>> >>>>> On 12/20/14, 4:33 PM, Eric Prud'hommeaux wrote: >>>>>> >>>>>> > We need a URI for that, so that we can say that "every value of a >>>>>> given >>>>>> property must be a resource". Basically a way to say "anything that >>>>>> can >>>>>> appear as a subject in a triple (and therefore can have its own >>>>>> properties). >>>>>> We have always used rdfs:Resource for that and it worked well in >>>>>> practice - >>>>>> and rdfs:Literal to say "every datatype". rdfs:NonLiteral does not >>>>>> exist. >>>>>> OWL had owl:ObjectProperty and owl:DatatypeProperty, and if you left >>>>>> their >>>>>> range empty then they had that default interpretation. How was this >>>>>> ever >>>>>> supposed to work in RDF Schema? >>>>>> >>>>>> RDFS never needed to address this distinction (arguably because it's >>>>>> not s >>>>>> schema language). It is certainly better to mint a new term than to >>>>>> confuse >>>>>> the meaning of an existing term. >>>>>> >>>>> >>>>> I would be OK with a different term but this should then become the >>>>> superclass >>>>> of all other classes, so that the inheritance model is consistent. >>>>> Currently >>>>> only rdfs:Resource can play this role I think, but that unfortunately >>>>> includes >>>>> literals. And owl:Thing would suck in way too much complexity just for >>>>> this >>>>> technical detail (and existing models that use rdfs:subClassOf >>>>> rdfs:Resource >>>>> would be excluded too). >>>>> >>>>> Holger >>>>> >>>>> >>>> >>>> It appears that you are asking for the class whose instances are all >>>> resources excluding literal values. The expressive power required for >>>> this class goes well beyond the bounds of RDFS. >>>> >>>> This new class cannot be the superclass of all classes. It is not a >>>> superclass of the class that is the fixed meaning of rdfs:Resource, of >>>> course, and it is also not a superclass of class that is the fixed >>>> meaning of rdfs:Literal or of any of the datatype classes. Making this >>>> class a superclass of all classes would break RDFS. >>>> >>>> It would also not be the case that the meaning of all IRIs and blank >>>> nodes would belong to this new classes. In RDF the meaning of an IRI or >>>> a blank node can be a literal value. >>>> >>>> >>>> peter >>>> >>>> >>> >> >
Received on Sunday, 21 December 2014 00:32:41 UTC