Re: Generic Property-Value Proposal for Schema.org

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.

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
>

Received on Friday, 2 May 2014 22:02:36 UTC