Re: RDA and ranges - take 2

Hi,

This is a really long discussion, and I am reluctant to enter it... But Gautier's OWL efforts and Karen's question ("do the FRBR domains define the properties, or do the properties define the domain?") make me think that all this is going a very strange way, model-wise.

I find this rdvocab:titleProper(Manifestation) utterly confusing. If there is an ontological commitment here, to me it is on the instances of manifestation, not the semantics of the property.

I've not read it, but I guess the rule in RDA is or can be rephrased into something like "A manifestation's title proper should obey the rules of RDA2.3.2". In OWL this could be represented by:
- creating a specific datatype (or a class if it is more convenient, as Gautier put it) that represents the RDA2.3.2 constraint, and
- assert that frbr:Manifestation is a subclass of the things that are connected to this datatype using the *generic* rdvocab:titleProper (if you want the more formal stuff the axiom are documented at http://www.w3.org/TR/owl-ref/#ValueRestriction). Which implies that all instances of rda:Manifestation should have their rdvocab:titleProper fitting the datatpye (or the class) that enforces RDA2.3.2.

This is much more efficient, and keeps titleProper at the level of genericity it should stay. In fact in linked data the links are crucial, and it's really bad practice to introduce extra links that have no added value from a modeling perspective.

Note that in UML you would do it a similar way. Along a class hierarchy, you re-use attributes with different constraints, you don't redefine a sub-attribute for every sub-class (in fact I even wonder whether this is impossible, I should go back to my textbooks...).

There are two objections to that, but they would not change the overall approach (i.e., putting the extra RDA ontological commitment on classes, not on properties):

1. If it is difficult/impossible to create a datatype (or a class) appropriately capturing RDA 2.3.2, I'd say, still in that case this is not a reason to create a titleProperManifestation property. The informal spec they would have created for rdvocab:titleProper(Manifestation) can perfectly fit in the documentation for frbr:Manifestation as well :-)

2. This representation techniques imply re-defining classes in another namespace. In that case, but you could still argue that if someones load your RDA ontology he should comply on the RDA view even on other namespace. And because this is still not really clean, you could just create your own subclass of frbr:Manifestation and specify your axioms at that level. Granted, it creates some duplication, but this is still far much better practice than duplicating all properties, imho.

Cheers,

Antoine




> Karen,
>
> To express "range: [number(literal) + unit (vocabulary:RDAcarrier) +
> subunit (literal)", you have two solutions :
>
> 1 - As Jon suggests, you can define a new datatype. But in that case,
> you can just check the syntax and you don't catch the semantic.
> 2 - You can declare a new class, for example vocab:Format (I don't find
> a better name ;-) ), a property vocab:unit,  an another class vocab:Unit
> with some instances for each unit and use the mechanism described in RDF
> primer with this example : http://www.w3.org/TR/rdf-primer/#example21 :
>
> _:a
>    rdavocab:extent _:b.
>
> _:b
>    rdf:type vocab:Format;
>    rdf:value "number"^^rdfs:Litteral;
>    vocab:unit _:a-particular-unit.
>
> _:a-particular-unit
>    a vocab:Unit;
>    rdfs:label "a particular unit".
>
> But with this solution, there is a problem too, because as we use RDF,
> all triples are independant.
>
> So you have :
> rdavocab:extents
>    rdfs:range vocab:Format
>
> and if you want to specialize with a sub-property :
> rdavocabl:extents(Manifestation)
>    rdfs:domain frbr:Manifestation ;
>    rdfs:range vocab:Format ;
>    rdfs:subPropertyOf rdavocab:extents.
>
> Best regards,
>
> Gautier
>
>
>
>
> On Wed, Aug 18, 2010 at 7:03 PM, Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>
>
>
>         What I am getting at is that we may need a hierarchy that goes like
>         this (from most specific to most general):
>
>         1. RDA + FRBR -- range is as defined in RDA; domain is FRBR entity
>         2. RDA alone -- range is as defined in RDA; no domain?
>         3. Property with definition -- range and domain are open
>
>
>     I've re-done the diagram using Extent, which I think better
>     illustrates the issue:
>
>     http://kcoyle.net/domainsrangesExtent.pdf
>
>     What is doesn't cover is a 4th possibility:
>
>     4. Property with definition + FRBR
>
>     This might be useful in creating a FRBR-zed version of MARC (but
>     maybe not) -- but in any case it is a logical extension of all of this.
>
>     kc
>
>
>     --
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     ph: 1-510-540-7596
>     m: 1-510-435-8234
>     skype: kcoylenet
>
>
>
>
>
> --
> --------------------------------------------------------------------------
> Gautier Poupeau
> Antidot     |    GSM: +33 (0)6 45 49 59 77
> F-75 Paris       |   mailto: gautier.poupeau@gmail.com
> <mailto:gautier.poupeau@gmail.com>
> Blog : Les petites cases <http://www.lespetitescases.net> | Twitter :
> @lespetitescases
> --------------------------------------------------------------------------
>

Received on Thursday, 19 August 2010 08:57:10 UTC