Re: Should we adopt SKOS?

I agree with Mike on this, although I have a slightly different set of 
objections. As I understand schema.org, it is markup for visible text, 
with some accommodation for additional description that is not visible 
to the web page reader (e.g. standardized date formats, identifiers for 
named things that have a standard ID). The value space is generally 
assumed to be the visible text. For controlled value lists, it is 
recommended that external lists be used. [1] Presumably, if the values 
have been defined in RDF or SKOS, their identifiers can be included in 
the non-visible markup.

If you think of schema.org from a product point of view, most 
manufacturers have a number of fixed sets of values: the blender comes 
in two colors; the car comes in 6 colors and 3 interior types; the 
notebook in two sizes; etc. These change from model to model, and are 
specific to that manufacturer. It seems clear to me that these lists 
should be managed by the manufacturer external to schema.org.

Any defined value that has broader usability can be on the list of 
helpful external lists and its identifier included in the microdata 
markup. (Geonames, for example; BISAC subjects as another.) I have not 
seen in this discussion an example of a value for which a 
schema.org-specific identifier would provide capabilities that cannot be 
provided by an external list.

With Mike and others I am concerned that the discussion is moving away 
from semantic mark-up of visible text to a full metadata standard 
including control of the value space. I think this adds a complication 
that threatens the usability of schema.org for its original purpose.

kc


[1] http://blog.schema.org/2012/05/schemaorg-markup-for-external-lists.html

On 1/10/13 8:50 PM, Mike Bergman wrote:
> Hi All,
>
> I have a recommendation on the SKOS issue, if you will bear with me, but
> the length of this inherited thread and its esoterica, I think, affirm
> two observations:
>
> 1) since the Good Relations adoption, there is a desire (precedent) to
> want to find additional vocabularies that can be sanctioned by
> schema.org's market position
>
> 2) schema.org risks becoming the new forum for all sorts of semantic
> folly and discussion.
>
> I think both of these are a mistake.
>
> As for 1), I can appreciate that Martin has worked the system well
> enough to get his vocabulary accepted. It is a good vocabulary, and
> Martin is a diligent advocate. But, frankly, I don't think this is a
> model we want to see perpetuated. There are multiple realms that
> conceivably deal with important dimensions of the "schema" scope; do we
> seriously think it is the role of this forum to find those encompassing
> descriptions?
>
> Vocabulary acceptance is ultimately, I think, a market position, and not
> any role or responsibility of schema.org.
>
> The *sponsors* of schema.org, however, do have what amounts to much
> market clout. If they like something, they will adopt it; if not, they
> won't. The choices they make as players in making schema.org stuff
> prominent or not will (in part) determine their own market performance.
> I accept this, and whatever this forum does, it has no ultimate bearing
> on these sponsors' market decisions. This forum is not the W3C (and even
> the W3C making such determinations has little bearing on this market).
>
> I also firmly believe that vocabulary extensions from concepts to
> products to whatever should be accommodated for within a schema.org
> framework. My issue is solely whether any single extension warrants
> sanction. Extension mechanisms, yes; specific vocabularies, no.
>
> As for 2), I think that is just a natural outcome of looking to
> schema.org as some kind of "answer" to what used to be known as the
> "chicken-and-egg dilemma" for the semantic Web. The best thing about
> schema.org is that it is a pragmatic forum to discuss prominent types of
> things and their attributes.
>
> My advice is to try to keep schema.org as a relatively pure location for
> important value:pair discussions. We'll get to the big stuff -- and
> perhaps even schema.org will be in part one vehicle for doing so --
> by-and-by, but this is a forum for *market importance* not theory.
>
> As for the SKOS stuff, we (Structured Dynamics) use it much. But the
> premise of the adoption into schema.org fits into that same
> dysfunctionality I noted above: trying to make schema.org an umbrella
> for sanctioned subsidiary vocabularies. I believe this to be a Bad Idea.
>
> My simple suggestion is to move "about" to become a property of Thing
> and not CreativeWorks (which, after reflection, is a placement that is
> silly). Then, with an extension mechanism that recognizes an external
> namespace (say, gr: or umbel: or dc:) enable that (or perhaps, many
> other schema: properties) to extend the umbrella.
>
> As for SKOS, I think it is generally orthogonal to a schema.org
> specification. Like any vocabulary on the Web, map to the concepts that
> make sense for you. If "about" with namespace recognition were added to
> schema.org, there would be no further questions about what to do with
> SKOS or any other Web vocabulary.
>
>      schema.org != semantic web
>
> Thanks, Mike
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 11 January 2013 17:16:31 UTC