 |
 |
Hi, Thanks a lot for forwarding this discussion here! It seems to me that you are quite in agreement. schemaorg:domain and schemaorg:range have "labels" that I'm not fond of, but at least now we have well-identified properties (ie with their own URIs, distinct from the RDFS domain and range ones) with agreed definitions. @Dan: do you think Bernard's semi-formal definition could make their way into http://schema.org/docs/datamodel.html? Antoine > 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 >> forum. >> A quick summary : >> I've posted my (still mixed) feelings about Dan Brickley's position >> yesterday [1] >> and got Dan's feedback [2] I have suggested to Dan to continue the >> conversation here. >> Actually I begin to understand better and what Dan proposes at [3] begins to >> make sense to me. > > Hurrah :) > >> 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 > http://schema.org/docs/datamodel.html > >> 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 > > Yup. > > 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 > http://blog.schema.org/2012/05/schemaorg-markup-for-external-lists.html > ... posted late on Friday so people might've missed it. > > cheers, > > Dan > >> Bernard >> >> >> >> [1] >> http://blog.hubjects.com/2012/04/schemaorg-tree-and-vocabulary-forest.html >> [2] https://plus.google.com/108363728773973627360/posts/h3QDjqirHY >> [3] >> https://dvcs.w3.org/hg/webschema/file/b9e25ad40b88/schema.org/drafts/alpha/rdfa.html >> >> >> Le 6 avril 2012 00:43, Thomas Baker<[log in to unmask]> a écrit : >>> >>> Schema.org Alignment Task Group - 2012-04-05 telecon - report >>> >>> Agenda: >>> http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120405 >>> This report: >>> http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120405_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., [1]) >>> * pages on issues raised (e.g., >>> https://github.com/dcmi/schema.org/issues/9) >>> * the draft mappings themselves, in RDF/XML format, on GitHub >>> (https://github.com/dcmi/schema.org) >>> * 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 >>> be >>> laboriously cut-and-paste into [1] -- 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 >>> a >>> machine-readable form, but it is not friendly for users, so we would >>> have >>> to find some way to generate a Web page from these mappings that people >>> can >>> 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 >>> out >>> of sync as soon as we make edits. >>> >>> Finally, it is still unclear how we will be able to collect comments on >>> the >>> mappings on an ongoing basis. >>> >>> Antoine, you suggested we might move the mappings from RDF/XML into >>> RDFa [2]? >>> >>> [1] >>> http://wiki.dublincore.org/index.php/Schema.org_Alignment/Mappings_Details >>> [2] >>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1204&L=dc-architecture&F=&S=&P=2541 >>> >>> 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. >>> >>> [3] >>> http://wiki.dublincore.org/index.php/Schema.org_Alignment/Mappings_Details#schema:Organization_rdfs:subClassOf_dct:Agent >>> >>> ACTION: Antoine and Tom to put wiki document Mappings_Details into RDFa. >>> >>> ---------------------------------------------------------------------- >>> Issue 9: schemaorg type-properties and rdfs:domain (Bernard) >>> https://github.com/dcmi/schema.org/issues/9 >>> >>> 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 >>> schema.org. >>> I am perplexed; am unsure we can rely on something that is not >>> explicit. >>> 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 >>> into >>> Schema.org markup? Or do we say clearly we are using rdfs.org because >>> schema.org >>> does not make available the equivalent? >>> >>> Karen: It seems like a coin toss because we don't know which will be more >>> stable. >>> We should pick the one we think is more stable. >>> >>> Bernard: If you go to schema.org itself, there are no formal definitions, >>> but >>> "types" and "properties" and "expected values", etc. but as DanBri >>> explains, >>> 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 >>> union. >>> >>> Antoine: Agree, but Dan seems to be saying we should not consider these >>> domain >>> statements, etc, as stable. Sceptical about the value of really >>> precise >>> 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 >>> rdfs.org). >>> 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 >>> dereferenceable. >>> The only dereferenceable definition is given by Schema.org. If we make >>> mappings, >>> 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 >>> definition >>> that is overcommitted - with semantics that are more constrained than >>> the schema.org >>> version. >>> >>> GordonD: +1 for using rdfs.org >>> >>> Karen: I'm not sure how we could do this otherwise. How could we express >>> equivalence >>> 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 >>> at >>> 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 >>> is >>> what is happening now. The other users of the URI will rely on the >>> first >>> formal definition provided by whomever - not necessarily the publisher >>> of >>> the URI. Of course, if Schema.org publishes formal definitions, we >>> should >>> use them, but until then no choice. >>> >>> Tom: If we were to decide otherwise, we would have to change the contents >>> of [4], >>> which uses the formal definitions at rdfs.org. >>> >>> [4] >>> http://wiki.dublincore.org/index.php/Schema.org_Alignment/Mappings_Details >>> >>> RESOLVED Use rdfs.org as basis of the mapping. >>> >>> RESOLVED To Kirsten's question [5] -- how to add new proposals for >>> mappings >>> -- the response is to wait until the RDFa file is done, then fold in >>> new >>> proposals there. >>> >>> [5] >>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1202&L=dc-architecture&F=&S=&P=14738 >>> >>> >>> -- >>> 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 >> >> -------------------------------------------------------- >> Mondeca >> 3 cité Nollez 75018 Paris, France >> www.mondeca.com >> Follow us on Twitter : @mondecanews >> >