On 12 April 2012 18:37, Bernard Vatant <[log in to unmask]> wrote:
Sorry for the slow reply...
> The discussion about schema.org URIs semantics has continued outside this
> A quick summary :
> I've posted my (still mixed) feelings about Dan Brickley's position
> yesterday 
> and got Dan's feedback  I have suggested to Dan to continue the
> conversation here.
> Actually I begin to understand better and what Dan proposes at  begins to
> make sense to me.
> What is lacking if a definition of http://schema.org/domain and
> http://schema.org/range (which I suggest to rename to avoid confusion
> validSubjectType and validObjectType).
> Such predicates allow a coupling of properties to types (classes) less
> restrictive than rdfs:domain and rdfs:range. They would be used more for
> data aggregation and sanity check than for inferencing.
Yes. Probably we won't rename them at this stage, since they haven't
yet been formally named at all. The word "valid" has its own bagage,
too. In the human-facing docs we say something like "expected type"
sometimes, but we do use 'domain' and 'range' informally in
> Basically the semantics is that if you have declared in the schema :
> p validSubjectType D
> p validObjectType R
> It means than the following graph is conformant to the schema
> x rdf:type D
> x p y
> y rdf:type R
> But if you find only (x p y) you can't infer anything on the type of x and y
We think that's ok, since often a common supertype of D and R is a
pretty boring, artificial construction anyway.
> Seems to me, many vocabularies actually use rdfs:domain and rdfs:range
> default such expressivity, without anticipating consequences of the "hard"
> semantics of those properties.
> An issue not unlike owl:sameAs abuse ...
Yes, I'm sure that is the case.
> So ... maybe validSubjectType and validObjectType should be defined outside
> the schema.org namespace, for a more general use.
I'd like to make sure it works for us first ;)
Loosely related btw is
... posted late on Friday so people might've missed it.
>  https://plus.google.com/108363728773973627360/posts/h3QDjqirHY
> Le 6 avril 2012 00:43, Thomas Baker <[log in to unmask]> a écrit :
>> Schema.org Alignment Task Group - 2012-04-05 telecon - report
>> This report:
>> Present: Tom (chair), Karen, Gordon, Antoine, Bernard, Kai (IRC)
>> Tom: We have:
>> * wiki pages with the information we need for comparing terms to be
>> mapped (e.g., )
>> * pages on issues raised (e.g.,
>> * the draft mappings themselves, in RDF/XML format, on GitHub
>> * the mailing list, with a bit of everything.
>> The information and comments we need to consider in order to make the
>> mappings is spread all over and poorly linked. It is tedious even to
>> pull these together
>> into an agenda.
>> Information about the properties and classes we are considering had to
>> laboriously cut-and-paste into  -- and we will have no way of
>> knowing if
>> the sources have changed if not by manually clicking on the links.
>> Finally, the RDF/XML format on GitHub is nice, because it is already in
>> machine-readable form, but it is not friendly for users, so we would
>> to find some way to generate a Web page from these mappings that people
>> read and use. The RDF/XML format is also not ideal for citing in the
>> GitHub issue tracker, because URIs with line references will be thrown
>> of sync as soon as we make edits.
>> Finally, it is still unclear how we will be able to collect comments on
>> mappings on an ongoing basis.
>> Antoine, you suggested we might move the mappings from RDF/XML into
>> RDFa ?
>> Antoine: we could put these mappings into RDFa and point off to the
>> discussion threads.
>> For example, we could have an HTML representation of URL above - plus
>> pointers to GitHub
>> issue tracker and mailing list. We could add RDFa markup into the head
>> of that section.
>> We could use the HTML of the wiki page as a starting point.
>> ACTION: Antoine and Tom to put wiki document Mappings_Details into RDFa.
>> Issue 9: schemaorg type-properties and rdfs:domain (Bernard)
>> Bernard: The Schema at RDFS.org is Michael Hausenblas's interpretation.
>> It is
>> more or less endorsed by schema.org itself, because there is a link.
>> But there
>> is also a rather inconspicuous schemaorg.owl schema, which is not in
>> sync with
>> the larger schema.org activity. DanBri says that the implicit
>> semantics at
>> schema.org are not as specific as at rdfs.org. He suggests we use
>> I am perplexed; am unsure we can rely on something that is not
>> Issue: how will people use mappings that we publish? I just spoke
>> with someone
>> who is using schema.org for a newspaper in French; they transform
>> existing DC
>> into schema.org markup. Do we rely on something pragmatic? Turn DC
>> Schema.org markup? Or do we say clearly we are using rdfs.org because
>> does not make available the equivalent?
>> Karen: It seems like a coin toss because we don't know which will be more
>> We should pick the one we think is more stable.
>> Bernard: If you go to schema.org itself, there are no formal definitions,
>> "types" and "properties" and "expected values", etc. but as DanBri
>> these are not the formal semantics of RDFS domain and range.
>> These semantics are not expressed formally anywhere - except by
>> Dan. I think
>> this is a shaky foundation to build on.
>> Some properties are defined with a domain of Person _or_
>> Organization, for
>> example. If you want to express this "or", it translates into OWL
>> Antoine: Agree, but Dan seems to be saying we should not consider these
>> statements, etc, as stable. Sceptical about the value of really
>> semantics in the DC context, because alot of properties are loosely
>> defined -
>> just like Schema.org.
>> Bernard: But URIs used on both sides are the same (at schema.org and
>> If you assert any equivalence between DC and Schema.org property, the
>> URI you
>> use as subject of the triple is something that has a weird status now.
>> Schema.org does not provide a description, because the URI is not
>> The only dereferenceable definition is given by Schema.org. If we make
>> we have to be explicit about where the semantics are defined. If not
>> at rdfs.org,
>> where is there a formal definition?
>> Antoine: Okay with me to use rdfs.org. I will flag it if I see an rdfs.org
>> that is overcommitted - with semantics that are more constrained than
>> the schema.org
>> GordonD: +1 for using rdfs.org
>> Karen: I'm not sure how we could do this otherwise. How could we express
>> between things in RDF and things not in RDF?
>> Antoine: If equivalence is asserted between DC and non-RDF terms, implies
>> that the
>> target propertiy "is a property" - an analogous problem.
>> Bernard: Antoine, this relates to HTTP Range-14. If the owner of the URI
>> Schema.org does not declare the semantics of the URI, someone else
>> will, and
>> this is exactly what is happening. Giving semantics to URIs not owned
>> what is happening now. The other users of the URI will rely on the
>> formal definition provided by whomever - not necessarily the publisher
>> the URI. Of course, if Schema.org publishes formal definitions, we
>> use them, but until then no choice.
>> Tom: If we were to decide otherwise, we would have to change the contents
>> of ,
>> which uses the formal definitions at rdfs.org.
>> RESOLVED Use rdfs.org as basis of the mapping.
>> RESOLVED To Kirsten's question  -- how to add new proposals for
>> -- the response is to wait until the RDFa file is done, then fold in
>> proposals there.
>> Tom Baker <[log in to unmask]>
> Bernard Vatant
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Linked Open Vocabularies
> 3 cité Nollez 75018 Paris, France
> Follow us on Twitter : @mondecanews