Tom-- if you don't object, I'm going to bring together a few threads of conversation, just to cut down on emails.
On Nov 7, 2014, at 7:13 PM, Thomas Baker <[log in to unmask]> wrote:
>> It's not clear to me what you mean by "the formal semantics". There is not a single formal semantics for a set of triples. There are the
>> various semantics under RDF, RDFS, OWL, etc., which are compatible by design, but are _certainly distinct_.
> As in , let
> 1) P rdfs:domain C
> This entails:
> 2) C rdf:type rdfs:Class
> One may choose not to _apply_ RDFS inferencing in order to materialize triple 2 in a given dataset, but that does not change the fact that this is what "P rdfs:domain C" actually entails. I am not aware of any RDF-family semantics by which triple 2 would not be inferred.
Consider plain RDF semantics. Under them, "C rdf:type rdfs:Class" is _not_ available. Only once some inferencing regime (such as RDFS) has been brought into play does it appear. It is not impossible for Bibframe to require that consuming applications apply inferencing. I don't think it is a good idea and I've argued for that in other messages.
> The part I'm not getting is why this thread is discussing application-specific requirements for structural constraints on data
> without reference to BIBFRAME profiles, which are _all about_ specifying structural constraints on data.
Because this thread, to my understanding, isn't about structural constraints at all, and never was. Structural constraints are an interesting topic, but as I understood Rob Sanderson's original critique, the question of "types vs. properties" isn't about constraint at all. It's about extension.
The University of Virginia Library