RE: Application-specific intersections with schema.org record types

Hi Eric,

Better a late reply than none I guess :-)

On Wednesday, August 20, 2014 6:30 PM, Eric Brisco wrote:
> Suppose we are building a new application called GuestbookPro, and we
> want to store information about each person who signs the guestbook.
> Using the schema.org vocabulary, this would be done by using the
> http://schema.org/Person record type (referred to as schema:Person
> from now on). However, say for GuestbookPro we only care to store the
> person's name and their telephone number. In that case, schema:Person
> is a much larger record than we actually need.
> 
> From what I can tell, any field of schema:Person may be null. To store

Correct. There's no requirement that you include all properties.


> a person's name and telephone number we would just store the "name"
> and "telephone" properties of schema:Person and make the assumption
> that the value of any property not present is null. However, we miss
> the opportunity to represent or document the fact that GuestbookPro
> will only ever care about "name" and "telephone" in the schema:Person
> record. If we were going to develop a viewer for GuestbookPro, we
> cannot assume that only "name" and "telephone" will be present without
> resorting to out-of-band information, because the data is representing
> that a schema:Person record is being used and so any of the fields
> must be expected.	

Right. Schema.org currently has no way to describe such things AFAICT.


> What would be more ideal is to specify a new record type as a subset
> of schema:Person. We will call this record type gbp:Person and will
> only have the properties "name" and "telephoneNumber". We then specify
> a mapping from gbp:Person to schema:Person (which is lossless), and
> from schema:Person to gbp:Person (which is lossy).

Schema.org is based on RDF which doesn't work that way. Unless explicitly
forbidden, each property can be used with any type.


> In general the
> mapping may be more complex than simply mapping property names. For
> example, a requirement may be to convert a date and time format.

That should only be required internally in your app. The external
representations should use the same format if they use the same vocabulary
(schema.org).


> Another example is that one record type may have only one property
> "fullName" and another record two properties "firstName" and
> "lastName". The purpose of this mapping is that gbp:Person may still
> be understood as a schema:Person, and a schema:Person can still be
> understood as a gbp:Person (with loss of data), so we do not lose the
> benefits of standardization and we retain the capability of defining
> types which best suit our applications.
> 
> I know of no mechanism like the one I describe, but I feel as though
> it is necessary to make schema.org practical to use, otherwise the
> scope of your application is poorly represented by the data. I am
> looking for any thoughts regarding this issue.

Since you posted to Hydra's mailing list at the same time, you probably
already know that Hydra supports doing that (not via "mappings" though).
Other vocabularies you might wanna have a look at are SPIN and Resource
Shapes and ShEx. Let's continue the discussion on the Hydra list.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 4 September 2014 10:11:32 UTC