Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension Mechanism #284

Closed
elf-pavlik opened this issue Jan 25, 2015 · 31 comments

Comments

@elf-pavlik
Copy link
Contributor

commented Jan 25, 2015

Following up on #164, schema.org could use solid recommendations for extending it.
I made some suggestions over mailing list

Maybe as first step we could collect various existing experiences on Extension Mechanism wiki page?

@danbri

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2015

Thanks. I suggest keeping compare-and-contrast experience notes here rather than in Wiki as for a topic like this it is important to keep track of who is saying what, which the issue tracker does better. So I'd keep the Wiki for 'links on this topic' for now.

@chaals

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2015

  • reply@
  • notifications@

26.01.2015, 17:25, "Dan Brickley" notifications@github.com:

Thanks. I suggest keeping compare-and-contrast experience notes here rather than in Wiki as for a topic like this it is important to keep track of who is saying what, which the issue tracker does better. So I'd keep the Wiki for 'links on this topic' for now.

Hmm. Or descriptions of the possible approaches - but as danbri says it is important to annotate them with who says so.

For what it's worth I am concerned about the current approach to extension because it doesn't allow for URLs that go somewhere, and explicitly breaks the idea of decentralising which can readily lead to clashes.

It seems to be an artifact of the original idea that we would use microdata - and are therefore restricted in how we can mix vocabularies. While that strikes me as another lesson in what is wrong with microdata, we are still seeing a lot of it in Russia :(

I think an extension mechanism is important - endlessly expanding schema.org isn't part of our goals either, which means we need one that works.

cheers

Chaals

Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

@danbri

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2015

Historically there have been several different yet related uses of the word 'extension' around here.

  • The processes for adding new vocabulary into schema.org, e.g. the "rnews" or "good relations" or "lrmi" extension, which was basically a proposal to improve/change schema.org's own vocabulary.
    • Initially (when deployment = zero) we said "propose in any form you like ...", e.g. send a PDF, a textual message on the mailing lists, a word processor document, etc. And we used W3C's Wiki to wrap a layer of admin around that chaos.
    • This hit a limit with the Good Relations proposal, which was handled initially as a very large Google doc.
    • At this point schema.org was still hosted on Google tooling but we implemented a capability for importing RDFa/HTML RDFS files, and started using W3C's Mercurial repository for these, or in the GR case see also Martin Hepp's repository.
    • Several proposals during 2013 were developed via Mercurial collaboration, however at that time only someone at google could easily generate a test version of the site for review, which was a painful bottleneck.
    • During 2014 schema.org tooling was migrated to an opensource appengine app, alongside a move from Mercurial to Git(hub). Various W3C groups also adopted Github due to its wide adoption amongst developers.
    • The current "extend schema.org itself" model now builds on Github style collaboration, including the use of branches/forks etc.
  • From launch there was also the rough idea that publishers (initially of Microdata) could simply add in more information by adding a '/' into the type and property names. The page at http://schema.org/docs/extension.html documented this, and was recently updated to indicate some other ways of extending schema.org.
    • The classic problem here is that by using '/'-extensions you don't get to document clearly what you have done. So if you write itemtype="http://schema.org/Person/Minister" you don't get anywhere to document whether this is Minister in the religious vs political sense.
    • A patch to the schema.org codebase to handle URLs like http://schema.org/Person/Minister would be very useful. See #6
    • The appeal of "/"-extensions is lower when using RDFa 1.1 and JSON-LD, since those notations are more strongly in the RDF tradition of supporting simultaneous use of multiple vocabularies. Microdata assumes that in each itemscope there's a single vocabulary in scope. The http://schema.org/additionalType property was added to support the provision of extra types from other vocabularies in microdata syntax.
    • Microdata remains (as we begin 2015) the "lowest common denominator" in terms of being explicitly supported by the schema.org search companies.
  • The new-ish http://schema.org/Role type provides another built-in schema.org mechanism for qualifying any factual statement with additional information (using schema.org vocabulary or other).
  • The initial language at the time of schema.org's launch gave the impression that it shouldn't be mixed with other vocabularies. Later it has been presented more inclusively, and there are many other existing RDF-compatible vocabularies that can be directly mixed into pages alongside schema.org.
  • Sometimes extensions proposed to schema.org have been partially accepted, with some details not being added. For example the original https://www.w3.org/wiki/WebSchemas/SoftwareApplicationSchema proposal had a set of types for kinds of software applications which were understood by Google's Rich Snippet feature (https://developers.google.com/webmasters/structured-data/rich-snippets/sw-app) but which didn't become part of schema.org. Google continued to understand it anyway.
  • There is a loose understanding amongst the schema.org partners that it is OK to try out potential new vocabulary in products/tools and partnerships, even before it is fully agreed. This comes with a pretty commonsense consequence which is that potentially unstable proposals should be documented as such. In other words there is less pressure to use "vendor prefix" -oriented mechanisms such as seen in the (CSS world)[https://wiki.csswg.org/spec/vendor-prefixes].
  • Sometimes there are large domain specific vocabularies which may be too large to add directly to schema.org, for maintainability and usability reasons.
  • Schema.org is generally designed so that it can be consumed without crawling around for mapping files, but has not explicitly documented examples in which a basic description and a larger richer description co-habit in the same page.
  • The topic of "External enumerations" has been discussed and documented e.g. in a blog post and Wiki writeup. The rough idea is to say "schema.org does not want to standardize long lists of things. The initial proposal in this area was focussed on a types and instances model, e.g. we might have "Country" in schema.org but not a list of actual countries.
  • There is also a strand of activity around SKOS (W3C's RDF vocabulary for topics / thesauri / classifications), where SKOS captures many simple use cases that aren't modeled explicitly as type hierarchies. See https://www.w3.org/wiki/WebSchemas/SKOS ... Roughly this would address properties values where the value comes from a larger and pre-existing list rather than an enumeration built in to schema.org. e.g. Code lists in geospatial data are sometimes modeled this way.

In summary there are lots of ways in which a schema.org based description might go beyond the basics, but I don't think we'll ever have a single unified extension mechanism.

@sesuncedu

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2015

How much is the slash mechanism actually used in practice?

If there are only trace amounts, of data where it doesn't make a
difference, I would suggest fixing microdata.

  1. Provide a way to specify prefixes for abbreviated IRIs. Meta might be a
    good place.
    Predefine schema: to map to http://schema.org/ .
    Require prefix names that match URI scheme names to map to themselves. (
    http: -> http: ).
    Allow : in names.
  2. Provide a way to import term sources (possibly a flag for prefix
    definition). If dereferencable, should dereference to an rdfs document, a
    sdo document, or an OWL document.
  3. Specify in a specification that the vocabulary is specified to include
    everything necessary for it to work (ie any property whose domain allows
    and that is a (possibly abbreviated) IRI can be used on any type.
  4. Encourage use of abbreviated IRIs as type and property names.
  5. Handle colon-less names using legacy mechanism, but deprecate for schema:
    Register schema as an IRI prefix for backwards compatibility (something
    that has not been a

Living standards are like unwritten constitutions...

@melvincarvalho

This comment has been minimized.

Copy link

commented Jan 26, 2015

Would a group of people be interested in a joined collaboration of a non official extension vocab to schema.org -- ie a related document with shared access to add use case driven terms, that may not be appropriate for the core?

@danbri

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2015

@melvincarvalho lots of groups of people have been doing just that around here for years, that's where much of http://schema.org/docs/releases.html came from. Did you have any particular domain in mind?

@vholland

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

It is sometimes difficult to separate out intentional use of the slash mechanism from typos or other errors. It is clearest when someone adds a new type like http://schema.org/Thing/Animal, but sometimes people skip the parent type and just do http://schema.org/Animal. It becomes even murkier if/when schema.org adopts that type officially.

Properties are even harder to figure out as they have no parent to hang off of. Did the author use http://schema.org/actor on an http://schema.org/Event because http://schema.org/performerIn was insufficient or because the author missed the latter when reading the docs?

@sesuncedu

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

Even if schema:Animal is defined, and is defined as a direct or indirect
subclass of schema:Thing, there would still have to be an explicit
equivalence axiom stated for the slash class.

This would be dangerous, as the only thing we can infer about
schema:Thing/Animal is that it is a subclass of schema:Thing. Different
uses on different pages may mean completely different things.

A Muppet toy store might define Thing/Animal to be the class of all plush
toys depicting the character of that name.

Some properties are hierarchical. It would seem plausible for actor to be
made a sub-property of performer, but that is getting out of the meta- and
into the ontology.
On Jan 28, 2015 9:48 AM, "vholland" notifications@github.com wrote:

It is sometimes difficult to separate out intentional use of the slash
mechanism from typos or other errors. It is clearest when someone adds a
new type like http://schema.org/Thing/Animal, but sometimes people skip
the parent type and just do http://schema.org/Animal. It becomes even
murkier if/when schema.org adopts that type officially.

Properties are even harder to figure out as they have no parent to hang
off of. Did the author use http://schema.org/actor on an
http://schema.org/Event because http://schema.org/performerIn was
insufficient or because the author missed the latter when reading the docs?


Reply to this email directly or view it on GitHub
#284 (comment).

@vholland

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

Agreed. There are many ways the current extension mechanism makes it impossible to discern intent, so we can't use it as a clear signal for ways to expand the schema.

@thadguidry

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

K.I.S.S. Keep It Simple Smartypants

Let just use "+" plus sign for expansion.

http://www.schema.org/MedicalClinic+PlasticSurgeryProvider

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "LocalBusiness+MedicalOrganization+PlasticSurgeryProvider",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "streetAddress": "1200 Highway 75"
  },
  "description": "A superb clinic with world class emergency care services",
  "name": "iCare Clinic",
  "telephone": "850-555-1234",
  "+proceduresPerformed": "Lap Band, Tummy Tuck, Rhinoplasty"
}
</script>

I just did a quick Multi Type Entity. And I added a custom property. Wow, I'm badass.

<script type="application/ld+json">
{ "@context" : "http://schema.org",
  "@type" : "Organization",
  "url" : "http://www.your-company-site.com",
  "contactPoint" : [
    { "@type" : "ContactPoint",
      "telephone" : "+1-401-555-1212",
      "contactType" : "customer service"
      "+holidaysClosed" : "Christmas, Easter, My Birthday"
    } ] }
</script>

I just added a new custom property called "holidaysClosed".

Now, I just need to know where and how I document my custom properties and my PlasticSurgeryProvider in JSON-LD. Agree, then DONE.

@chaals

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

  • reply@- schemaorg@, notifications@28.01.2015, 19:59, "Thad Guidry" notifications@github.com:K.I.S.S. Keep It Simple SmartypantsLet just use "+" plus sign for expansion.http://www.schema.org/MedicalClinic+PlasticSurgeryProviderThat has similar problems to slash.Now, I just need to know where and how I document my custom properties and my PlasticSurgeryProvider in JSON-LD. Agree, then DONE.We need to explain how this works in microdata, too. Or drop ongoing support for microdata. If we added documentation properties to schema itself, you could document your extension within your custom data. But that's more than a little unwieldy.  cheers Chaals --Charles McCathie Nevile - web standards - CTO Office, Yandexchaals@yandex-team.ru - - - Find more at http://yandex.com 
@thadguidry

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@chaals Disagee that it will be unwieldy. Basic "description" property should cover it. The idea is that of extensions getting out in the wild sooner and allowing a playground for the long tail domains. We MUST provide that playground, even if our tools do not understand fully that long tail domain completely, we can allow developers to give some "descriptions" and "hints" to foster grow of them.

Your "has similar problems to slash" is probably because you lack documentation. You can easily parse out "PlasticSurgeryProvider", you just need to know what new properties are hanging off of it, right ? So...

"+PlasticSurgeryProvider:proceduresPerformed":""Lap Band, Tummy Tuck, Rhinoplasty"
@Dataliberate

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

As it was mentioned I thought it would be worth giving a brief overview of
the logic behind the way BiblioGraph.net extends Schema.org.

  • BiblioGraph.net is not intended to become a stand-alone vocabulary -
    it needs Schema.org to function.
  • Described as a 'filling in the gaps' vocabulary for our
    [bibliographic] domain. Also referred to by some as a frosting on the
    Schema.org cake.
  • Objective was to produce a complete view of the total vocabulary -
    Schema.org + BiblioGraph.net so that a user could get all information,
    description, examples in one place and naturally use the Schema types and
    properties, we want them to, along side the BiblioGraph ones.
  • This was achieved by building the BiblioGraph site using a forked
    version of the schemaorg software that merges the two domains together.
  • Apart from the bibliograph.net namespace the description and
    management of extension Types and properties is the same as for Schema
    itself:
  • defined in the BiblioGraph rdfa
    http://bibliograph.net/docs/bibliograph_net_rdfa.html file,
    • Types defined as subTypes of Schema Types
    • Properties with domain and range statements for Schema and/or
      BiblioGraph types.

It seems to work simply and well.

  • Tracking code updates via github
  • Keeping up to date with Schema.org versions by copying the latest rdfa
    file
  • Managing BiblioGraph extensions in the BiblioGraph rdfa file.

It's not perfect and given time I would like to enhance things a little,
for example to avoid name clashes if a BiblioGraph term is deprecated in
favour of it being adopted by Schema.

Any questions, just ask.

~Richard.

On 28 January 2015 at 16:33, vholland notifications@github.com wrote:

Agreed. There are many ways the current extension mechanism makes it
impossible to discern intent, so we can't use it as a clear signal for ways
to expand the schema.


Reply to this email directly or view it on GitHub
#284 (comment).

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Tel: +44 (0)7767 886 005

Linkedin: http://www.linkedin.com/in/richardwallis
Skype: richard.wallis1
Twitter: @rjw

@elf-pavlik

This comment has been minimized.

Copy link
Contributor Author

commented Jan 28, 2015

@danbri I understand your reasoning for using this issue over wiki page, but as you see very likely it will become a lengthy one... I will still try to capture some highlights on that wiki page!

I also created placehoder section on that wiki page to start capturing limitations of Microdata https://github.com/schemaorg/schemaorg/wiki/Extension-Mechanism#limitations-of-microdata
IMO asking people to use RDFa or JSON-LD if they want to use extensions of schema.org makes sense. Otherwise the whole ecosystem will suffer from shortcomings of microdata 😞

@gkellogg

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@thadguidry said:

Let just use "+" plus sign for expansion.

http://www.schema.org/MedicalClinic+PlasticSurgeryProvider

I don't see how this really improves on the '/' separator. In any case, it doesn't create a class (or property) which is actually defined in a schema which can be determined from the markup, so the Linter will flag such usage.

@thadguidry continues:

Now, I just need to know where and how I document my custom properties and my PlasticSurgeryProvider in JSON-LD. Agree, then DONE.

Interesting idea, for JSON-LD, anyway, would be to define it as RDFS in an included context. Normally, a referenced context is only used for term definitions, but my practice is to also put the RDFS definition of any new terms in there as well.

@chaals replied:

We need to explain how this works in microdata, too. Or drop ongoing support for microdata. If we added documentation properties to schema itself, you could document your extension within your custom data.

This mechanism would work just fine with Microdata to RDF as it is now, and it should work just as well using regular Microdata too, modulo the lack of term definition.

@elf-pavlik concludes:

IMO asking people to use RDFa or JSON-LD if they want to use extensions of schema.org makes sense. Otherwise the whole ecosystem will suffer from shortcomings of microdata

+1

Microdata is what it is.

@thadguidry

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@gkellogg not the URL... the Type ! :)

If it helps...What does this mean to you ?

<div itemscope itemtype="http://schema.org/MedicalClinic+PlasticSurgeryProvider">
@gkellogg

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@thadguidry, yes @itemtype takes one or more absolute URLs that MUST be in the same vocabulary. In that sense, http://schema.org/MedicalClinic and http://schema.org/MedicalClinic+PlasticSurgeryProvider, along with http://schema.org/MedicalClinic/PlasticSurgeryProvider are both absolute URLs in the same vocabulary. The Microdata to RDF algorithms will generate property predicate URIs for all of these.

@thadguidry

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@gkellogg interesting. It would be cooler still if the algorithms could deduce that I am trying to say:

http://schema.org/MedicalClinic
(and) denoted by + plus sign
http://schema.org/PlasticSurgeryProvider

So ideally and cooler still would be my JSON-LD describing my custom properties for the unknown new type PlasticSurgeryProvider:

{
  "@context": "http://schema.org",
  "@type": "MedicalClinic+PlasticSurgeryProvider",
  "+proceduresPerformed:description":"The Medical Procedures performed by this Plastic Surgery Provider",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "streetAddress": "1200 Highway 75"

  },
  "description": "A superb clinic with world class emergency care services",
  "name": "iCare Clinic",
  "telephone": "850-555-1234",
  "+PlasticSurgeryProvider:proceduresPerformed": "Lap Band, Tummy Tuck, Rhinoplasty"
}
@gkellogg

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

In JSON-LD you can simply have two types in an array, which should do some of what you want:

{
  "@context": "http://schema.org",
  "@type": "MedicalClinic+PlasticSurgeryProvider",
  "+proceduresPerformed:description":"The Medical Procedures performed by this Plastic Surgery Provider",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "streetAddress": "1200 Highway 75"

  },
  "description": "A superb clinic with world class emergency care services",
  "name": "iCare Clinic",
  "telephone": "850-555-1234",
  "+PlasticSurgeryProvider:proceduresPerformed": "Lap Band, Tummy Tuck, Rhinoplasty"
}

