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
|