Re: Question about literals in subject position

On Mon, Sep 28, 2009 at 9:49 AM, Birte Glimm
<birte.glimm@comlab.ox.ac.uk> wrote:
> [snip]
>
>> We could change the definition to allow literals as subjects - in order to maintain compatibility absolutely with the Query 1.0 spec, the restriction could be moved into the definition of simple entailment matching, freeing it up for other entailment regimes.
>>
>> Query 1.0 notes that the RDF WG knew of no reason not permit them except the syntax issues with RDF/XML.

I can't recall where I saw this, but didn't the RDF folks consider
adding them in if a new version of RDF ever happens?

> I am not advocating that literals in subject positions should be
> allowed. If they are allowed, however, they are another source of
> infinite answers under at least RDF(S) entailment regimes and we have
> to have conditions in space to prevent infinite answers from this
> source. The restriction that I have proposed would work for literals
> in subject position, but we have discussions at the moment about we
> should just restrict the use of rdf:_1, rdf:_2, ... which are the only
> real source of infinite answers at the moment.

I'd prefer to see the entailment regime restricted to prevent infinite
entailment. This needs to be the case for OWL anyway, where blank
nodes have to be avoided for things like owl:minCardinality.

>> FYI: system that provide property function, built-in functions (various other names) put literals in the subject position
>
> Good to know.

Personally, I prefer the flexibility of saying things like:

"10941738641570527421809707322040357612003732945449205990913842131476349984288934784717997257891267332497625752899781833797076537244027146743531593354333897"^^positiveInteger
 math:hasFactor
"102639592829741105772054196573991675900716567808038066803341933521790711307779"^^positiveInteger

"10941738641570527421809707322040357612003732945449205990913842131476349984288934784717997257891267332497625752899781833797076537244027146743531593354333897"^^positiveInteger
 math:hasFactor
"106603488380168454820927220360012878679207958575989291522270608237193062808643"^^positiveInteger

(not saying we *should* do this, just that I like it)

Of course, there are alternatives to this (currently invalid) syntax
that use skolemization, but these can be frustrating to use, and a
mapping for skolemizing can become an issue as well. Also, the
functions that Andy alluded to tend to become more difficult when
skolemizing.


Regards,
Paul

Received on Monday, 28 September 2009 17:43:00 UTC