Note that the Linter simply reduces markup (Microdata, RDFa or JSON-LD) to RDF and reasons over the results, so if semantics aren't captured in RDFS it will flag issues. One way to do this would be to capture the RDFS in your document, although it would be somewhat extraneous:

{
  "@context": "http://schema.org",
  "@graph": [{
    "@type": ["MedicalClinic", "PlasticSurgeryProvider"],
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Dallas",
      "addressRegion": "TX",
      "streetAddress": "1200 Highway 75"
    },
    "description": "A superb clinic with world class emergency care services",
    "name": "iCare Clinic",
    "telephone": "850-555-1234",
    "proceduresPerformed": "Lap Band, Tummy Tuck, Rhinoplasty"
  }, {
    "@id": "http://schema.org/PlasticSurgeryProvider",
    "@type": "rdfs:Class",
    "rdfs:label": "Plastic Surgery Provider",
    "rdfs:comment": "..."
  }, {
    "@id": "http://schema.org/proceduresPerformed",
    "@type": "rdf:Property",
    "rdfs:label": "procedures performed",
    "rdfs:comment": "The Medical Procedures performed by this Plastic Surgery Provider",
    "rdfs:domain": "http://schema.org/PlasticSurgeryProvider"
  }]
}

Anything else is really conflating markup with semantics IMO, and isn't really RDF anymore. It would need to work consistently across the different markup sites. I think that people that are serious about such extensions should just define a vocabulary with a JSON-LD context and use it as such, for example:

