Re: Schema.org and OWL

I took a closer look at the use of "Specification" and I now see that it's
only used to mean "Type" in one place in the schema -
PropertyValueSpecification, the other eight times it's used to refer to a
StructuredValue, so the generalization I made in my last message was wrong,
I'm sorry.

I tried to see where naming conventions might create more naming
consistency and I'm wondering what people think about these ideas?

   - For *StructuredValue types*: "Specification", or alternatively
   "Description", should either be removed or added to all. (My own
   preference is added.)
   - For *Enumeration types*: "Type" should either be removed or added to
   all. (My own preference is removed.)

I then looked for more cases where appending "Type" to names of
types-of-types might create consistency:


*CourseType* (currently Course)

*Course *(currently CourseInstance)


*ProductType *(currently ProductModel, subtype of Product)

*Product*

    IndividualProduct (suggest removing)

*PropertyValueType* (currently PropertyValueSpecification)

*PropertyValue*


*AudienceType (currently Audience)DishOrDrinkType (currently
MenuItem)QuantityType (currently Quantity)*


*RoomType (currently BedDetails)*

I think I now understand the opposition to making Offer etc. a subtype of
Event. So my only proposals regarding Event/Intangible are:

*Event*

*    DeliveryEvent*

*        ParcelDeliveryEvent *(currently ParcelDelivery, subtype of
Intangible)

    *Trip *(currently subtype of Intangible)


Any feedback on these ideas would be awesome!

Anthony

On Tue, Jun 12, 2018 at 12:17 PM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

