 |
 |
FWIW the issue about inferencing is unresolved within the Shapes group. It is quite possible/likely that OWL inferencing is not required for the system to work. In practical deployments, many (if not most) RDF applications that I have seen do not have inferencing activated. Holger On 1/24/15, 11:35 AM, Young,Jeff (OR) wrote: > Karen, > > As you suggest an RDFS reasoner would infer rdf*s*:Resource. > > http://www.w3.org/TR/rdf-schema/#ch_resource > > RDFS says tomaytos, OWL says tomottos, let's call the whole thing off. :-) > > I claim that things/resources exist and can be understood without class assignments. The same is true for, say, names. Names and types are very handy, but not essential. > > Jeff > >> On Jan 23, 2015, at 6:44 PM, Karen Coyle <[log in to unmask]> wrote: >> >> Jeff, would owl:Thing really be inferred in data that limits itself to RDFS? I think it depends on the applications, and today many applications are OWL-based (and therefore convert RDFS to OWL). Using RDFS I can see that rdf:Resource would be the logical inference when no subclass of rdf:Resource is included in the instance data, but I'm not sure how and when OWL becomes a default. In any case, is my assumption correct that one CAN create even complex graphs without necessarily making use of explicit classes? >> >> kc >> >>> On 1/23/15 12:19 PM, Young,Jeff (OR) wrote: >>> Dealing with this might be an example: >>> >>> http://www.loc.gov/marc/bibliographic/bd720.html >>> >>> It's not so much that adding some types wouldn't be helpful, but sometimes we just don't know... at least not yet... and perhaps never will. >>> >>> Also note that at least one class could be automatically inferred: owl:Thing. That's because anything imaginable is, at the very least, a thing. >>> >>> Jeff >>> >>>> -----Original Message----- >>>> From: DCMI Architecture Forum [mailto:[log in to unmask]] On >>>> Behalf Of Karen Coyle >>>> Sent: Friday, January 23, 2015 3:05 PM >>>> To: [log in to unmask] >>>> Subject: Re: [RDF AP] First draft validation language proposal >>>> >>>> I am having trouble getting across the idea that one might create data without >>>> using explicit classes. I thought we could provide a DCT example, and started >>>> one, but I think it needs to show more complexity. >>>> The reason I think that is that members of the group are unable to conceive of >>>> robust data without classes. So here's my start, and perhaps someone can >>>> improve on it: >>>> >>>> @prefix dct: <http://purl.org/dc/terms/> . >>>> @prefix ex: <http://example.com/> . >>>> @prefix foaf: <http://xmlns.com/foaf/0.1/> . >>>> >>>> ex:A dct:title "Here's my book" ; >>>> dct:creator [ >>>> dct:name "Karen" ; >>>> foaf:website <http://kcoyle.net/me> ] . >>>> dct:publisher <http://www.publisher.com> ; >>>> dct:date "2015" . >>>> >>>> http://www.publisher.com dct:name "Good Books" . >>>> >>>> (I'm not sure that this illustrates what I intend it to.) >>>> >>>> kc >>>> >>>>> On 1/23/15 10:51 AM, Thomas Baker wrote: >>>>>> On Fri, Jan 23, 2015 at 10:12:38AM -0800, Karen Coyle wrote: >>>>>> "Shapes" is a new term in this context, though, which has both >>>>>> positive and negative aspects: positive because it carries less >>>>>> baggage, negative because it will be unfamiliar and will have to be >>>>>> learned. >>>>> Yes - agreed. IMO the lack of baggage is good. The language will >>>>> will have be learned, whatever it is called. >>>>> >>>>>> (Peter Patel-Schneider is dead set against anything that uses the >>>>>> term "resource" because of potential conflicts with how "resource" >>>>>> is defined in RDF.) >>>>> I'm with Peter on that. >>>>> >>>>>> The group has talked quite a bit about what to call the "target" of >>>>>> validation -- some favor using "class" because they anticipate in >>>>>> their environments that every graph they address will be >>>>>> distinguished as a particular class. Although I can see their point, >>>>>> I'm not sure that the use of classes for open data will be as >>>>>> extensive or reliable as it is in the enterprise systems that most >>>>>> working group members work on. If we anticipate using >>>>>> "un-constrained" RDA properties, then we do not have class >>>>>> information to rely on to distinguish groups of triples for >>>>>> validation. >>>>> +1 to your position on this. I strongly feel that this new language >>>>> should not depend on classes or in any way force the use of classes >>>>> (i.e., of specific subclasses of Resource). The example of >>>>> unconstrained RDA properties sounds good. >>>>> >>>>> Tom >>>>> >>>> -- >>>> Karen Coyle >>>> [log in to unmask] http://kcoyle.net >>>> m: 1-510-435-8234 >>>> skype: kcoylenet/+1-510-984-3600 >> -- >> Karen Coyle >> [log in to unmask] http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet/+1-510-984-3600