Holger, how I read what you are saying is that there are two options:
- validation based on classes
- global validation
If one is not uses classes, how is the "whole graph" defined? What makes
a graph "the whole graph"? A single subject? Some shape? Or does whole
graph mean absolutely every triple in your triple-store?
kc
On 1/23/15 6:09 PM, Holger Knublauch wrote:
> In the language currently called LDOM, users can create constraints that
> are evaluated globally for the whole graph (currently called
> ldom:StaticConstraint). In those cases where a class-based data model is
> present, LDOM supports a pattern in which constraints are attached to
> classes (using ldom:property and ldom:constraint), and those are
> evaluated based on the presence of rdf:type triples.
>
> Holger
>
> On 1/24/15, 11:56 AM, Young,Jeff (OR) wrote:
>> Does the Shapes group require a type assignment to qualify its
>> functionality? The answer shouldn't be important.
>>
>>
>>
>>> On Jan 23, 2015, at 8:51 PM, Holger Knublauch
>>> <[log in to unmask]> wrote:
>>>
>>> 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
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|