{
  "@context": {
    "@vocab": "http://schema.org",
    "myVocab": "http://example.org/myVocab#",
    "PlasticSurgeryProvider": "myVocab:PlasticSurgeryProvider",
    "proceduresPerformed": "myVocab:proceduresPerformed"
  },
  "@graph": [{
    "@id": "myVocab:PlasticSurgeryProvider",
    "@type": "rdfs:Class",
    "rdfs:label": "Plastic Surgery Provider",
    "rdfs:comment": "..."
  }, {
    "@id": "myVocab:proceduresPerformed",
    "@type": "rdf:Property",
    "rdfs:label": "procedures performed",
    "rdfs:comment": "The Medical Procedures performed by this Plastic Surgery Provider",
    "rdfs:domain": "myVocab:PlasticSurgeryProvider"
  }]
}

This can be used within a JSON-LD document as follows:

{
  "@context": ["http://schema.org", "http://example.org/myVocab"],
  "@type": ["MedicalClinic", "PlasticSurgeryProvider"],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "streetAddress": "1200 Highway 75"
    },
  "description": "A superb clinic with world class emergency care services",
  "name": "iCare Clinic",
  "telephone": "850-555-1234",
  "proceduresPerformed": "Lap Band, Tummy Tuck, Rhinoplasty"
}

