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
>>
>
|