> I admit I didn't see CourseInstance under Event. I still have an issue
> with the naming though because as it stands we have "instances of Courses"
> and "instances of CourseInstances":
>
> *Course*
>     Stanford CS101 (Course instance)
>
> *Event*
>
>     *CourseInstance*
>         *StanfordCS101*
>             Stanford CS101 2018-19 (CourseInstance instance)
>
>
> It comes down to how to name things when types are also desirable as
> instances. A couple of strategies already in use in Schema are to append
> "Specification" or "Model" to the type name. So this might work for courses:
>
> *CourseSpecification*
>     Stanford CS101
>
> *Event*
>
>     *Course*
>         *StanfordCS101*
>             Stanford CS101 2018-19
>
>
> The same could be done for Offer:
>
> *OfferSpecification*
>     Macy's 50% Black Friday sale
>
> *Event*
>
>     *Offer*
>         Macy's 50% Black Friday sale 2018
>
>
> Likewise, ProductModel ideally shouldn't be a subtype of Product (I think
> the reasoning about reuse of properties such as "weight" is flawed). It'd
> make more sense to follow the same pattern as the previous examples:
>
> *ProductModel*
>     iPhone X
>
> *Product*
>
>     iPhone X (serial number 12345678)
>
>
> And IndividualProduct would be removed entirely because of redundancy with
> Product. I think that when looking at type names, inclusion of
> "Individual", "Instance", or "Occurrence" are signs of potential naming or
> structural issues.
>
> In my view we could possibly also have a consistent and simple naming
> convention by using "Type", instead of "Specification" or "Model" for
> example, in all places where types are instances, so:
>
> *CourseType*
>
> *OfferType*
>
> *ProductType*
>
>
> (It even scales in the rare situations you need to model types of types
> and so on: TypeType, TypeTypeType...)
>
> On the separate topic of Events, Peter and Simon brought up endurants and
> perdurants - what about schema:Event is insufficient to cover all
> perdurants? I'm not saying we should add all types of perdurants to Event,
> that's not the intention of Schema, but why can't types we already have,
> like Trip, be moved from Intangible and put under Event? Why is a Festival
> an Event but a Trip not?
>
> Anthony
>
> On Tue, Jun 12, 2018 at 8:43 AM Sebastian Samaruga <ssamarug@gmail.com>
> wrote:
>
>> I've just uploaded PDF versions of the files so you can preview them in
>> browser instead of downloading them. Thanks!
>>
>> On Mon, Jun 11, 2018, 9:32 PM <Simon.Cox@csiro.au> wrote:
>>
>>> Hey Sebastian –
>>>
>>>
>>>
>>> If you are using GitHub for blogging, then I suggest you write in
>>> Markdown, rather than attaching .docx.
>>>
>>> That way we can read your musings directly instead of having to
>>> download.
>>>
>>>
>>>
>>> *From:* Sebastian Samaruga [mailto:ssamarug@gmail.com]
>>> *Sent:* Tuesday, 12 June, 2018 10:22
>>> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
>>> *Cc:* Anthony Moretti <anthony.moretti@gmail.com>; Dan Brickley <
>>> danbri@google.com>; Peter F. Patel-Schneider <pfpschneider@gmail.com>;
>>> Richard Wallis <richard.wallis@dataliberate.com>;
>>> public-schemaorg@w3.org; W3C Semantic Web IG <semantic-web@w3.org>;
>>> public-rww <public-rww@w3.org>
>>> *Subject:* Re: Schema.org and OWL
>>>
>>>
>>>
>>> I don't know if this really deserves attention in this context. I can't
>>> stop trying to figure out how to solve issues as such in this thread but
>>> also a more general way of using RDF (Quads) to solve other kind of
>>> mediation / alignment issues in a distributed manner.
>>>
>>>
>>>
>>> As I go along I'm dumping my thoughts in an ideas scrapbook manner. As
>>> long as I'll be able to put them into readable documents format I'll be
>>> publishing them in raw form, just for the case I'm missing something.
>>>
>>>
>>>
>>> https://github.com/ssamarug/ssamarug
>>>
>>>
>>>
>>> http://exampledotorg.blogspot.com
>>>
>>>
>>>
>>> (warning: these are just raw statements of concepts or ideas. I don't
>>> currently have time to put them in an orderly fashion, the purpose is
>>> solely to have them somewhere in the hope of having a chance to collaborate
>>> into developing them further).
>>>
>>>
>>>
>>> Best,
>>>
>>> Sebastian.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 11, 2018, 1:30 PM Sebastian Samaruga <ssamarug@gmail.com>
>>> wrote:
>>>
>>> In the realm of upper ontologies I think ISO-15926 [1] handles this sort
>>> of issues nicely (that's why I'm copying this thread to semantic-web) but
>>> it is a whole of an upper ontology and didn't have the time to understand
>>> it completely.
>>>
>>>
>>>
>>> For what is whorth for me, I'm trying to adapt an object-oriented design
>>> pattern (DCI: Data, Context and Interactions [2]) to the realm of RDF Quads
>>> metamodels. There I regard of dimensionally aggregated data (D) for which
>>> schema occurrences (C) play roles in behaviors instances / flows (I).
>>>
>>>
>>>
>>> I'm working in a formal description of the later, and I've also posted
>>> previously some blurry early drafts. I also have a strong focus in ontology
>>> alignments / translations so the use case could fit for generating other
>>> schema documents. Regards,
>>>
>>> Sebastián.
>>>
>>>
>>>
>>> [1] https://en.m.wikipedia.org/wiki/ISO_15926
>>>
>>>
>>>
>>> [2] https://en.m.wikipedia.org/wiki/Data,_context_and_interaction
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jun 11, 2018, 5:23 AM <Simon.Cox@csiro.au> wrote:
>>>
>>> My read of all this is that
>>>
>>>
>>>
>>> schema.org:Event subClassOf natural-language:Event .
>>>
>>>
>>>
>>> You need to recognize that the name of the concept in schema.org is
>>> more specialized that the use of the word 'Event' in all English-language
>>> usages.
>>>
>>>
>>>
>>> The upper-ontologies resolve this by using a more technical word - like
>>> occurrent or perdurant - which includes all time-bounded things including
>>> both planned events, unplanned incidents, things that move around, as well
>>> as other kinds of interactions. But even these attempts to define
>>> universals must be taken with a pinch of salt. Classification is contextual
>>> - the 'same thing' may be classified differently in different applications.
>>> The main application of schema.org is SEO, so the classification system
>>> is tuned to that.
>>>
>>>
>>>
>>>
>>>
>>> *Simon J D Cox*
>>> Research Scientist
>>> Land and Water
>>> <http://www.csiro.au/Organisation-Structure/Flagships/Land-and-Water>
>>> CSIRO
>>>
>>> E simon.cox@csiro.au *T* +61 3 9545 2365 *M* +61 403 302 672
>>> *   Physical: *Reception Central, Bayview Avenue, Clayton, Vic 3168
>>> *   Deliveries: *Gate 3, Normanby Road, Clayton, Vic 3168
>>>    *Postal:* Private Bag 10, Clayton South, Vic 3169
>>> people.csiro.au/C/S/Simon-Cox
>>> orcid.org/0000-0002-3884-3420
>>> researchgate.net/profile/Simon_Cox3
>>> <https://www.researchgate.net/profile/Simon_Cox3>
>>> ------------------------------
>>>
>>> *From:* Anthony Moretti <anthony.moretti@gmail.com>
>>> *Sent:* Monday, 11 June 2018 8:26 AM
>>> *To:* Dan Brickley
>>> *Cc:* Peter F. Patel-Schneider; Richard Wallis; public-schemaorg@w3.org
>>> *Subject:* Re: Schema.org and OWL
>>>
>>>
>>>
>>> Yep I definitely understand it doesn't imply disjointedness. But
>>> subclassing is answered by the "some or all" test, and I'd argue that all
>>> instances of these types are events. For example, is there an example of a
>>> trip that is not an event?
>>>
>>>
>>>
>>> And yep I completely agree, some not all books have current offers for
>>> sale/trade, so books are not a subtype of product. And I completely agree
>>> with the second example too, some not all things being offered are creative
>>> works. For example, an orange being offered for sale is a product but not a
>>> creative work, thus not all products are creative works. So I don't think
>>> those are examples of tradeoffs by schema.org, they're completely
>>> correct modeling by schema.org.
>>>
>>>
>>>
>>> If things like trips aren't considered events then strange behavior or
>>> additional work for people will result. For example a reasoner might look
>>> for all events to display on a calendar, but with the current structure all
>>> trips will have to be additionally typed as events, when in my view it
>>> should be implicit from already being classified as a trip.
>>>
>>>
>>>
>>> On Sun, Jun 10, 2018 at 2:38 PM Dan Brickley <danbri@google.com> wrote:
>>>
>>> The lack of a "subclassof" relationship doesn't mean we consider the
>>> types disjoint. You might similarly argue that all books are products, or
>>> that all products are creative works. While we respect the efforts of the
>>> ontologies community, Schema org is a bit different in the tradeoffs we
>>> have chosen to make. The looseness may be frustrating but it has also
>>> helped us grow this thing incrementally.
>>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>> On Sun, 10 Jun 2018, 14:28 Anthony Moretti, <anthony.moretti@gmail.com>
>>> wrote:
>>>
>>> If we believe schema.org will be used long into the future then even if
>>> changes are hard we should try to make them right?
>>>
>>>
>>>
>>> Arguing by word origins, even the word "action" comes from "event".
>>> Using the dictionary on Google:
>>>
>>>
>>>
>>>     "action"
>>>
>>>     "act"
>>>
>>>     "actus" (Latin) - event, thing done
>>>
>>>
>>>
>>> Arguing by structure, Actions on schema.org duplicate the startDate and
>>> endDate properties (startTime and endTime). Additionally, Actions have a
>>> state property on schema.org but Events do not, yet all action states
>>> can all be derived from more general event states. So putting Action, or
>>> any type with a startDate or endDate, as a subtype of Event actually
>>> removes redundancy.
>>>
>>>
>>>
>>> A simple test to determine whether something is an event or not is can
>>> it be put on a calendar and look normal? I think instances of all the types
>>> I mentioned can:
>>>
>>>
>>>
>>>     Event
>>>
>>>         Action
>>>
>>>         Course
>>>
>>>         Offer
>>>
>>>         ParcelDelivery
>>>
>>>         Relationship
>>>
>>>         Trip
>>>
>>>
>>>
>>> Anthony
>>>
>>>
>>>
>>> On Sun, Jun 10, 2018 at 11:38 AM Dan Brickley <danbri@google.com> wrote:
>>>
>>> Yeah, we decided against cramming Actions under Event a long time ago,
>>> even if it has a certain appeal; I' d say same goes for the other event-ish
>>> types.
>>>
>>>
>>>
>>> On Sun, 10 Jun 2018, 11:24 Peter F. Patel-Schneider, <
>>> pfpschneider@gmail.com> wrote:
>>>
>>> It's very difficult to determine what things are instance of schema.org
>>> Event
>>> because the guidance is so slim, particularly as we are not supposed  to
>>> take
>>> into account most of the information on http://schema.org/Event.   My
>>> view is
>>> that even if we are supposed to ignore everything after "certain time and
>>> location", then schema.org Event should be read narrowly, excluding
>>> things
>>> that don't have a certain time or don't have a certain location.  This
>>> would
>>> rule out Action, ParcelDelivery (as the entire delivery process), and
>>> Trip, as
>>> these generally take place over several locations.   Offer is ruled out
>>> because it often doesn't have a location at all and its temporal
>>> information
>>> doesn't have to do with its "happening".  Course is also ruled out
>>> because it
>>> is more than a sequence of lectures.
>>>
>>>
>>> One could take an expansive view of schema.org Event, perhaps saying
>>> that its
>>> instances are anything that has a temporal component and a spatial
>>> component.   So Bill Murray is an instance of schema.org Event via his
>>> birth
>>> date and his location on Earth, as is his membership in the cast of
>>> Ghostbusters.  But then what things aren't instances of Event (besides
>>> platonic entities like 3, if you assume that there are any truly platonic
>>> entities)?
>>>
>>>
>>> Is there a middle ground?  Formal ontologists have attempted to create
>>> one---dividing the universe into endurants and perdurants.  But I don't
>>> see
>>> that schema.org Event is getting at the meaning of perdurant.
>>>
>>>
>>> peter
>>>
>>>
>>>
>>>
>>> On 06/10/2018 12:32 AM, Anthony Moretti wrote:
>>> > Let's get the easy ones out of the way before looking at Roles. The
>>> > following are obviously subtypes of event, I might create an issue on
>>> GitHub
>>> > to get more feedback:
>>> >
>>> >     Event
>>> >
>>> >         Action
>>> >
>>> >         Course
>>> >
>>> >         Offer
>>> >
>>> >         ParcelDelivery
>>> >
>>> >         Trip
>>> >
>>> >
>>> > I'll argue for Role now. In my view, it would be easier to understand
>>> if the
>>> > terminology was Relation, or Relationship, rather than Role.
>>> >
>>> > An event is either:
>>> >
>>> >   * A period of time (e.g. Jun 9, 2018, 12 PM - 1 PM)
>>> >   * The period of time that a statement, explicit or implicit, is true
>>> (e.g.
>>> >     My run this morning = Anthony isRunning True)
>>> >
>>> > To be clear, having the same statement exist with different periods of
>>> > validity can still be consistent:
>>> >
>>> >   * Anthony isRunning True (Jun 9, 2018, 12 PM - 1 PM)
>>> >   * Anthony isRunning True (Jun 8, 2018, 12 PM - 1 PM)
>>> >
>>> > If you look at temporal databases
>>> > <https://en.wikipedia.org/wiki/Temporal_database> every fact has
>>> a valid
>>> > time <https://en.wikipedia.org/wiki/Valid_time> - the time period
>>> during
>>> > which the fact is true. Therefore if you reify any fact or
>>> relationship you
>>> > produce something with start or end times, therefore producing an
>>> event.
>>> >
>>> > In schema.org <http://schema.org>:
>>> >
>>> >  1. All Roles are reified relationships.
>>> >  2. Therefore all Roles have "valid times".
>>> >  3. Therefore all Roles have start or end times.
>>> >  4. Therefore all Roles are events.
>>> >
>>> > If the terminology was updated it would look like:
>>> >
>>> >     Event
>>> >
>>> >         Relationship, or Relation (currently Role)
>>> >
>>> >
>>> > Regarding Bill Murray, what is being modeled if not the fact that Bill
>>> > Murray was involved as an actor during its filming, and so for a
>>> period of time?
>>> >
>>> > And yep, I agree that you can define an entity and separately define an
>>> > event that represents its period of existence. But you can't do that
>>> for an
>>> > event, and in like fashion you can't do that for a statement either,
>>> it just
>>> > wouldn't make sense for either right?
>>> >
>>> > Anthony
>>> >
>>> >
>>> > On Sat, Jun 9, 2018 at 6:52 PM Peter F. Patel-Schneider
>>> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>> >
>>> >     Yes, many Roles in schema.org <http://schema.org> are events, and
>>> could
>>> >     be so modelled.  But not
>>> >     all, in my opinion, or at least not usefully.
>>> >
>>> >
>>> >     For example the relationship between Bill Murray and Ghostbusters
>>> is not an
>>> >     event.   It was, perhaps, initiated by a bunch of events, namely a
>>> >     sequence of
>>> >     acting performances that were captured and edited together to form
>>> the
>>> >     movie.
>>> >     However, that bunch of events is not the relationship being
>>> modelled.
>>> >
>>> >
>>> >     It's just like one might model people as their lives, i.e., an
>>> event that
>>> >     plays out (roughly) from conception to death.  But I find it
>>> useful to
>>> >     distinguish between a person and their life event.
>>> >
>>> >
>>> >     peter
>>> >
>>> >
>>> >
>>> >     On 06/06/2018 09:01 PM, Anthony Moretti wrote:
>>> >     > I agree that the first problem to do with strings can be solved
>>> by boxing
>>> >     > them into anonymous individuals. On the second problem to do
>>> with Roles I
>>> >     > agree that you can't do a simple "subjectOf" transform because
>>> Role is not
>>> >     > in the domain of "about", but maybe defining a new property such
>>> as
>>> >     > "participantIn" (domain Thing, range Role) and using it wherever
>>> a Role is
>>> >     > the object of a statement might keep about the same level of
>>> meaning (not
>>> >     > very good) but at least make it consistent OWL? So your example
>>> would be
>>> >     > transformed to:
>>> >     >
>>> >     >     DJT : Person
>>> >     >
>>> >     >         participantIn ? : Role
>>> >     >
>>> >     >             spouse MM : Person
>>> >     >
>>> >     >             startDate : 1993
>>> >     >
>>> >     >             endDate : 1999
>>> >     >
>>> >     >         participantIn ? : Role
>>> >     >
>>> >     >             spouse IT : Person
>>> >     >
>>> >     >             startDate : 1977
>>> >     >
>>> >     >             endDate : 1992
>>> >     >
>>> >     >
>>> >     > A more general solution using guidance
>>> >     > from https://www.w3.org/TR/swbp-n-aryRelations/ and with better
>>> meaning
>>> >     > might be:
>>> >     >
>>> >     >     DJT : Person
>>> >     >
>>> >     >         isSpouseFor ? : MarriageRelation
>>> >     >
>>> >     >             spouse DJT : Person
>>> >     >
>>> >     >             spouse MM : Person
>>> >     >
>>> >     >             startDate : 1993
>>> >     >
>>> >     >             endDate : 1999
>>> >     >
>>> >     >         isSpouseFor ? : MarriageRelation
>>> >     >
>>> >     >             spouse DJT : Person
>>> >     >
>>> >     >             spouse IT : Person
>>> >     >
>>> >     >             startDate : 1977
>>> >     >
>>> >     >             endDate : 1992
>>> >     >
>>> >     >
>>> >     > Your question about movie roles is also solved by this, for
>>> example:
>>> >     >
>>> >     >     Bill Murray : Person
>>> >     >
>>> >     >         isActorFor ? : PerformanceRelation
>>> >     >
>>> >     >             actor Bill Murray : Person
>>> >     >
>>> >     >             movie Ghostbusters : Movie
>>> >     >
>>> >     >             characterName : Dr. Peter Venkman
>>> >     >
>>> >     >             startDate : 1983
>>> >     >
>>> >     >             endDate : 1984
>>> >     >
>>> >     >
>>> >     > Class hierarchy:
>>> >     >
>>> >     >     Event
>>> >     >
>>> >     >         Relation
>>> >     >
>>> >     >             MarriageRelation
>>> >     >
>>> >     >             PerformanceRelation
>>> >     >
>>> >     >
>>> >     > I think confusion might come from the many English meanings of
>>> "role":
>>> >     >
>>> >     >     Type of role, e.g. Quarterback - no start or end dates.
>>> >     >     Instance of a role, e.g. 49ers quarterback 1979-1992 -
>>> potential start
>>> >     >     and end dates.
>>> >     >     Character, e.g. Hamlet - no start or end dates.
>>> >     >
>>> >     >
>>> >     > So I'm still lead to believe that Role/Relation and several
>>> other types in
>>> >     > schema.org <http://schema.org> <http://schema.org> are subtypes
>>> of
>>> >     Event because their instances
>>> >     > always have potential start and end dates:
>>> >     >
>>> >     >     Event
>>> >     >
>>> >     >         Action
>>> >     >
>>> >     >         Course
>>> >     >
>>> >     >         Role/Relation
>>> >     >
>>> >     >         Offer
>>> >     >
>>> >     >         ParcelDelivery
>>> >     >
>>> >     >         Trip
>>> >     >
>>> >     >
>>> >     > Anybody else think this too? I'm a bit new to this so hope I'm
>>> not putting
>>> >     > something too strange out there!
>>> >     >
>>> >     > Anthony
>>> >     >
>>> >     >
>>> >     > On Wed, Jun 6, 2018 at 3:20 PM Peter F. Patel-Schneider
>>> >     > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>>
>>> wrote:
>>> >     >
>>> >     >     The short-circuiting of Role in schema.org <
>>> http://schema.org>
>>> >     <http://schema.org> is
>>> >     >     certainly outside of
>>> >     >     schema.org <http://schema.org> <http://schema.org>.   OWL
>>> has
>>> >     nothing that can do the right
>>> >     >     thing with the following
>>> >     >     schema.org <http://schema.org> <http://schema.org> data
>>> >     >
>>> >     >     DJT : Person
>>> >     >       spouse ? : Role
>>> >     >                spouse MM : Person
>>> >     >                startDate : 1991
>>> >     >                endDate : 1999
>>> >     >       spouse ? : Role
>>> >     >                spouse IT : Person
>>> >     >                startDate : 1977
>>> >     >                endDate: 1992
>>> >     >       spouse MT : Person
>>> >     >     particularly in conjunction with
>>> >     >     spouse
>>> >     >       domain Person
>>> >     >       range Person
>>> >     >
>>> >     >     Except that you could turn *all* property values (except
>>> maybe for
>>> >     those
>>> >     >     properties that are guaranteed never to have a Role
>>> intermediary) into
>>> >     >     events
>>> >     >     *before* they got to OWL.  This would look something like:
>>> >     >
>>> >     >     DJT : Person
>>> >     >       spouseEvent ? : SpouseEvent
>>> >     >                     spouse MM : Person
>>> >     >                     startDate : 1991
>>> >     >                     endDate : 1999
>>> >     >       spouseEvent ? : SpouseEvent
>>> >     >                     spouse IT : Person
>>> >     >                     startDate : 1997
>>> >     >                     endDate : 1992
>>> >     >       spouseEvent ? : SpouseEvent
>>> >     >                     spouse MT : Person
>>> >     >     spouse range Person
>>> >     >            domain SpouseEvent
>>> >     >     spouseEvent range SpouseEvent
>>> >     >                 domain Person
>>> >     >     SpouseEvent sub Event
>>> >     >     startDate range Date
>>> >     >     endDate range Date
>>> >     >
>>> >     >     Hah!  That turned out better than I thought it would, but I
>>> view the
>>> >     >     need for
>>> >     >     the transform as showing that schema.org <http://schema.org>
>>> >     <http://schema.org> Role is
>>> >     >     outside the purview of OWL
>>> >     >     because it requires major surgery to the underlying ontology
>>> (as
>>> >     opposed
>>> >     >     to a
>>> >     >     transform to handle "strings as things" that just replaces
>>> such
>>> >     strings
>>> >     >     with a
>>> >     >     blank node connected to the string by some sort of
>>> description
>>> >     property
>>> >     >     which
>>> >     >     doesn't require such surgery).
>>> >     >
>>> >     >     And then what do you do about movie roles?  They shouldn't
>>> have start
>>> >     >     and end
>>> >     >     dates, or even have the possibility of start and end dates.
>>> >     >
>>> >     >     peter
>>> >     >
>>> >     >
>>> >     >
>>> >     >     On 06/06/2018 02:50 PM, Anthony Moretti wrote:
>>> >     >     > Peter, when you say "roles fall outside the purview of
>>> OWL" is
>>> >     it possible
>>> >     >     > that Role should be a subtype of Event, thus requiring no
>>> special
>>> >     >     treatment?
>>> >     >     > I say that because individual roles have potential start
>>> and end
>>> >     dates.
>>> >     >     >
>>> >     >     > If you continue that thinking you end up with several
>>> types that
>>> >     might be
>>> >     >     > considered subtypes of Event:
>>> >     >     >
>>> >     >     >     Event
>>> >     >     >
>>> >     >     >         Action
>>> >     >     >         Course
>>> >     >     >         Role
>>> >     >     >         Offer
>>> >     >     >         Parcel delivery
>>> >     >     >         Trip
>>> >     >     >
>>> >     >     >
>>> >     >     > Anthony
>>> >     >     >
>>> >     >     > On Wed, Jun 6, 2018 at 7:42 AM Peter F. Patel-Schneider
>>> >     >     > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>
>>> >     >     <mailto:pfpschneider@gmail.com <mailto:
>>> pfpschneider@gmail.com>
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>>>
>>> wrote:
>>> >     >     >
>>> >     >     >     OK, it appears that you are trying to produce an OWL
>>> >     ontology that
>>> >     >     would
>>> >     >     >     accept schema.org <http://schema.org> <
>>> http://schema.org>
>>> >     <http://schema.org>
>>> >     >     documents that would accept
>>> >     >     >     unexceptional schema.org <http://schema.org>
>>> >     <http://schema.org> <http://schema.org>
>>> >     >     >     documents (under some loose definition of what makes an
>>> >     unexceptional
>>> >     >     >     schema.org <http://schema.org> <http://schema.org>
>>> >     <http://schema.org> document).
>>> >     >     >
>>> >     >     >
>>> >     >     >     But you are running up against problems with "strings
>>> as
>>> >     things" and
>>> >     >     >     Roles.
>>> >     >     >
>>> >     >     >
>>> >     >     >     Look at about and subjectOf.   Any use of a string as a
>>> >     value for
>>> >     >     about is
>>> >     >     >     going to make that string an instance of two OWL
>>> Classes
>>> >     (the range of
>>> >     >     >     about,
>>> >     >     >     which includes Text, and the domain of subjectOf, which
>>> >     doesn't).
>>> >     >     This
>>> >     >     >     is not
>>> >     >     >     permissible in OWL.
>>> >     >     >
>>> >     >     >
>>> >     >     >     Using a role as a value for subjectOf will make the
>>> role node an
>>> >     >     instance of
>>> >     >     >     the domain of about, which doesn't include Role.
>>> Roles fall
>>> >     >     outside the
>>> >     >     >     purview of OWL.
>>> >     >     >
>>> >     >     >
>>> >     >     >     What I think has to be done for "strings as things" is
>>> to
>>> >     >     preprocess them as
>>> >     >     >     an anonymous node with the string as the value of some
>>> >     description
>>> >     >     >     property.
>>> >     >     >     Roles need to be short-circuited and the role values
>>> >     eliminated.
>>> >     >     If the
>>> >     >     >     role
>>> >     >     >     values are to be retained then some sort of fancy
>>> >     reification has
>>> >     >     to be
>>> >     >     >     introduced.
>>> >     >     >
>>> >     >     >
>>> >     >     >     But a lot of this is guesswork, as it is unclear just
>>> what
>>> >     "strings as
>>> >     >     >     things"
>>> >     >     >     and Roles mean in schema.org <http://schema.org>
>>> >     <http://schema.org>
>>> >     >     <http://schema.org>.   (I haven't looked
>>> >     >     >     closely at the use of URLs
>>> >     >     >     as stand-ins for objects but my guess is that that is
>>> similar to
>>> >     >     "strings as
>>> >     >     >     things".)
>>> >     >     >
>>> >     >     >
>>> >     >     >
>>> >     >     >     OWL makes a distinction between object and data
>>> values, and this
>>> >     >     distinction
>>> >     >     >     has to be carried through to the ontology, where there
>>> are
>>> >     classes and
>>> >     >     >     datatypes.  As far as I can tell Text should be a
>>> datatype.
>>> >     >     >
>>> >     >     >
>>> >     >     >
>>> >     >     >
>>> >     >     >     peter
>>> >     >     >
>>> >     >     >
>>> >     >     >
>>> >     >     >     On 06/06/2018 07:09 AM, Richard Wallis wrote:
>>> >     >     >     > Just the fresh pair of experienced eyes I needed! -
>>> Thanks
>>> >     @Thomas
>>> >     >     >     >
>>> >     >     >     > @Danbri - not “wasting a lot of time agonising", in
>>> simple
>>> >     terms
>>> >     >     I’m just
>>> >     >     >     > [selfishly] trying to get a useful version to load
>>> >     into Protégé and
>>> >     >     >     > hopefully helping a few others at the same time.
>>> >     >     >     >
>>> >     >     >     > @Peter thanks for your thoughtful questions.  As you
>>> can see
>>> >     >     from the
>>> >     >     >     above
>>> >     >     >     > the prime simple objective is to get it visible
>>> >     in Protégé.  Beyond
>>> >     >     >     that, it
>>> >     >     >     > is to capture the class and property hierarchy of
>>> Schema.org
>>> >     >     including
>>> >     >     >     > the multiple domain/ranges of properties defined [In
>>> >     Schema.org]
>>> >     >     using
>>> >     >     >     > domainIncludes & rangeIncludes, in a way that a tool
>>> >     >     like Protégé can cope
>>> >     >     >     > with.  As for ranges, it includes the assumption that
>>> >     properties, in
>>> >     >     >     > addition to the defined range(s), also have Text,
>>> URL, and
>>> >     Role
>>> >     >     >     included in
>>> >     >     >     > their range.
>>> >     >     >     >
>>> >     >     >     > Once I’ve done it, I want to add the simple
>>> generating code to
>>> >     >     the Schema
>>> >     >     >     > scripts run at release time so that it can be kept
>>> up to date.
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     > ~Richard.
>>> >     >     >     >
>>> >     >     >     > Richard Wallis
>>> >     >     >     > Founder, Data Liberate
>>> >     >     >     > http://dataliberate.com
>>> >     >     >     > Linkedin: http://www.linkedin.com/in/richardwallis
>>> >     >     >     > Twitter: @rjw
>>> >     >     >     >
>>> >     >     >     > On 6 June 2018 at 14:45, Peter F. Patel-Schneider
>>> >     >     >     <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com
>>> >
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>
>>> >     >     <mailto:pfpschneider@gmail.com <mailto:
>>> pfpschneider@gmail.com>
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>>
>>> >     >     >     > <mailto:pfpschneider@gmail.com
>>> >     <mailto:pfpschneider@gmail.com> <mailto:pfpschneider@gmail.com
>>> >     <mailto:pfpschneider@gmail.com>>
>>> >     >     <mailto:pfpschneider@gmail.com <mailto:
>>> pfpschneider@gmail.com>
>>> >     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>>>>
>>> wrote:
>>> >     >     >     >
>>> >     >     >     >     It's hard to say much about the file without
>>> knowing
>>> >     what it is
>>> >     >     >     supposed to
>>> >     >     >     >     capture.
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     It is supposed to capture the class and property
>>> >     hierarchy and
>>> >     >     >     property
>>> >     >     >     >     restrictions or schema.org <http://schema.org>
>>> >     <http://schema.org>
>>> >     >     <http://schema.org>
>>> >     >     >     <http://schema.org>, but not necessarily in a
>>> >     >     >     >     form compatible with RDFS
>>> >     >     >     >     or OWL?
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     Is it supposed to faithfully encode the model
>>> theory of
>>> >     >     schema.org <http://schema.org> <http://schema.org>
>>> >     >     >     <http://schema.org>
>>> >     >     >     >     <http://schema.org> in OWL?
>>> >     >     >     >     If so, where is the document for this theory?
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     Is it supposed to capture "strings as things" or
>>> Roles?
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     How does it view property domains and ranges?
>>> As
>>> >     axioms?
>>> >     >     As strict
>>> >     >     >     >     constraints?  As soft constraints?
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     I would also move from rdf/xml to turtle, which
>>> is
>>> >     easier to
>>> >     >     write and
>>> >     >     >     >     easier
>>> >     >     >     >     to read.
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     peter
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >     On 06/06/2018 05:05 AM, Richard Wallis wrote:
>>> >     >     >     >     > Calling folks with more OWL experience than me!
>>> >     >     >     >     >
>>> >     >     >     >     > The schema.org <http://schema.org>
>>> >     <http://schema.org> <http://schema.org>
>>> >     >     <http://schema.org>
>>> >     >     >     <http://schema.org> site has an OWL
>>> >     >     >     >     definition file that has
>>> >     >     >     >     > not been maintained since April
>>> >     >     >     2014: http://schema.org/docs/schemaorg.owl
>>> >     >     >     <http://schema.org/docs/schemaorg.owl>.
>>> >     >     >     >     > Also the structure and syntax of the file
>>> needs some
>>> >     >     attention.
>>> >     >     >     >     >
>>> >     >     >     >     > To help with the occasional questions about
>>> accessing
>>> >     >     processable
>>> >     >     >     >     > representations of the vocabulary; to attempt
>>> to
>>> >     close an
>>> >     >     issue
>>> >     >     >     (#1611
>>> >     >     >     >     > <
>>> https://github.com/schemaorg/schemaorg/issues/1611
>>> >     >     >     >
>>> >      <https://github.com/schemaorg/schemaorg/issues/1611>>); and to
>>> >     >     >     help with a
>>> >     >     >     >     > personal project, I have had a look at
>>> producing an
>>> >     up to
>>> >     >     date,
>>> >     >     >     improved,
>>> >     >     >     >     > maintainable version of the file.
>>> >     >     >     >     >
>>> >     >     >     >     > My first attempt can be downloaded/viewed
>>> >     >     >     >     >
>>> >     >     here:
>>> https://s3.amazonaws.com/rjwPublicData/public/schemaorg.owl
>>> >     >     >     >
>>> >      <https://s3.amazonaws.com/rjwPublicData/public/schemaorg.owl>
>>> >     >     >     >     >
>>> >     >     >     >     > I am looking for comments, suggestions, and
>>> help
>>> >     around a few
>>> >     >     >     aspects of
>>> >     >     >     >     > this work in progress:
>>> >     >     >     >     >
>>> >     >     >     >     >   * Is it generally ‘a good owl file’
>>> >     >     >     >     >
>>> >     >     >     >     >   * Should it contain more/less info about
>>> >     the vocabulary and
>>> >     >     >     its terms
>>> >     >     >     >     >
>>> >     >     >     >     >   * Specifically with reference to
>>> domainIncludes and
>>> >     >     rangeInclude -
>>> >     >     >     >     mapped
>>> >     >     >     >     >     to rdfs:domain & rdfs:range with
>>> >     owl:unionOfcollections:
>>> >     >     >     >     >
>>> >     >     >     >     >       o Is this the best/only way to represent
>>> multiple
>>> >     >     domain &
>>> >     >     >     >     ranges for
>>> >     >     >     >     >         an objectproperty?
>>> >     >     >     >     >
>>> >     >     >     >     >       o Have I got the syntax correct?
>>> >     >     >     >     >
>>> >     >     >     >     >   * Several people use Protégé
>>> >     >     <https://protege.stanford.edu/> as a
>>> >     >     >     >     tool for
>>> >     >     >     >     >     this kind of effort - I am trying to
>>> identify
>>> >     what syntax,
>>> >     >     >     will enable
>>> >     >     >     >     >     this tool to recognise the multiple
>>> >     domain/ranges when
>>> >     >     importing
>>> >     >     >     >     this file.
>>> >     >     >     >     >
>>> >     >     >     >     > If anyone out there with more OWL experience
>>> than me
>>> >     (not
>>> >     >     >     difficult),
>>> >     >     >     >     could
>>> >     >     >     >     > spend a few minutes taking a look at this and
>>> >     commenting, it
>>> >     >     >     would be
>>> >     >     >     >     > greatly appreciated.
>>> >     >     >     >     >
>>> >     >     >     >     > ~Richard
>>> >     >     >     >     >
>>> >     >     >     >     > Richard Wallis
>>> >     >     >     >     > Founder, Data Liberate
>>> >     >     >     >     > http://dataliberate.com
>>> >     >     >     >     > Linkedin:
>>> http://www.linkedin.com/in/richardwallis
>>> >     >     >     >     <http://www.linkedin.com/in/richardwallis>
>>> >     >     >     >     > Twitter: @rjw
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >     >
>>> >     >     >
>>> >     >     >
>>> >     >
>>> >
>>>
>>>

Received on Wednesday, 13 June 2018 21:09:42 UTC