Re: Concrete mixers

On 2 Jan 2015, at 11:54, Simon Spero <sesuncedu@gmail.com> wrote:
> Sorry about  the puns , but I literally just have a few questions about what kinds things you can do if you were to have data and object properties with the same name.
> 

This is possible in the rdf semantics (though I find the semantics a bit odd). We discussed in the WG various punning options as well.
> The motivating use case is building a bridge between schema.org (sdo) and OWL.
> 
> sdo has a data model that is roughly close to rdfs. A major difference is that instead of having domain and range statements, where multiple assertions for the same property give an effective domain / range that is the intersection of the assertions, sdo uses domainincludes and rangeincludes, which combine to form a union.
> 
Last ISWC, Peter Patel-Schneider gave a paper analysing this and giving a formal semantics for some part of schema.org. You may want to consult this.
> These could be handled either by using an anonymous type directly or by defining a named type.  The named type could either be a defined as an equivalent class for the union, or by creating an artificial supertype.
> 
> Using the equivalent+union approach should give more useful results when the hierarchy is computed (e.g  suggesting missing abstractions).
> 
> Using anonymous unions or subclassing may match the semantics of sdo more closely, but the data model is too loosely defined to be sure.
> 
> Most properties are either purely literal valued, or purely object valued, but some properties have ranges that are mixed.
> 
> In some cases this is historical accident resulting from having separately developed, conceptually independent vocabularies existing in a flat namespace. 
> In other cases the literal value is unstructured information that a sufficiently smart entity extractor could convert into an object. 
> In a third set of situations, the literal value serves as an identifier - for example, using the "descriptor(preferred label) " of a "concept" in a  "controlled vocabulary", which is required to be unambiguous. [quotes used to indicate packed terms].
> 
> In the first case, splitting the merged property into separate data and object properties on the way in and merging on the way out is the obvious approach.
> 
This a punning approach and would be in the spirit of current OWL DL. The problem we ran into that didn’t get consensus is how to handle counting quantifiers in such circumstances. E.g.,

P max 2 …

If you’re qualified…hurrah! If unqualified…hmmm.

I don’t think it’s a huge problem myself. We could default unqualified in any syntax to Thing (an unqualified data property restriction would have to be manually entered).
> In the third case, generating synthetic objects for literal values on their way in to the A-Box seems obvious - HasKey could be avoided with canonical mappings to IRI. Being able to assert a property local UNA would be handy here.
> 
> It is the second case that seems to present the most difficult problems.  There is only one conceptual property in play, and it would seem more useful to have cardinality constraints apply to all.
> 

Ooops! Yeah, if you want to count across all that’s an issue. I think it’s pretty rare right now. Not that it might not be highly useful if one were doing mixed modelling.
> Using autoboxing seems like the right thing, but could be confusing to explain (unless literal values are always boxed, which is not a performance win).
> 

?? What’s the performance issue?
> The typical use case has some form of completeness lurking in the background (probably #$completeExtentKnown or #$completeExtentAsserted).
> 
Do you mean closure? I.e., moving away from the OWA?
> Comments / Suggestions?
> 
I don’t have a good enough feel for how such  modelling would work in general. Schema.org is a good example of how schema integration might induce interesting use cases, but I don’t really have enough of a feel to get more concrete of what features this drives. This is pretty much where we ended up in the working group (though my example was Dublin Core).

Cheers,
Bijan.