RDFa is simple enough using prefix definitions. Microdata can be more complicated and likely involves the use of absolute URLs for some @itemprop values along with additionalType, but then Microdata isn't as well suited for more complicated markup sort of by design.

@thadguidry

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

@gkellogg "Microdata isn't as well suited for more complicated markup" - Yes, as you have already explained.
Thanks Greg ! , this gives us a good perspective on capabilities actually. Some I did not know about.
I totally agree that extending should be interpreted as "define your OWN vocabulary".

So, the problem now lies with helping train and document for folks how to easily define their own vocabulary with JSON-LD (and use it to extend existing Schema.org properties as well as creating their own Types) and making it a pseudo official method that the stakeholders can agree upon.

Takers ?

@gkellogg

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2015

So, the problem now lies with helping train and document for folks how to easily define their own vocabulary with JSON-LD (and use it to extend existing Schema.org properties as well as creating their own Types) and making it a pseudo official method that the stakeholders can agree upon.

Yes, given the complexities of getting RDF schemas right, and generating a JSON-LD context, some kind of online tool that dumps out a JSON-LD document containing the context and the vocabulary definition would be pretty useful. Could be a fairly simple form-based tool, maybe part of json-ld.org.

@elf-pavlik

This comment has been minimized.

Copy link
Contributor Author

