Re: Should we adopt SKOS?

Hi Mike,

I think 1) is more pragmatic than you describe.

The core motivation for many is to have a way to describe their Œthings¹ on
the web using vocabulary types and properties that Œthe search engines¹ will
commit over time to recognising.  They want their things to be discoverable.
Using, or linking to resources described using, types & properties not
recognised by the search engines will have little or no benefit towards that
end.

So starting with the Schema vocabulary Œas it is¹ trying to describe
resources (sufficiently to aid their discovery), as we are in the
bibliographic domain, it is clear there are a few gaps.  Some of those gaps
are roughly equivalent to existent vocabularies, such as GoodRelations in
ecommerce and in this case SKOS.  Hence the recommendation to adopt those
vocabularies wholesale as needed.

This does raise the issue of keeping in step with those vocabularies as they
evolve.  I suspect that would be very difficult to do in a satisfactory way.
I believe the best we could do is to adopt (copy) the vocabulary at a moment
in time into Schema and follow the extension proposal process for any
changes ­ that is the only way the Schema backers could be expected to add
them to the set that they will commit to recognising over time.

Unfortunately this is where your attractive proposal for external namespace
recognition would be difficult to implement/support ­ the only way to be
sure that the search engines will commit to recognise something is that it
is in the Schema namespace.

Having said all that, I do recognise that a spin off benefit of the Schema
initiative is the creation of a broadly recognised general purpose
vocabulary for describing most things.  Will this be good enough or detailed
enough for most domains to describe their resources for their own internal
purposes ­ probably not. It never will be for the Library domain!

As you will probably agree, Schema should not be viewed as the potential
vocabulary to rule them all.  It is however becoming the de facto vocabulary
you use to supplement your [domain¹s] vocabularies of choice to make them
discoverable by others.

I agree with your concerns in 2) - we should not lose sight of the broad
general purpose of the initiative and the goal of delivering something
simple to help people mark up their data so the search engines can discover
them.

~Richard.



On 11/01/2013 04:50, "Mike Bergman" <mike@mkbergman.com> 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
> 
> --
> __________________________________________
> 
> Michael K. Bergman
> CEO  Structured Dynamics LLC
> 319.621.5225
> skype:michaelkbergman
> http://structureddynamics.com
> http://mkbergman.com
> http://www.linkedin.com/in/mkbergman
> __________________________________________
> 
> 
>