Re: Generic Property-Value Proposal for Schema.org

Being an early adopter myself I would like to point out one detail that
IMHO is being overlooked in this discussion so far. Cost effectiveness of
adding schema.org to a website.

I mostly work on websites of SME-sized organizations and almost have to
sell my soul to get their owners to invest in adding 1 entity extra to what
they consider the golden egg already - Rich snippets. Beyond most really
couldn't care any less since they don't see the added value of investing
any further.

Going any further than that for the masses means they'll be spending more
on semantics then the have spend on the realization of their (eCommerce)
site or on their yearly advertising budget. So any proposal that adds a
'simple' mechanism for adding semantic value, even a limited one, to a
website in a cost-effective way is a winner in my book.

The more this subject is being discusses, the more I'm getting convinced
Martin is onto something that I can see being implemented on quite a large
scale. It's simplicity makes it something that could be implemented in a
cost effective way at a low level yet still provide the opportunity to be
more specific for those that have a bigger budget and do want to take the
extra steps of using external vocabularies.

And by the way, even when dealing with organizations that do have bigger
budgets it's not a given they'll invest their resources in more elaborate
semantics. Simply because there are no tools/graphs/analytics that give any
form insight into the ROI of investing in semantics. Yet those do exist for
investments in PPC.

So even for larger corporations this proposal seems like a perfect bridge
between having no added structured data beyond Rich snippets or the
full-monty. I consider this a great step up for those who otherwise would
most definitely not choose to take that extra step.

I for one hope the details will get worked out soon and that the possible
implications for the Roles proposal get tackled as well so we can get this
implemented. And if the sponsors give this the proper media coverage, the
needed documentation, and maybe add the ever so slightest hint in what the
effect of implementing this could be, I believe we have something that
could get adopted quite fast.




On Sat, May 3, 2014 at 1:50 AM, martin.hepp@ebusiness-unibw.org <
martin.hepp@ebusiness-unibw.org> wrote:

> Actually, no - I may have been unclear, but you are mixing the markup data
> with data that you can derive from the markup data.
>
> Using propertyID with the URI of a Web vocabulary does not imply that the
> value entity has the type defined as the range for that property.
>
> >
> > here, propertyID points to http://purl.org/vvo/ns#gearbox, which
> clearly identifies the property "have gearbox type", whose range is
> http://purl.org/vvo/ns#GearboxTypeValue (which could be very be passed in
> the itemtype in addition to or in place of http://schema.org/PropertyValue
> )
>
> <div itemtype="http://schema.org/Car" itemid="car">
>   <img itemprop="image" src="station_waggon123.jpg" />
>   <span itemprop="name">Station Waggon 123</span>
>   <div itemprop="additionalProperty" itemscope itemtype="
> http://schema.org/PropertyValue" itemid="data">
>           <span itemprop="name">Gearbox Type</span>:
>           <link itemprop="value" href="http://purl.org/vvo/ns#GearboxDSG"
> />VW DSG
>           <link itemprop="propertyID" href="http://purl.org/vvo/ns#gearbox"
> />
>   </div>
> </div>
>
> does not (formally) imply that the http://schema.org/PropertyValue node
> is also of the type http://purl.org/vvo/ns#GearboxTypeValue.
>
> You can of course write a heuristic, e.g. as a SPARQL CONSTRUCT rule that
> say that if you find the above structure, then you should translate this to
>
>     :car <http://purl.org/vvo/ns#gearbox>
> http://purl.org/vvo/ns#GearboxDSG .
>
> But the PropertyValue is not directly that entity.
>
> So it would not be correct to infer
>
>     :data rdf:type http://purl.org/vvo/ns#GearboxTypeValue.
>
> Because http://purl.org/vvo/ns#GearboxTypeValue is the type for
> http://purl.org/vvo/ns#GearboxDSG, but not for the PropertyValue entity
> :data.
>
> Martin
>
> On 03 May 2014, at 01:16, Francois-Paul Servant <
> francoispaulservant@gmail.com> wrote:
>
> > Hi Martin,
> >
> > Le 3 mai 2014 à 00:02, martin.hepp@ebusiness-unibw.org a écrit :
> >
> >> Dear Francois-Paul:
> >> On 01 May 2014, at 19:24, Francois-Paul Servant <
> francoispaulservant@gmail.com> wrote:
> >>
> >>> Thad,
> >>>
> >>> not sure to fully understand you here.
> >>>> does propertyID always infer the idea of a Kind or Type ?
> >>> I'd say that if propertyID is the URI of a property, then the "idea of
> a Kind or Type" you mention would be the range of the property in question.
> >>>
> >>
> >>
> >> No, propertyID can be
> >>
> >> a) a prefixed string, mainly meant to standards for product properties,
> like eClass;
> >> b) a site-specific, non-prefixed string (e.g. the primary key of the
> property, the vendor-specific id of the property. For instance, in some
> Volkswagen systems, the property "upholstery" has the ID "4", see
> http://www.volkswagen.co.uk/vocabularies/vvo/ns#Upholstery.
> >> c) a URI or URL indicating the type of the property.
> >>
> >> So c) can be a URI of a class in a proper Linked Open Data Vocabulary,
> but it could also be the fragment URI of an entry in a car maker's glossary
> page.
> >
> > there's something that I do not understand, or a possible ambiguity,
> with c)
> > in your reply to your my first email, you give an example (and I was
> very happy with it):
> >
> > <div itemtype="http://schema.org/Car
> > ">
> >   <img itemprop="image" src="station_waggon123.jpg" />
> >   <span itemprop="name">Station Waggon 123</span>
> >   <div itemprop="additionalProperty" itemscope itemtype="
> > http://schema.org/PropertyValue
> > ">
> >         <span itemprop="name">Gearbox Type</span>:
> >         <link itemprop="value" href="
> > http://purl.org/vvo/ns#GearboxDSG
> > " />VW DSG
> >         <link itemprop="propertyID" href="
> > http://purl.org/vvo/ns#gearbox
> > " />
> >   </div>
> > </div>
> >
> > here, propertyID points to http://purl.org/vvo/ns#gearbox, which
> clearly identifies the property "have gearbox type", whose range is
> http://purl.org/vvo/ns#GearboxTypeValue (which could be very be passed in
> the itemtype in addition to or in place of http://schema.org/PropertyValue
> )
> >
> > so, I read this as: c) a URI or URL that identifies the property
> >
> > from this, we could infer
> > s http://purl.org/vvo/ns#GearboxTypeValue
> http://purl.org/vvo/ns#GearboxDSG
> >
> > if we have
> > s additionalProperty [value o ; propertyId p]
> > then
> > s p o.
> >
> > So, do you confirm that you answer "No" when I say
> > if propertyID is the URI of a property, then the value of the "value
> property" is of type in the range of propertyID
> >
> > fps
> >
> >>
> >> I do not want to revive the discussion whether using URIs of "pages" as
> proxies for entities in the context of schema.org is good or bad, but I
> think this should be allowed.
> >>
> >>
> >> Martin
> >>
> >>
> >>> fps
> >>>
> >>> Le 1 mai 2014 à 18:22, Thad Guidry <thadguidry@gmail.com> a écrit :
> >>>
> >>>> Francois, Martin,
> >>>>
> >>>> Is that the intended use for propertyID ?  I did not get the feeling
> from looking through the proposal that it could also be used to hold Kinds,
> Types, Contexts, etc.  I instead got the feeling that it was to be used for
> identifiers... ah looking at it again... now I see... so ... what is the
> eClass representation of this in reality ?
> >>>>
> >>>> <meta itemprop="propertyID" content="eclass81:02-AAM226">
> >>>>
> >>>> is that content equate to some Kind or Type ? ... does propertyID
> always infer the idea of a Kind or Type ?  if not, ... how does one infer a
> Kind or Type in Martins proposal ?
> >>>>
> >>>>
> >>>> I have a box...that has  "some KIND of Feature" ... how do I express
> that Feature KIND...that many of my boxes would share ?  Is that what
> propertyID would be used for ?
> >>>>
> >>>> (I must be really tired today)
> >>>>
> >>>>
> >>>>
> >>>> On Thu, May 1, 2014 at 11:14 AM, Francois-Paul Servant <
> francoispaulservant@gmail.com> wrote:
> >>>> Thad,
> >>>>
> >>>> I've been very fast in my explanation.
> >>>> Whatever the interpretation of PropertyValue, we can write:
> >>>>
> >>>> foo:YourBook schema:additionalProperty x:MartinHeppAsPV.
> >>>> x:MartinHeppAsPV a PropertyValue;
> >>>>    propertyID author;
> >>>>    value x:MartinHeppThePerson
> >>>>
> >>>> but x:MartinHeppThePerson and x:MartinHeppAsPV are not the same thing.
> >>>>
> >>>> Must I say that I strongly support Martin's proposal direction? My
> only concern is the following: it must allow to use a URI for the object of
> the property (the "feature") when we have one, (and minting one should be
> encouraged otherwise), because this allows to publish data as they are, and
> to lift them later.
> >>>>
> >>>> Best,
> >>>>
> >>>> fps
> >>>>
> >>>> Le 1 mai 2014 à 16:53, Thad Guidry <thadguidry@gmail.com> a écrit :
> >>>>
> >>>>> Francois,
> >>>>>
> >>>>> That's because this:
> >>>>>
> >>>>> foo:YourBook schema:additionalProperty x:MartinHeppThePerson.
> >>>>>
> >>>>> is missing the sub-property for the right context... I.E.  it's
> missing the word "author"
> >>>>>
> >>>>> 1. perhaps that missing context needs to somehow use
> "additionalType" ?
> >>>>>
> >>>>> 2. maybe context should just be the "scope" of the Property-Value
> pairing?
> >>>>>
> >>>>> In Schema.org .. Contexts and Kinds are referred to and modeled
> actually as Types. ..(well, that's how we CURRENTLY have Schema.org
> designed).
> >>>>>
> >>>>> But Martin's proposal presents a slight variation on the CURRENT
> Design...that we need, but that we need to get right...and it can be a work
> in progress starting at Products & Places. Agreed.
> >>>>>
> >>>>> Martin,
> >>>>>
> >>>>> The new proposal looks fine to me... just wondering about how to
> handle missing Context, as Francois is hitting upon...would that be through
> the use of "additionalType" or "scope" or something else ?  Can you mock up
> an example for his Sunroof case ?
> >>>>>
> >>>>> --
> >>>>> -Thad
> >>>>> +ThadGuidry
> >>>>> Thad on LinkedIn
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -Thad
> >>>> +ThadGuidry
> >>>> Thad on LinkedIn
> >>>
> >>
> >>
> >
>
>
>