commented Jan 29, 2015

@msporny, we had conversation on Web Credentials list about integrating Credentials / OBI vocabularies with schema.org. We also discussed with @mfhepp aligning vocabularies related to e-commerce work happening in Web Payments CG/IG in #134 (comment) . Last but not least, you published an excellent comparison of RDFa/Microdata/Microformats
Would you have some constructive suggestions for clear path in extending schema.org? Especially using externally defined vocabularies and possibly having option not to limit oneself with constrains related to use of Microdata.
EDIT: I also just noticed RDFa Vocabulary Expansion which looks possibly useful here...

@danbri

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2015

Also related: Martin Hepp's property-value proposal, #263

@sesuncedu

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2015

I've tried to explain above a mechanism for producing microdata that cannot
be proven to be incorrect, and which gets around the one vocabulary, flat
namespace rule (the net effect would allow things that look and work like
abbreviated IRIs).

Creating a yet another new model for defining ontologies would be bad (~
all life as you know it stopping instantaneously and every molecule in your
body exploding at the speed of light bad).

The extension mechanism should use straight rdf(s)+ owl, or the sdo
syntactic variant.
CycL would also be a reasonable choice, given the data model
documentation
...

The distortions in sdo are side-effects of forcing things into a
single flat namespace just to be able to reuse any sdo properties at all.

