Jon Phipps
Fri, 19 Jun 2009 08:36:22 -0700
Hi Rob, The basic idea that we're trying to implement is to provide a way to create a DC description set profile that can be used to generate a schema that can be used to validate data, in the XML sense of valid, as well as an ontology that can be used to supply the semantics for that same data expressed as RDF.
What we're trying to do here, unfortunately, is define a restriction that can be expressed (definitely) in XML schema and an inference that can be expressed (probably) in RDFS/OWL. I was hoping that we could do this without having to leave RDF. And I didn't understand that a dual range meant both rather than either were inferred. So no-range-inference looks like the best choice. We'll have to express the restriction in another context. I have to confess to some increasingly muddy thinking -- I'm usually the person in the room who points out that RDF isn't XML and an ontology isn't a schema. But trying to think simultaneously in both models at once while working within a very strictly defined entity-relationship context is obviously proving to be a bit of a challenge. Thanks for the detailed response, Jon On Fri, Jun 19, 2009 at 2:34 AM, Rob Styles <rob.sty...@talis.com> wrote: > Hi Jon, > > On 18 Jun 2009, at 21:10, Jon Phipps wrote: > > Folks, >> >> I'm looking for some community advice on how to best model this situation: >> >> The RDA spec says that the rda:extent property applies to both >> frbr:manifestation and frbr:item. Without getting into a discussion of >> whether that's correct, I'm interested in the best way to model that. >> It looks like there are at least a couple of options... >> >> 1) declare a single property with two domains: >> >> <rda:extent> a rdf:Property ; >> rdfs:isDefinedBy <http://RDVocab.info/Elements> . >> rdfs:domain <frbr:Item> , >> <frbr:Manifestation> . >> > > It's worth remembering that the rdfs:domain predicate isn't an imlication, > not a restriction - that is it means something on the right of the property > _becomes_ the class specified by the domain of the predicate, not that it is > _restricted_ to resources of that class. > That means, in this case, that the object of an rda:extent property would > become both a frbr:Item and a frbr:manifestation. Knowing the frbr model, I > don't think that's your intention. To fix the problem and say that the thing > one the right is either one or the other looks roughly like this: > > <rda:extent> a rdf:Property ; > rdfs:domain <rda:ItemOrManifestation> . > > <rda:ItemOrManifestation> a owl:Class ; > rdfs:domain [ > a owl:Class ; > owl:unionOf [ > rdf:first frbr:Item ; > rdf:rest [ > rdf:first frbr:Manifestation ; > rdf:rest rdf:nil > ] > ] > ] ; > > This uses a bit of owl to specify a class that is the union of the two > other classes, meaning it can be either. > > >> 2) declare a single property with two subproperties: >> >> <rda:extent> a rdf:Property ; >> rdfs:isDefinedBy <http://RDVocab.info/Elements> . >> >> <rda:extentItem> a rdf:Property ; >> rdfs:subPropertyOf <rda:extent> ; >> rdfs:domain <frbr:Item> . >> >> <rda:extentmanifestation> a rdf:Property ; >> rdfs:subPropertyOf <rda:extent> ; >> rdfs:domain <frbr:Manifestation> . >> > > I'd tend to er against this as it introduces predicates that mean the same > thing but use different terms depending on the type of object, thus > duplicating the type information and making it more complex to navigate the > data without inferencing. > > I think I prefer option 2 since it allows the base property to be >> domain-free but still expresses the intent of the text and it's been >> modeled this way elsewhere [1][2], but I'm wondering if anyone has a >> good reason to prefer option 1? Or are there other ways of expressing >> this that I haven't considered? >> > > [1] when corrected, is the better way as it says what you mean without > introducing additional predicates or duplicating the type information. If > you;re happy to leave the extent property domain-free, why not just do that? > That way it is far easier for people to re-use, and as I say the domain > implies the type of the resource rather than restricting it. > > >> Cheers, >> Jon Phipps >> >> [1] http://RDVocab.info/Elements/identifierForTheItem >> [2] http://RDVocab.info/Elements/identifierForTheManifestation >> > > Rob Styles > tel: +44 (0)870 400 5000 > fax: +44 (0)870 400 5001 > mobile: +44 (0)7971 475 257 > msn: mmmmm...@yahoo.com > irc: irc.freenode.net/mmmmmrob,isnick > web: http://www.talis.com/ > blog: http://www.dynamicorange.com/blog/ > blog: http://blogs.talis.com/panlibus/ > blog: http://blogs.talis.com/nodalities/ > blog: http://blogs.talis.com/n2/ > > Please consider the environment before printing this email. > > Find out more about Talis at www.talis.com > shared innovationTM > > Any views or personal opinions expressed within this email may not be those > of Talis Information Ltd or its employees. The content of this email message > and any files that may be attached are confidential, and for the usage of > the intended recipient only. If you are not the intended recipient, then > please return this message to the sender and delete it. Any use of this > e-mail by an unauthorised recipient is prohibited. > > Talis Information Ltd is a member of the Talis Group of companies and is > registered in England No 3638278 with its registered office at Knights > Court, Solihull Parkway, Birmingham Business Park, B37 7YB. >