Re: Common programming interfaces for schema.org objects

Thanks for the continued feedback. I've pulled some items from the
responses to which I will respond.


*Thad*: When you say "common contract", what basis is this derived from ?
Or is it that your organization has derived some best practices that define
this common contract and you want to share it more outside of your existing
Github account ?  Or is it your intention that this common contract still
needs more work or help from Schema.org stakeholders and experts to be
proven as a best practice ?

*Steven*: It is in fact a common contract that our organization feels would
be effective at representing the Schema.org data structures that have
affected our application, and we would like to share it more outside of our
project eco-system and vendor namespace. The JobPosting object, to which we
have taken interest, and their underlying data structures, Thing,
PostalAddress, Organization, and Place, will be "covered" during the scope
of what I am proposing here. I would like to structure the project in a way
such that additional data structures can be included either by myself or
other contributors in the future.

-------

*Thad*: How does your effort help or hinder PHP developers in working with
Schema.org

*Steven*: My hope is that these interfaces become a common resource to
include in projects that hope to utilize Schema.org standards without the
need to require implementations of the object themselves. For instance, my
project would take a dependency on the interface provided with the
namespace of "SchemaOrg\JobPosting", which will depend on the
"SchemaOrg\Intangible" and "SchemaOrg\Thing" interfaces. Likewise a
separate project may provide an implementation of the
"SchemaOrg\JobPosting" interface. These two projects would be compatible.
This pattern is available elsewhere, like http://www.php-fig.org/psr/psr-7.
Additionally, the driver behind creating a repository of interfaces is that
the package would be lightweight, it would not require the implementation
as well. To point to the PSR7 example, a popular HTTP client project,
Guzzle, takes a dependency on the PSR7 package and passes around
implementations of those objects. As a consequence, countless other
packages are now "compatible" without the weight of every implementation.

-------

*Thad*: Hod does your effort help or hinder Schema.org itself in relation
to PHP programmatic use or access.

*Steven*: I don't see how it will hinder the Schema.org itself, and am open
to feedback to the contrary. I see it as another alternative to define the
standards of the organization and introduce more projects to the data
structures at the imperative level. If projects and their developers see
value in adopting a data structure because it is easy to work with, and a
lot of work has already been done for them, then awareness and adoption can
increase. That's how we elected to adopt these standards in this particular
project.

-------

*Joachim*: Having said that, it would be really nice to have an ad hoc
programming-language representation of schema.org classes/objects and their
properties. Should this be for PHP only? No, obviously not!

*Steven*: This is a driver for this conversation. I don't necessarily think
PHP should be the only one to consider. I am proposing this one because it
appears to be the first of its kind within the Github organization and
"you've got to start somewhere".

-------

*Joachim*: How hard would it be to make your PHP-language approach generic?
Let’s say there would be some implementation (no matter which language),
which takes descriptions found on schema.org and turns them into code for
any object oriented language? I have not looked at rewriting/transformation
systems for a while (s.a. XSLT), but there should be some suitable
frameworks/tools out there which allow this. Thoughts on this?

*Steven*: The approach could be generic and portable to other languages,
and the code itself would not be. I am not interested in creating
generators, those exist already. I am more concerned with the common place
to define object interfaces so that many projects could share
implementations of these objects. With regards to other languages, I think
there could be room for language specific interfaces for other languages.
You might expect to see github.com/schemaorg/schemas-php,
github.com/schemaorg/schemas-csharp, github.com/schemaorg/schemas-java...

-------

*Martynas*: All imperative/object-oriented data structures will be
contrived approximations that will suffer from impedance mismatch just like
relational ORMs do. Haven't we learned that lesson yet?

*Steven*: While I recognize merit in the philosophical basis of this
position, the reality is that the code will be written and distributed in
projects without the consent of this organization. My goal here is to
provide a common reference for the intentions of those who are creating
these imperative/object-oriented data structures and the software that is
being produced to create and manipulate their instances. I simply want to
know if this organization has any interest in providing a home for this.


Cheers!

Steven

On Mon, Nov 2, 2015 at 3:16 PM, Martynas Jusevičius <martynas@graphity.org>
wrote:

> Hey all,
>
> schema.org is essentially an RDF vocabulary, so CONSTRUCT is the most
> natural and platform-independent way to transform it, just like XSLT
> is for XML.
>
> All imperative/object-oriented data structures will be contrived
> approximations that will suffer from impedance mismatch just like
> relational ORMs do. Haven't we learned that lesson yet?
>
>
> Martynas
> graphityhq.com
>
> On Mon, Nov 2, 2015 at 10:10 PM, Joachim Baran <kim@codamono.com> wrote:
> > Hi!
> >
> >   From my perspective, I am also hesitant to adopt SPARQL, because it
> > appears to me that no relevant commercial project has utilized it so far,
> > really no popular database supports it (Oracle aside), and the machine
> > learning and data analysis frameworks have not picked it up either.
> >
> >   Having said that, it would be really nice to have an ad hoc
> > programming-language representation of schema.org classes/objects and
> their
> > properties. Should this be for PHP only? No, obviously not!
> >
> >   How hard would it be to make your PHP-language approach generic? Let’s
> say
> > there would be some implementation (no matter which language), which
> takes
> > descriptions found on schema.org and turns them into code for any object
> > oriented language? I have not looked at rewriting/transformation systems
> for
> > a while (s.a. XSLT), but there should be some suitable frameworks/tools
> out
> > there which allow this. Thoughts on this?
> >
> > Best wishes,
> >
> > Kim
> >
> > CODAMONO, Toronto, Ontario, Canada
> > https://www.codamono.com
> >
> >
> > On November 2, 2015 at 3:17:25 PM, Thad Guidry (thadguidry@gmail.com)
> wrote:
> >
> > Steven,
> >
> > When you say "common contract", what basis is this derived from ? Or is
> it
> > that your organization has derived some best practices that define this
> > common contract and you want to share it more outside of your existing
> > Github account ?  Or is it your intention that this common contract still
> > needs more work or help from Schema.org stakeholders and experts to be
> > proven as a best practice ?
> >
> > The reason I ask is that Schema.org is tech agnostic against tools, but
> when
> > it concerns interfaces, well then that might open up discussion a bit
> more.
> > I would ask for more detail from you in regard to:
> >
> > 1. How does your effort help or hinder PHP developers in working with
> > Schema.org
> > 2. Hod does your effort help or hinder Schema.org itself in relation to
> PHP
> > programmatic use or access.
> >
> >
> > Thad
> > +ThadGuidry
> >
>