There are a number of steps that could be taken to start logically
partitioning the existing sdo vocabulary without breaking backwards
compatibility (nice term set, medicine. Shame if it were to accidentally
get struck by a killer whale).

Possible splitters include:

  1. treating the term definitions as intentional concepts and punning them
    into concept schemes.
  2. defining second order faceting classes.
  3. moving the terms into a separate namespace and file, with deprecated
    equivalentBlah terms in the main namespace.

Composite domains and ranges stand some examination. Generic terms should
not have very specific classes mixed in to the domain , especially if
there is no real connection between the various classes (member got messed
up by frequent flyers).

Documentation for general purpose terms should not have to mention specific
classes.

Conversely, specific terms should not have to mention inapplicable generic
terms.

@sesuncedu

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2015

I think it might be good to set up a real time discussion on data model & extension mechanisms sometime soon, to discuss some concrete options. A Google hangout, or similar (could request the IAOA conference bridge) , with some summary but concrete proposals ahead of time to compare and contrast for usability, ease of implementation, expressivity, etc.

Note:
Some raw or cooked data on current usage in the wild would be handy (for example, some terms may have high frequency, and occur in many documents, but those documents may only occur on a few sites (or be seo gamesmanship) ; some theoretically allowed properties may have virtually no usage on given types, etc.

@jasondouglas

This comment has been minimized.

Copy link

commented Jan 29, 2015

@danbri - I might've just missed it, but I didn't see on your list what we discussed with Actions which was defining your own subclass. For example, I have a proprietary share action that has it's own properties (e.g., "Pin" for "Pinterest") and so I want to use everything that's on ShareAction, but extend it with my own params.

@vholland

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2015

@jasondouglas - Couldn't you use gkellogg's suggestion above to define your extension inline? Schema.org already has schema.org/Property and schema.org/Class, which is equivalent to rdfs:Class. It seems if schema.org also had an equivalent to rdfs:subClassOf, authors could state PinAction is a subClassOf ShareAction and here are the properties.

@jasondouglas

This comment has been minimized.

Copy link

commented Jan 30, 2015

@vholland - yes, that's what I would assume, but I don't believe we've said that it's either a recommended or supported practice.

@sesuncedu

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2015

It's not really supported, and would have some implementation downsides at
scale.

An imports mechanism (using the same ontology language if desired ) could
have some distinct advantages over inline definitions, since instance
classification & validation rules can be compiled.

Inline axioms may cause problems for streaming processing, since axioms at
the end of the document may change the meaning of entities encountered
earlier.

It might be possible to impose restrictions on inline definitions that
avoid crossing the streaming. For example, requiring that all definitions
appear up front, with all classes appearing before any subclasses,
forbidding the introduction of new superclasses for existing classes, and
forbidding the use of domainIncludes and rangeincludes on existing
properties, and requiring subproperties to specify domains/ranges that are
subclasses of the effective domain/range of the superproperty should be
fairly easy to handle incrementally.

Or could do imports.
On Jan 30, 2015 12:32 PM, "jasondouglas" notifications@github.com wrote:

@vholland https://github.com/vholland - yes, that's what I would
assume, but I don't believe we've said that it's either a recommended or
supported practice.


Reply to this email directly or view it on GitHub
#284 (comment).

@danbri

This comment has been minimized.

Copy link
Contributor

commented Feb 11, 2015

Here's a discussion document that revisits our approach to extensions:

https://docs.google.com/document/d/1-hq53ZtP1NxRqpjCCuhVRRwqQmEuaAzWDQ7OuG18_pg/edit?usp=sharing

(If anyone has trouble w/ google docs let me know and I'll post a snapshot somewhere in a textier form)

@elf-pavlik

This comment has been minimized.

Copy link
Contributor Author

commented May 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.