Re: Eurocentrism, incorrect unit abbreviations, and proprietary Royalist Engish (sic) terms

It's ok I understand. I just read the new README, want to make it known
that I haven't raised these concerns because of a desire for *"elegance,
'proper modeling', ontological purity or conceptual unification"*. I'm a
software developer and raise them based on identical problems faced daily
in software design.

Schema has had great success and maybe some of it by being super practical
and shipping quickly, and in software that's a great strategy too
initially. But over time if you keep only that approach the software
becomes brittle <> and
you accumulate technical debt <>.
I'm no expert, but it feels like Schema is possibly showing signs of these.
These are lessons software developers have taken decades to learn, and
seeing Schema do nothing about similar problems feels like watching
something bad about to happen and not being able to do anything about it.

On the learning front, I'm new to Schema and I know the challenge it has
been for me to learn, and so it's hard not to think about all the people
that are going to come after me and face the same difficulties too. Big
moves can set yourself up for a much better future, look at Apple when it
moved from classic Mac OS to Mac OS X in 2001 and is still on that
today. Maybe Schema can get the input of software engineers on how to
manage a change like that.

Thanks for all the interesting discussion.


On Mon, Jul 16, 2018 at 5:38 PM Dan Brickley <> wrote:

> I don't mean to shut down conversations, it's just that big email list
> discussions turn out to be a pretty crude tool. In general Github issues
> have been much more of the engine of productivity in the project, and email
> here has tended more to be where people blow off steam and vent
> frustrations. That's probably not an ideal split but it's the pattern we
> seem to fall into. In the specific case of these discussions the thing I'm
> taking away is that the Steering Group and founders could/should have been
> clearer (even, blunter) about the kinds of community discussion, vocabulary
> development and collaborative activity we are aiming at here. While it's
> very unlikely that we'll engage in large scale ontological re-engineering
> to the extent you've been advocating, I don't want to give the impression
> that community discussions are unwelcome here. But some nudges in terms of
> the kinds of collaboration would probably help. I've tweaked
> over in
> Github a little, recently, in that direction. In general (and I've said
> this before, e.g.
> )
> we need to remember that adding/reorganizing schema definitions is only one
> of the many ways in which we can have useful collaborations. It would be
> interesting and healthy to see people working together on e.g. opensource
> tooling (whether cloud, browser-based, libraries...) that *consumes*
> markup. Consuming across all domains, across the
> whole Web, is not easy (even if you're a major search engine) but there are
> plenty of other possibilities for exploiting markup and structured data
> systems that use It may be healthy if we refocus a little on
> fostering more diverse use of the definitions that we've already got,
> rather than simply debating what to add or change. And for the grand
> questions of ontoogical engineering, there's always
> :)
> Dan
> On Mon, 16 Jul 2018 at 17:12, Anthony Moretti <>
> wrote:
>> Yep, and I'm sorry. I didn't mean for it to go like this I just wanted to
>> help with Joe's original question around CampingPitch. That's my final take
>> on how to tackle it soundly anyway. Sorry to everybody who wasn't
>> interested after a certain point.
>> Anthony
>> On Mon, Jul 16, 2018 at 4:45 PM Dan Brickley <> wrote:
>>> Feels like this thread is going around in circles here, unless I'm
>>> missing something . Perhaps you could pursue this discussion in a Github
>>> issue, to save everyone's mailboxes?
>>> Dan
>>> On Mon, 16 Jul 2018 at 16:43, Anthony Moretti <>
>>> wrote:
>>>> If you wanted to solve the problem at the root you could have two
>>>> additional top-level types to classify things as suitable for sale or rent,
>>>> having an offer not being a requirement. Then anything could be multi-typed
>>>> with one or both of these:
>>>>     Things
>>>>         Events
>>>>         Organizations
>>>>         People
>>>>         Places
>>>>         *Rentable things*
>>>>         *Salable things*
>>>>         ...
>>>> It's probably not necessary though if there aren't many use cases.
>>>> Instead individual use cases like RentableCampsite could be added on
>>>> as-needed basis, and if more use cases arise this might be a general
>>>> solution.
>>>> Anthony
>>>> On Mon, Jul 16, 2018 at 10:44 AM Anthony Moretti <
>>>>> wrote:
>>>>> If you're talking from the customer side then yeah you're right, it's
>>>>> only relevant to a customer whether something has a sell/rent offer
>>>>> attached to it.
>>>>> If you're talking from the supplier side then the second meaning is
>>>>> also relevant, firstly whether something is fit or suitable for sale/rent,
>>>>> then secondly whether the supplier decides to attach one or more sell/rent
>>>>> offers.
>>>>> Publishers are generally suppliers right?
>>>>> Anthony
>>>>> On Mon, Jul 16, 2018 at 10:14 AM Martin Hepp <> wrote:
>>>>>> There are many ways of modeling the same facts, e.g. subclasses,
>>>>>> relationships or attributes. uses a typed relationship to
>>>>>> an offer to indicate whether a thing is buyable or rentable. That is
>>>>>> unlikely to change.
>>>>>> It also has a lot of advantages, e.g.
>>>>>> - there can be multiple offers referring to the same thing in
>>>>>> parallel,
>>>>>> - a thing that has been sold does not cease to exist (google
>>>>>> „OntoClean“ for background),
>>>>>> - there is a natural way of attaching meta-data of the offer
>>>>>> and more.
>>>>>> Best wishes
>>>>>> Martin
>>>>>> ---------------------------------------
>>>>>> martin hepp
>>>>>> www:
>>>>>> email:
>>>>>> Am 16.07.2018 um 17:45 schrieb Anthony Moretti <
>>>>>> Saying something is *suitable* for renting is just as valid as
>>>>>> saying something is suitable for anything else, e.g.:
>>>>>> Venue
>>>>>>     MusicVenue
>>>>>> ParkingSpace
>>>>>>     RentableParkingSpace
>>>>>> Campsite
>>>>>>     RentableCampsite
>>>>>> Anthony
>>>>>> On Mon, Jul 16, 2018 at 8:41 AM Anthony Moretti <
>>>>>>> wrote:
>>>>>>> I agree with you, I wrote that at 3 am and it's sloppy explanation
>>>>>>> and wrong and I'm sorry, the structure is still valid though. If you follow
>>>>>>> the dictionary definition of "rentable" then the mountain is a rentable
>>>>>>> mountain if it's presently true that it is "available or suitable for
>>>>>>> renting", "suitable" being the key word that shows an offer isn't required,
>>>>>>> don't even need to go to the OWA for an explanation, it's part of the
>>>>>>> definition of rentable.
>>>>>>> My point was meant to be that with the Campsite/RentableCampsite
>>>>>>> structure even uncommon scenarios where entire campsites are available as a
>>>>>>> whole for rent can be handled, in that case the campsite could be more
>>>>>>> narrowly classified as a RentableCampsite in just the same manner as the
>>>>>>> numbered sites that are part of it.
>>>>>>> Anthony
>>>>>>> On Mon, Jul 16, 2018 at 8:25 AM Dan Brickley <>
>>>>>>> wrote:
>>>>>>>> On Mon, 16 Jul 2018 at 08:00, Martin Hepp <> wrote:
>>>>>>>>> Since the Web of Data is using the Open-World Assumption, the fact
>>>>>>>>> that you do not have a triple at hand that refers to a mountain as included
>>>>>>>>> in an offer does not imply that it is not rentable etc.
>>>>>>>> and yet it is so convenient to read meaning into missing data, e.g.
>>>>>>>>> It really makes no sense to attach commercial properties to
>>>>>>>>> things, they are much better attached to offers that refer to things. That
>>>>>>>>> is, in a nutshell, the essence of the GoodRelations conceptual model: That
>>>>>>>>> products and offers are best represented as two distinct entities. I am
>>>>>>>>> sure this idea had been around before GoodRelations.
>>>>>>>> Perhaps a variation on  "All problems in computer science can be
>>>>>>>> solved by another level of indirection"
>>>>>>>> Dan
>>>>>>>>> Best wishes
>>>>>>>>> Martin Hepp
>>>>>>>>> -----------------------------------
>>>>>>>>> martin hepp
>>>>>>>>>          @mfhepp
>>>>>>>>> > On 13 Jul 2018, at 12:06, Anthony Moretti <
>>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > On Martin's point, because there isn't temporal logic everything
>>>>>>>>> should be assumed present tense. So "rentable" implies "presently rentable"
>>>>>>>>> not "potentially rentable in the future". So even though it's theoretically
>>>>>>>>> possible to rent out a mountain it's not a rentable mountain in my view
>>>>>>>>> until the offer exists.
>>>>>>>>> >
>>>>>>>>> > Anthony
>>>>>>>>> >
>>>>>>>>> > On Fri, Jul 13, 2018 at 2:34 AM Hans Polak <>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > On 13/07/18 01:25, Joe Duarte wrote:
>>>>>>>>> >> We could easily write a spec mapping the human syntax to
>>>>>>>>> machine-readable codes.
>>>>>>>>> >
>>>>>>>>> > Last time I checked, "easily" was not the case. I believe that
>>>>>>>>> human syntax is quite complicated to map... but I am not a linguist.
>>>>>>>>> >
>>>>>>>>> > If we are "divided" on how to use a word, how are we going to be
>>>>>>>>> "united" on grammar?
>>>>>>>>> >
>>>>>>>>> > My €0,02
>>>>>>>>> >
>>>>>>>>> > ~ Hans
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >

Received on Tuesday, 17 July 2018 05:15:50 UTC