Re: Bob is not a shape [Was: Re: Shapes are Classes, even if you don't use rdf:type]

On 1/26/15 3:56 PM, Holger Knublauch wrote:
>
> On 1/26/15, 7:57 PM, Eric Prud'hommeaux wrote:
>>
>> We're spending time trying to coerce our general shapes language to
>> work in a system designed only for global shape constraints.
>
> Not true. LDOM is not only designed for global shape constraints. Most
> real-world applications live in controlled environments in which even
> the owl:imports come from local copies instead of the open web.

Without doing some major surveying of uses, I don't think it wise to 
make statements that begin with "most."


  These
> applications can chose exactly which graphs they want to use for their
> tasks. They can easily create their own copies of any namespace,
> redefine constraints etc.

... nor "they can easily". What's easy for one may not be easy for 
another. We should be designing for the widest possible set of uses. I 
have significant examples where "own copies" are not possible due to the 
sheer size of the vocabularies (and the relatively small size of the 
systems that must use them).

Nobody is ever forced to merge any "global"
> constraints into a single flat graph. I would even say those whole
> Semantic Web visions are pie-in-the-sky architectures.

Our context should be the capabilities of RDF and OWL, not what happens 
today within some applications. If RDF/OWL support a function, then our 
solution should also support that function. Otherwise, we are designing 
for something other than RDF. Which, Holger, it sounds like you prefer. 
Wouldn't that be a different task group?

kc

>
> Also, based on the context proposal by Jerven and Dimitris, LDOM has a
> more flexible way of slicing and dicing constraint definitions that
> further erodes the very foundation of why Shapes were originally needed.
>
>>   It seems
>> much more efficient to add SPIN support for a predicate that connects
>> classes to shapes.
>
> Yes, it already exists and is called rdf:type.
>
>> This would enable SPIN's current deployment of
>> global shapes and enable a large market with use cases that where
>> global shapes would be a harmful oversimplification.
>>
>> "All classes can play the role of a shape" doesn't imply any class
>> relationship; it just says they're not disjoint. In fact, they are
>> disjoint by almost any class definition that we find in the wild.
>>
>>    foaf:Person
>>    ┃ The Person class represents people. Something is a Person if it is
>>    ┃ a person. We don't nitpic about whether they're alive, dead, real,
>>    ┃ or imaginary. The Person class is a sub-class of the Agent class,
>>    ┃ since all people are considered 'agents' in FOAF.
>>    ┃ — http://xmlns.com/foaf/0.1/#term_Person
>>
>>    schema:Person
>>    ┃ A person (alive, dead, undead, or fictional).
>>    ┃ — http://schema.org/Person
>>
>>    dc:Policy
>>    ┃ A plan or course of action by an authority, intended to influence
>>    ┃ and determine decisions, actions, and other matters.
>>    ┃ — http://dublincore.org/2012/06/14/dcterms.rdf
>>    ┃ (dc:PhysicalResource may be a more entertaining example)
>>
>>    uniprot:cluster
>>    ┃ Cluster of proteins with similar sequences.
>>    ┃ — http://www.uniprot.org/core/#Cluster
>>
>>    fma:Kidney
>>    ┃ Corticomedullary organ which has as its part renal pelvis shared
>>    ┃ with and connected to ureter. Examples: There are only two, right
>>    ┃ kidney and left kidney.
>>    ┃ — http://fme.biostr.washington.edu/FME/body.jsp?selID=7203
>>
>> These academic-looking conflicts warn us of a fundamental modelling
>> error: attaching constraints to otherwise reusable classes. Even if
>> the WG went along with this, we'd get, and deserve, objections from
>> public review of the specs.
>
> For some cases maybe it is unwise to attach constraints to a published
> ontology, but why publish an ontology in the first place if everyone
> then uses it as they please? What is the value if people use
> foaf:firstName to point at an xsd:date? We could just as well give up on
> trying to build a better data format.
>
>
>>
>> We could decide to overlook the fact that we're using the same
>> identifier to talk about people and person records in some usage
>> context, but that in turn creates more inconsistencies (read
>> "headaches") down the road when we want to use foaf:Person in another
>> context. Separating shapes from classes clearly identifies the purpose
>> of the shape and encourages appropriate reuse. For example, a contacts
>> database might be populated by foaf:Person entries like:
>>
>>      [ a foaf:Person;
>>        foaf:mbox <mailto:kontokostas@informatik.uni-leipzig.de>;
>>        foaf:givenName "Dimitris" ;
>>        foaf:familyName "Kontokostas" ]
>>
>> could have a schema like:
>>      <ContactShape> {
>>          a (foaf:Person)?,
>>          foaf:givenName xsd:string+,
>>          foaf:familyName xsd:string
>>          foaf:mbox IRI?
>>      }
>>     or in LDOM
>>      <ContactShape> a ldom:Shape ;
>>        ldom:Property
>>          [ ldom:predicate rdf:type;
>>            ldom:allowedValues foaf:Person;
>>            ldom:minCount 0;
>>            ldom:maxCount 1 ] ,
>>          [ ldom:predicate foaf:givenName;
>>            ldom:valueType xsd:string,
>>            ldom:minCount 1 ] ,
>>          [ ldom:predicate foaf:familyName;
>>            ldom:valueType xsd:string,
>>            ldom:minCount 1,
>>            ldom:maxCount 1 ] ,
>>          [ ldom:predicate foaf:mbox;
>>            ldom:valueType xsd:string,
>>            ldom:minCount 0,
>>            ldom:maxCount 1 ] .
>>
>> which indicates the use as a contact and can be used in other contact
>> databases.
>>
>> On the occasions where there are global constraints, e.g. a square is
>> a rectangle with eqivalent sides, we can attach the shape to the class
>> with a ldom:classShape predicate.
>>
>>      ex:Square
>>          a rdfs:Class ;
>>          ldom:classShape ex:SquareShape ;
>>     rdfs:subClassOf ex:Rectangle ;
>>     rdfs:label "Square" .
>>
>> Global constraints on reusable classes is pretty rare (limited to some
>> geometric and physical laws); I think examples in the doc should focus
>> on foaf:Person, arguably one of the most reused classes in all of RDF.
>
> I disagree. The ldom:classShape above is just another way of writing
> rdfs:subClassOf. Putting that triple in there does not change anything -
> it's still a global constraint on Square. And foaf:Person is an
> unhelpful example, because it was originally designed for an open world.
> With our new language, we should start with a clean slate as mentioned
> before.
>
> Holger
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 27 January 2015 17:42:28 UTC