Re: Enhancing PropertyValue-based data (was Re: Generic Property-Value Proposal for Schema.org)

Forgive me if I misunderstand your point, but doesn't:

<div vocab="http://schema.org/" typeof="Product">
    ...
    <div property="additionalProperty" typeof="PropertyValue
http://ex.com/ov_100_250" id="http://ex.com/ov_100_250">
    ...
    </div>
</div>

get the same result as:

<div itemscope itemtype="http://schema.org/Product">
    ...
    <div itemprop="additionalProperty" itemscope itemtype="
http://schema.org/PropertyValue" itemid="http://ex.com/ov_100_250">
    <link itemprop="sameAs" href="http://acme.org/vocab/#Voltage">
    ...
    </div>
</div>

Would the @propertyID still be needed then?


On Sat, May 3, 2014 at 2:21 PM, Francois-Paul Servant <
francoispaulservant@gmail.com> wrote:

> Hi,
>
> what does it take to improve data published using PropertyValue, and to
> share the enhancements?
>
> Le 2 mai 2014 à 22:37, martin.hepp@ebusiness-unibw.org a écrit :
> <snip>
>
> Ideal Version: External Property with Qualitative Value
>
> <div itemscope itemtype="http://schema.org/Product">
>  <span itemprop="name">ACME Electric Anvil</span>
> ...
>  Operating Voltage: <div itemprop="http://acme.org/vocab/#voltage"
> itemscope
>       itemtype="http://schema.org/QuantitativeValue">
>      <span itemprop="minValue">100</span>-
>      <span itemprop="maxValue">220</span>
>      <meta itemprop="unitCode" content="VLT" > V
> </div>
>
> with this
>
> Variant 1: Property name instead of URI
>
> <div itemtype="http://schema.org/Product">
>  <span itemprop="name">ACME Electric Anvil</span>
>  <div itemprop="additionalProperty" itemscope itemtype="
> http://schema.org/PropertyValue">
>   <span itemprop="name">Operating Voltage</span>
>   <span itemprop="minValue">100</span>-
>   <span itemprop="maxValue">250</span>
>   <meta itemprop="unitCode" content="VLT"> V
>  </div>
> </div>
>
> or this
>
> Variant 2: Unit as text instead of UN/CEFACT Common Code and range as a
> single field
>
>
> <div itemtype="http://schema.org/Product">
>  <span itemprop="name">ACME Electric Anvil</span>
>  <div itemprop="additionalProperty" itemscope itemtype="
> http://schema.org/PropertyValue">
>   <span itemprop="name">Operating Voltage</span>
>   <span itemprop="value">100-250</span>-
>   <span itemprop="unitText">V</span>
>  </div>
> </div>
>
> or in worst case this:
>
> Variant 3: Range and Unit in a joint field
>
> <div itemtype="http://schema.org/Product">
>  <span itemprop="name">ACME Electric Anvil</span>
>  <div itemprop="additionalProperty" itemscope itemtype="
> http://schema.org/PropertyValue">
>   <span itemprop="name">Operating Voltage</span>
>   <span itemprop="value">100-250 V</span>-
>  </div>
> </div>
>
>
> It is obvious that the version with a dedicated property URI and a proper
> http://schema.org/QuantitativeValue node is easier to process.
>
> But from a data provider's perspective, who typically has the product
> properties in very light-weight property-value structures, with often
> proprietary properties, even the step to Variant 1 makes data publication
> much, much simpler, because he does not have to map the local property name
> to a standard property URI nor determine the type of the value
> (quantitative, qualitative, or Boolean). That is VERY difficult from
> typical Web applications, even if the back-end systems (PDM/PIM) had this
> additional data.
>
>
>
> one interesting exercise is to try to take data published in the non-ideal
> variants, and to see what it requires to get to the ideal one.
> With one constraint: we must imagine that there is already a lot of data
> published in the non-ideal variants, and that we want to lift them without
> republishing them all. This corresponds to the real situation of a client
> or a third party who wants to make use of these data and share its results.
> Or even of the publishing corporation, which may not be able without a lot
> of work to change all the publishing process as it is (neither, of course,
> to change anything to what has already been published). Is it possible to
> publish some extra statements (in an independent, supplementary process) to
> improve the non-ideal published data?
> (In an ideal situation, we publish the data, and we can improve it
> afterwards).
>
> Note that a player such as a search engine can quite easily handle the
> situation: from
> <span itemprop="name">Operating Voltage</span>
> it can easily recognize the corresponding http://acme.org/vocab/#voltageproperty in its "knowledge graph of known entities and properties" and then
> correctly index the product in question.
>
> What's for the rest of us?
>
> In the 3 variants that you describe, as they are, I think that there is no
> way to efficiently publish improved data. One can use NLP techniques to
> effectively use the data, but he/she cannot easily publish the results.
>
> The first reason is that the PropertyValue is not identified: in RDF
> terms, it is a blank node. No way to say something about it (no way to lift
> it therefore).
> So, if I have, for instance, a small program that knows that a unitText of
> "V" is equivalent to the unitCode "VLT", I can't simply publish something
> that would lift data published in variant 2 to the level of variant 1.
>
> On the other hand, if the data had been published using an identifier for
> the PropertyValues, it would have been possible: if we had for instance
> published in the first place:
> <div itemtype="http://schema.org/Product">
>    <span itemprop="name">ACME Electric Anvil</span>
>    <div itemprop="additionalProperty" itemscope itemtype="
> http://schema.org/PropertyValue" itemid="http://ex.com/ov_100_250">
>            <span itemprop="name">Operating Voltage</span>
>            <span itemprop="value">100-250</span>-
>            <span itemprop="unitText">V</span>
>    </div>
> </div>
>
> one could simply state somewhere
> http://ex.com/ov_100_250 schema:unitCode "VLT".
>
> to improve *all* the description of products published by ex.com that
> have an operating voltage of 100-250.
>
> With that, variants 2, 3 4 are basically equivalent: one can use any ML /
> heuristic technique to do the work, and easily share the results.
> The publisher of the "non-ideal" data can keep its systems running as they
> are, and just publish a small set of triples to improve all the already
> published and the to-be-published data.
>
> Now, can we reach the "ideal version" state as easily?
>
> Yes, but it requires the use of the propertyID property:
> <http://ex.com/ov_100_250> schema:propertyID <
> http://acme.org/vocab/#voltage>
> and to consider that, if the propertyID is the URI of a property, then if
> s additionalProperty pv.
> pv propertyID p.
> then s p pv.
> which is not completely in line with Martin's proposal.
>
> If this is a problem, there is a variant 0, which is an almost ideal
> version
> Variant 0: additionalProperty with External Type
>
> <div itemscope itemtype="http://schema.org/Product">
>    <span itemprop="name">ACME Electric Anvil</span>
>  ...
>   Operating Voltage: <div itemprop="additionalProperty" itemscope
> itemtype="http://acme.org/vocab/#Voltage <http://acme.org/vocab/#voltage>"
> itemid="http://ex.com/ov_100_250">
>        <span itemprop="minValue">100</span>-
>        <span itemprop="maxValue">220</span>
>        <meta itemprop="unitCode" content="VLT" > V
> </div>
> (possibly, add the propertyID to this markup)
>
> Note BTW that I do not consider the external property pattern as the
> "ideal version":
> - there will never be enough properties in a vocab: we need an
> "additionalProperty" anyway
> - it's sufficient to just define types of features in practical uses: if
> you say that your product has (="additionalProperty") a given "Voltage", do
> you really have to say that it "has voltage" the Voltage in question?
> - it doesn't work well for "configurations" (partially defined products),
> cf
> http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-11.pdf
>
> But this in another story. To summarize:
> data published in "non-ideal" versions can be easily enhanced, and the
> results shared, if and (I think) only if they include URIs for the
> PropertyValue in the first place. In this case, publishing some statements,
> independently of the original publishing, can improve a lot of data at once.
> The use of URIs for PropertyValues - local ones  is fine - should
> therefore be encouraged.
>
> (this assumes, of course, that users of the data make use of URIs and
> conflate statements published about the same URI in two different places.
> But without that, it's the whole idea of a web of data which is defeated.
> This may seem obvious, but last time I checked Google's structured data
> testing tool, it didn't do it even for statements in the same page.)
>
> fps
>
>